Test Plan.doc

mexicanmorningΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 4 μήνες)

363 εμφανίσεις


Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
i

of
13

3/18/2013



Patient Study Calendar


Test Approach Document

Version 3.0




Document Change history

Version Number

Date

Description

1.0

August 3, 2005

First draft is created

2.0

September 18, 2006

Final submitted

3.0

November 3, 2006

Revised based on ARCH Mentor f
eedback


Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
i

of
13

3/18/2013

TABLE OF CONTENTS


1.

INTRODUCTION

................................
................................
................................
................................
..................

1

1.1

S
COPE

................................
................................
................................
................................
.............................

1

1.1.1

Identification

................................
................................
................................
................................
.....

1

1.1.2

Document Overview

................................
................................
................................
..........................

1

1.2

R
ESOURCES

................................
................................
................................
................................
....................

2

1.3

R
EFERENCED DOCUMENTS

................................
................................
................................
..........................

2

2.

SOFTWARE TEST STRATE
GY

................................
................................
................................
.........................

4

2.1

O
BJECTIVES

................................
................................
................................
................................
...................

4

2.2

APPROACH

................................
................................
................................
................................
....................

4

2.3

D
ESCRIPTION OF
F
UNCTIONALITY

................................
................................
................................
..............

6

2.4

S
PECIFIC
E
XCLUSIONS

................................
................................
................................
................................
..

6

2.5

D
EPENDENCIES
&

A
SSUMPTIONS

................................
................................
................................
................

6

2.6

G
ENERAL
C
RITERIA FOR
S
UCCESS

................................
................................
................................
..............

7

2.6.
1

Readiness Criteria

................................
................................
................................
.............................

7

2.6.2

Pass/Fail Criteria

................................
................................
................................
.............................

7

2.6.3

Completion Criteria

................................
................................
................................
..........................

7

2.6.4

Acceptance Criteria

................................
................................
................................
..........................

8

3.

SOFTWARE TEST ENVIRO
NMENT

................................
................................
................................
................

9

4.

TEST SCHEDULE

................................
................................
................................
................................
...............

10

5.

RISKS

................................
................................
................................
................................
................................
....

11



Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
1

of
13

3/18/2013

1.

INTRODUCTION

This Test Plan describes the scope, approach, resources, and schedule for the testing activities
needed for the caBIG

Patient Study Calendar (PSC). It identifies the items being tested, features
to be tested, testing tasks to be performed, personnel responsible for each task, and risks
associated with this plan.

1.1

SCOPE

The scope of the PSC is detailed in the project’s Vi
sion and Scope document. In brief, the
module provides a standalone application providing the ability to create and edit study calendar
templates, generate and view prospective calendars, enter actual calendar events as they occur,
and manage calendars as
they change during a study. The software also provides integration
points to serve as an event hub for other study calendar modules.

The scope of testing on the project is limited to the requirements identified in the project’s
Software Requirements Specif
ication (SRS). The project has been broken up into four short
releases, with requirements for separate functional areas being determined at the start of each
release. The impact of this on the Test Plan is that the specifics of the test plan and the test d
ata
will be determined as requirements are included in the SRS.

1.1.1

Identification

This document applies to the PSC being developed by contributing members of the CTMS
workspace in the NCI caBIG initiative. The system is being developed by the PSC Development
team being led by Warren Kibbe at Northwestern University, in cooperation with the caBIG PSC
SIG and the Clinical Research Office staff of Northwestern University.

1.1.2

Document Overview

This Test Plan defines the strategies necessary to accomplish the testing
activities associated with
the development of the PSC module.

The Test Plan sections are organized as follows:

Section 1: Introduction
:

(This section)

Section 2: Strategy
: Describes the strategy for the overall approach and general
techniques to be used du
ring testing.

Section 3. Software Test Environment
: Describes the intended testing environment.

Section 4. Test Schedules
: Contains or references the schedules for conducting testing.

Section 5. Risks
: Identifies the risks associated with the Test Plan.


Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
2

of
13

3/18/2013

1.2

RE
SOURCES

Developer site personnel involved in testing include:

Warren Kibbe, Northwestern University


PI

Moses Hohman, Northwestern University


Project Manager, Prelude and Release 1 / Developer
Release 1

Rhett Sulphin, Northwestern University


Lead Deve
loper

Sean Whitaker, Northwestern University


Project Manager, Release 2
-
4 / Developer

Jaron Sampson, Akaza Research


QA Lead / Developer

Yufang Wang, Akaza Research
-

Developer

Padmaja Vedula, Semantic Bits


Developer

Use cases and requirements are gat
hered by the project team from the biweekly meetings with the
SIG and weekly meetings with the PSC Development Requirements group. These requirements
inform the development of the User Acceptance Tests. The latter group includes:

Sharon Elcombe, MA, Admini
strative Director, Mayo Clinic Cancer Center Clinical Research
Office and Group Operations Coordinator, North Central Cancer Treatment Group (NCCTG).

Paul Courtney, MS, Project Manager, Dartmouth/Norris Cotton Cancer Center.

John Speakman, Director, Clini
cal Research Informatics, Memorial Sloan
-
Kettering Cancer
Center.

Karen Ryan, Associate, Booz Allen Hamilton.

Lee Esker, MBA, Financial Operations Manager, Clinical Research Office, Robert H. Lurie
Comprehensive Cancer Center of Northwestern University.

1.3

R
EFERENCED DOCUMENTS

For additional project specific information, refer to the following documents:



Vision and Scope.doc



SRS.doc



PMP.doc



Stakeholder Involvement and Communication Plan.doc



Test Reports.doc



Use Cases.doc


Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
3

of
13

3/18/2013



Project Risks.doc


Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
4

of
13

3/18/2013

2.

SOFTWARE TEST STRATE
GY

2.1

OBJECTIVES

The quality assurance testing approach consists of three primary efforts: unit testing, integration
testing, and user acceptance testing. Unit testing is done during code development to verify
correct function of source code modules, and to p
erform regression tests when code is refactored.
Integration tests verify that the modules function together when combined in the production
system. User acceptance testing verifies that software requirements and business value have been
achieved.

System s
ecurity based on project participant and user roles is to be tested during integration and
user acceptance testing. Mechanisms to allow for adequate auditing as required by 21 CFR Part
11 and HIPAA guidelines will be taken into account for system architect
ure and design purposes
and will be subject to unit testing. However, the system will not be formally validated or
certified for compliance with 21 CFR Part 11 or HIPAA as part of currently planned test
activities.

2.2

APPROACH

Testing method:

Unit Testing

Summary:

Developers will be responsible for creating unit tests for all
modules developed. JUnit will be used as the testing framework,
and will be augmented by HTTPUnit, Schemamule, and DBUnit.
EasyMock. The Spring Framework’s mock library and EasyMock
will be used to create mock objects to assist in separating unit tests.

CruiseControl will run unit tests each time the repository is revised
and will archive test reports. Developers will be able to run unit
tests as needed to verify correct function of t
heir code, the results of
these ad
-
hoc unit tests will not be saved. Unit test code coverage
will be measured using Emma and those reports will be archived by
CruiseControl.

Tester(s):

Developer, Cruise Control


Testing method:

Integration testing


Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
5

of
13

3/18/2013

Summa
ry:

The Test Plan contains integration tests used to verify functional
requirements and to produce an integrated system suitable for User
Acceptance Testing. These tests will be written in Ruby as
Selenium scripts, stored in subversion, and executed for ea
ch
iteration release candidate. The Test Plan contains suspension and
resumption criteria for the integration tests, and reports generated.
Integration testing will be performed near the end of code
development for all iterations, allowing sufficient devel
opment time
to address integration issues. Integration tests will be peer
-
reviewed
by developers. Test results will be monitored by the QA Lead who
will be responsible for issuing trouble tickets.

Tester(s):

Developer, QA Lead


Testing method:

Regression

testing

Summary:

Developers will be responsible for running a build script which runs
all unit tests before checking in code to the repository. Cruise
control will also run the unit tests time each time code is submitted
to the repository. Errors will ca
use Cruise Control to send messages
to the responsible developer, the QA Lead, and the Technical Lead.

Tester(s):

Developer, Cruise Control, QA Lead


Testing method:

System installation testing

Summary:

Installation on a naïve (blank) machine will be te
sted, i.e., that all
software dependencies and system requirements are explicitly stated
in the documentation. System requirements and recommendation
include:



Hardware recommendation



Operating system requirements



Application server (Apache Tomcat)



Java 5
SDK



Firefox 1.5x



Supported databases (Oracle and PostgreSQL)

Installation guide and system deployment plans will be produced as
a result of the system installation testing.


Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
6

of
13

3/18/2013

Tester(s):

Developer
(will test installation on each platform and
configuration)

,

Adopter



Testing method:

User acceptance testing

Summary:

The adopter will be responsible for evaluating each release of the
software. At the beginning of each release, User Acceptance criteria
will be determined from software requirements. Adopter wil
l make
objective determinations of quality and provide issue reports

Tester(s):

Adopter

(report issues and enhancement request to QA Lead)

QA Lead, Project Manager

(create tickets to address issues and
enhancement requests, prioritized according to requir
ements
)


2.3

DESCRIPTION OF FUNCT
IONALITY

Although the long term benefits to be derived from the Patient Study Calendar are the standards
-
based interfaces and data definitions, the short term objectives and measurable success metrics
are around having an appl
ication that fulfills business requirements and end
-
user needs. In
particular, the Patient Study Calendar enables the creation of a study calendar template for a
study, manages events around the screening and registration of a participant on a study, prov
ides
a study
-
specific forecast calendar at a patient level, provides a retrospective view of participant
events, and provides study
-
, participant
-
, and event
-
based reports focused on the study calendar.

2.4

SPECIFIC EXCLUSIONS

The PSC is not intended to be a
n electronic data capture application. Therefore, clinical data in
the form of Case Report Forms (CRF) will not be collected or stored by the module.

2.5

DEPENDENCIES & ASSUM
PTIONS

Java programming language

The Patient Study Calendar application is developed
in the Java programming language. The
Java EE 5 SDK is being used for development. Integration tests and other tools and utilities will
be written in ruby, groovy, or other appropriate languages

that are useful in the testing
environment
.

Application Serv
er

The PSC implementation requires a Java application server. Apache Tomcat will be used for
development and testing.

Relational database


Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
7

of
13

3/18/2013

The backend database targets both PostgreSQL and Oracle relational databases. Unit tests will be
run against both targ
et databases.

Web browser

User acceptance testing and integration testing will target the Firefox 1.5x web browser.

2.6

GENERAL CRITERIA FOR

SUCCESS

2.6.1

Readiness Criteria

The test environment for each testing setting (unit, integration, and user acceptance) will
be
prepared prior to testing. This requires having systems installed with Apache Tomcat and access
to a properly configured database.

Unit testing starts after the first data access component is added to the system. Test cases will use
their own test data
sets; therefore each test database will be populated with test data before
beginning of unit testing and automatically cleared after unit testing. A separate database target
will be used for unit testing, so that unit testing does not clear operational dat
a for user testing
during development.

System installation tests take place after each release. Preparation of test environments on
different hardware configurations, creation of test databases and test files precede testing.

User acceptance testing is sc
enario based; these test scenarios should be defined with explicitly
stated sequences of user actions and expected
outcomes
.
The
s
ystem
will be

ready for functional
testing when
user requirements
are
implemented and documented as a test
scenario.
The
s
ystem
is ready for user acceptance testing right after successful completion of system installation testing
by Adopter.

2.6.2

Pass/Fail Criteria

The criteria for success of unit testing are 100% pass rate of tests.

User acceptance testing scenar
ios contain textual description
s

of user actions and expected
changes in system state and stored data. The criteria for success of acceptance testing is

100%
pass rate of test scenarios.

The
d
eveloper
s will
analyze

results of
the
system installation tes
ting and determine

the

quality of
documentation and ease of use.
The
d
eveloper
’s

approval
serves as pass/fail criteria

for tests
.

The
a
dopter
s

evaluate

user acceptance
. Adopter’s decision serves as pa
ss/fail criteria.

2.6.3

Completion Criteria

Testing is considered completed when the assigned tests have been executed and defects and
discrepancies are documented by
the
d
eveloper
s

and
a
dopter
s
.


Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
8

of
13

3/18/2013

In order for testing to be completed

the
d
eveloper
s

must reso
lve, verify, or designate as future
changes all filed issues in the issue tracking system.

2.6.4

Acceptance Criteria

Adopter
s

are

responsible for making
decision
s

about the completion of user acceptance testing
and approving
the
system for trial use at
their
site.

The criteria for acceptance of the testing procedures is that the system facilitates the creation of a
study calendar template, a prospective view of the template when applied to a specific patient and

calendar dates, and a retrospective
view of the actual patient performance of scheduled activities.



Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
9

of
13

3/18/2013

3.


SOFTWARE TEST ENVIRO
NMENT

This section describes the software test environment at each intended test site.

The Basic Test Environment

at developer site:


Hardware

Dell Latitude D510 (1.4 GH
z Intel Celeron M,
512 MB)

OS system

Windows XP Professional

Application server

Tomcat 5

Java SDK

1.5.0_07

Database 1

PostgreSQL 8.1

Database 2

Oracle 9 (through tunnel to NU)

Client web browser

Mozilla Firefox 1.5.0.6


The System Test Environment

a
t developer site:

Hardware

Apple Xserve Dual Processor 1 GHz
PowerPC G4

OS system

OSX 10.4

Application server

Tomcat 5.5

Java SDK

1.5.0_07

Database

PostgreSQL 8.1


The Acceptance Test Environment

at Adopter site:


Hardware

Apple Xserve Dual Processor
1 GHz
PowerPC G4

OS system

OSX 10.4

Application server

Tomcat 5.5

Java SDK

1.5.0_07

Database

PostgreSQL 8.1






Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
10

of
13

3/18/2013

4.

TEST SCHEDULE

8/7/2006

Release 1 Unit Test and Integration Test Reports

8/21/2006

Release 1 System Installation Tests and User Acceptance
Tests

9/18/2006

Release 2 Unit Test and Integration Test Reports

10/02/2006

Release 2 System Installation Tests and User Acceptance Tests

10/30/2006

Release 3 Unit Test and Integration Test Reports

11/13/2006

Release 3 System Installation Tests and Use
r Acceptance Tests

12/11/2006

Release 4 Unit Test and Integration Test Reports

12/18/2006

Release 4 System Installation Tests and User Acceptance Tests






Test Approach Document

Sponsor Award # 1435
-
04
-
04
-
CT
-
73980/79596CB

PSC Test Approach Document

Page
11

of
13

3/18/2013

5.

RISKS

Project risks are documented in the Project Risks document. Regarding testing, the follo
wing
risks have been identified.

Risk Area:

Unit test coverage.

Risk:

Some of the command and controller objects do not have unit tests.

Consequence:

Unit test coverage is incomplete.

Rank:

Medium

Mitigation/Contingency:
Developers
need

to go back

and write the unit tests for these
objects.


Risk Area:

User acceptance testing.

Risk:

There have been no funded adopters for the user acceptance testing.

Consequence:

User acceptance testing is very informal.

Rank:

High

Mitigation/Contingency:
We are ask
ing participants from the SIG to participate in ad
-
hoc user acceptance testing.