<<Test Plan Document-SOW # optional>>

Document Change History

Version Number Date Contributor Description
V1.0 What changes (additions and
deletions) were made for this
version?
** Note to Document Author Red and blue text (with the exception of the title and document name above) in
this document is directed at the template user to describe processes, build standards and help build the document
from the template. All such red and blue text should be removed before submitting any formal documentation,
including both draft and/or final, deliverables. ****
0
<<PROJECT NAME- INSTITUTION
NAME>>
Test Plan
pdated !uly "#, "00$
<<Test Plan Document-SOW # optional>>
Table of Contents
1 INTRODUCTION..................................................................................................................................3
%.% &'()*........................................................................................................................................ +
1.1.1 In Scope....................................................................................................................................3
1.1.2 Out of Scope.............................................................................................................................3
%." ,A-./0 (1!*'/.2*.................................................................................................................. +
1.2.1 Primary O!ecti"e....................................................................................................................3
1.2.2 Secon#ary O!ecti"e................................................................................................................$
%.+ R(-*& A34 R*&)(3&.1.-./.*&..................................................................................................... #
1.3.1 De"eloper.................................................................................................................................$
1.3.2 %#opter.....................................................................................................................................$
1.3.3 Testin& Process 'ana&ement Team.........................................................................................$
%.# A&&5)/.(3& 6(R /*&/ *7*'/.(3.......................................................................................... 8
%.8 '(3&/RA.3/& 6(R /*&/ *7*'/.(3.......................................................................................... 8
%.9 4*6.3./.(3&.............................................................................................................................. 9
2 TEST METHODOLOG......................................................................................................................!
".% )R)(&*.................................................................................................................................... 9
2.1.1 O"er"ie(...................................................................................................................................)
2.1.2 *saility Testin&......................................................................................................................)
2.1.3 *nit Testin& +'ultiple,.............................................................................................................-
2.1.$ Iteration./e&ression Testin&....................................................................................................-
2.1.0 1inal release Testin&................................................................................................................-
2.1.) Testin& completeness 2riteria..................................................................................................3
"." /*&/ -*2*-&............................................................................................................................. :
2.2.1 4uil# Tests................................................................................................................................3
".".%.% -evel % ; 1uild Acceptance /ests.......................................................................................................:
".".%." -evel " ; &mo<e /ests........................................................................................................................ :
".".%.+ -evel "a ; 1ug Regression /esting....................................................................................................:
2.2.2 'ilestone Tests.........................................................................................................................5
".".".% -evel + ; 'ritical )ath /ests............................................................................................................... =
2.2.3 /elease Tests............................................................................................................................5
".".+.% -evel # ; &tandard /ests..................................................................................................................... =
".".+." -evel 8 ; &uggested /est.................................................................................................................... =
".+ 1> R*>R*&&.(3....................................................................................................................... =
".# 1> /R.A>*............................................................................................................................... =
".8 &&)*3&.(3 'R./*R.A A34 R*&5)/.(3 R*,.R*5*3/&..........................................................%0
".9 /*&/ '(5)-*/*3*&&............................................................................................................... %0
2.).1 Stan#ar# 2on#itions6.............................................................................................................17
2.).2 4u& /eportin& 8 Tria&e 2on#itions6....................................................................................17
3 TEST DELI"ERA#LES......................................................................................................................11
+.% 4*-.2*RA1-*& 5A/R.7............................................................................................................ %%
+." 4('5*3/&............................................................................................................................. %"
3.2.1 Test %pproac9 Document.......................................................................................................12
3.2.2 Test Plan.................................................................................................................................12
3.2.3 Test Sc9e#ule..........................................................................................................................13
3.2.$ Test Specifications..................................................................................................................13
3.2.0 /e:uirements Traceaility 'atri;.........................................................................................13
+.+ 4*6*'/ /RA'?.3> @ 4*1>>.3>............................................................................................ %+
3.3.1 Testin& Wor<flo(....................................................................................................................13
3.3.2 Defect reportin& usin& = 1O/=>.........................................................................................1$
+.# R*)(R/&.................................................................................................................................. %9
3.$.1 Testin& status reports.............................................................................................................1)
3.$.2 P9ase 2ompletion /eports.....................................................................................................1)
3.$.3 Test 1inal /eport - Si&n-Off...................................................................................................1)
%
<<Test Plan Document-SOW # optional>>
+.8 R*&)(3&.1.-./0 5A/R.7.......................................................................................................... %9
$ RESOURCE % EN"IRONMENT NEEDS.......................................................................................1!
#.% /*&/.3> /((-&........................................................................................................................ %9
$.1.1 Trac<in& Tools........................................................................................................................1)
#.%.%.% 'onfiguration 5anagement.............................................................................................................%$
#." /*&/ *32.R(35*3/................................................................................................................ %$
$.2.1 ?ar#(are................................................................................................................................1-
$.2.2 Soft(are..................................................................................................................................1-
#.+ 1> &*2*R./0 A34 )R.(R./0 4*6.3./.(3................................................................................ %$
$.3.1 Se"erity @ist............................................................................................................................1-
$.3.2 Priority @ist............................................................................................................................13
#.# 1> R*)(R/.3>....................................................................................................................... %:
& TERMS'ACRONMS.........................................................................................................................1(
"
<<Test Plan Document-SOW # optional>>
1 Intro)uct*on
his test a!!roach document descri"es the a!!ro!riate strategies# !rocess# wor$flows and
methodologies used to !lan# organi%e# e&ecute and manage testing of software !ro'ects within
ca()*.
1.1 Scope
Descri"e the current test a!!roach sco!e "ased on your role and !ro'ect o"'ectives.
1.1.1In Scope
he ca()* +wor$s!ace name, +system name, Test Plan defines the unit# integration# system#
regression# and Client -cce!tance testing a!!roach. he test sco!e includes the following.
esting of all functional# a!!lication !erformance# security and use cases re/uirements listed in
the Use Case document.
0uality re/uirements and fit metrics+system name,.
1nd2to2end testing and testing of interfaces of all systems that interact with the +system
name,.
1.1.2Out of Scope
he following are considered out of sco!e for ca()* +wor$s!ace name, +system name,
system est 3lan and testing sco!e.
4unctional re/uirements testing for systems outside +a!!lication name,
esting of (usiness 563s# disaster recovery and (usiness Continuity 3lan.
1.2Quality Objective
1.2.1Primary Objective
- !rimary o"'ective of testing a!!lication systems is to. assure that the system meets the full
requirements, including quality requirements (AKA: Non-functional requirements) and fit
metrics for each quality requirement and satisfies the use case scenarios and maintain
the quality of the product. -t the end of the !ro'ect develo!ment cycle# the user should find
that the !ro'ect has met or e&ceeded all of their e&!ectations as detailed in the re/uirements.
-ny changes# additions# or deletions to the re/uirements document# 4unctional 5!ecification#
or Design 5!ecification will "e documented and tested at the highest level of /uality allowed
within the remaining time of the !ro'ect and within the a"ility of the test team.
+
<<Test Plan Document-SOW # optional>>
1.2.2Secondary Objective
he secondary o"'ective of testing a!!lication systems will "e to. identify and expose all
issues and associated risks, communicate all knon issues to the pro!ect team, and
ensure that all issues are addressed in an appropriate matter "efore release. -s an
o"'ective# this re/uires careful and methodical testing of the a!!lication to first ensure all areas
of the system are scrutini%ed and# conse/uently# all issues ("ugs) found are dealt with
a!!ro!riately.

1.3Roles and Responsibilities

7oles and res!onsi"ilities may differ "ased on the actual 56W. (elow listed functions are for
testing !hase.
1.3.1Developer
-n 8C)2designated Cancer Center selected and funded "y 8C)C( to !artici!ate in a s!ecific
Wor$s!ace to underta$e software or solution develo!ment activities. 7es!onsi"le to.
(a) Develo! the system9a!!lication
(") Develo! :se cases and re/uirements in colla"oration with the -do!ters
(c) Conduct :nit# system# regression and integration testing
(d) 5u!!ort user acce!tance testing
1.3.2Adopter
-n 8C)2designated Cancer Center selected and funded "y 8C)C( to underta$e formal
ado!tion# testing# validation# and a!!lication of !roducts or solutions develo!ed "y Wor$s!ace
Develo!ers. 7es!onsi"le to.
(a) Contri"ute to :se case# re/uirement develo!ment through review
(") Contri"ute to develo! and e&ecution of the develo!ment test scri!ts through
review
(c) Conduct 4ull :ser -cce!tance# regression# and end2to2end testing; this
includes identifying testing scenarios# "uilding the test scri!ts# e&ecuting scri!ts
and re!orting test results
1.3.3Testing Process Management Team
)nclude 8C)# (-H and Cancer Center <eads allocated to the +wor$s!ace name,. *rou!
res!onsi"le to manage the entire testing !rocess# wor$flow and /uality management with
activities and res!onsi"ilities to.
(a) =onitor and manage testing integrity and 5u!!ort testing activities
(") Coordinate activities across cancer centers
-dd more as a!!ro!riate to testing sco!e
#
<<Test Plan Document-SOW # optional>>
1.4Assumptions for Test Execution
(elow are some minimum assum!tions (in "lac$) that has "e com!leted with some e&am!les
(in red). -ny e&am!le may "e used if deemed a!!ro!riate for the !articular !ro'ect. 8ew
assum!tions may also "e added that are reasoned to "e suita"le to the !ro'ect.
4or :ser -cce!tance testing# the Develo!er team has com!leted unit# system and integration
testing and met all the 7e/uirement>s (including /uality re/uirements) "ased on 7e/uirement
racea"ility =atri&.
:ser -cce!tance testing will "e conducted "y 1nd2users
est results will "e re!orted on daily "asis using *forge. 4ailed scri!ts and defect list from
*forge with evidence will "e sent to Develo!er directly.
:se cases have "een develo!ed "y -do!ters for :ser -cce!tance testing. :se cases are
a!!roved "y test lead.
est scri!ts are develo!ed and a!!roved.
est eam will su!!ort and !rovide a!!ro!riate guidance to -do!ters and Develo!ers to
conduct testing
=a'or de!endencies should "e re!orted immediately after the testing $ic$off meeting.
1.5 Constraints for Test Execution
(elow are some minimum assum!tions (in "lac$) followed "y e&am!le constraints (red). -ny
e&am!le may "e used if deemed a!!ro!riate for the !articular !ro'ect. 8ew constraints may
also "e added that are reasoned to "e suita"le to the !ro'ect.
-do!ters should clearly understand on test !rocedures and recording a defect or
enhancement. esting 3rocess =anagement eam will schedule a teleconference with
Develo!ers and -do!ters to train and address any testing related issues.
Develo!er will receive consolidated list of re/uest for test environment set u!# user accounts
set u!# data set (actual and moc$ data)# defect list# etc. through GForge after the initial
-do!ter testing $ic$ off meeting.
Develo!er will su!!ort ongoing testing activities "ased on !riorities

est scri!ts must "e a!!roved "y est <ead !rior test e&ecution
est scri!ts# test environment and de!endencies should "e addressed during testing $ic$off
meeting in !resence of a 5=1 and re/uest list should "e su"mitted within ? days of the $ic$off
meeting
he Develo!er cannot e&ecute the :ser -cce!tance and 1nd to 1nd test scri!ts. -fter
de"ugging# the develo!er can conduct their internal test# "ut no results from that test can "e
recorded 9 re!orted.
8
<<Test Plan Document-SOW # optional>>
-do!ters are res!onsi"le to identify de!endencies "etween test scri!ts and su"mit clear
re/uest to set u! test environment
1.6Defnitions
(ugs. -ny error or defect that cause the software9a!!lication or hardware to malfunction. hat
is also included in the re/uirements and does not meet the re/uired wor$flow# !rocess or
function !oint.
1nhancement.
1) -ny alteration or modification to the e&isting system for "etter wor$flow and !rocess.
@) -n error or defect that causes the software9a!!lication or hardware to malfunction.
Where 1) and @) is 86 included in the re/uirements can "e categori%ed as an enhancement.
1nhancement can "e added as a new re/uirement after a!!ro!riate Change =anagement
!rocess.
2 Te+t Metho)o,o-.
2.1Purpose
2.1.1Overview
he "elow list is not intended to limit the e&tent of the test !lan and can "e modified to "ecome
suita"le for the !articular !ro'ect.
he !ur!ose of the est 3lan is to achieve the following.
Define testing strategies for each area and su"2area to include all the functional and /uality
(non2functional) re/uirements.
Divide Design 5!ec into testa"le areas and su"2areas (do not confuse with more detailed
test s!ec). (e sure to also identify and include areas that are to "e omitted (not tested)
also.
Define "ug2trac$ing !rocedures.
)dentify testing ris$s.
)dentify re/uired resources and related information.
3rovide testing 5chedule.
2.1.2Usability Testing
he !ur!ose of usa"ility testing is to ensure that the new com!onents and features will
function in a manner that is acce!ta"le to the customer.
Develo!ment will ty!ically create a non2functioning !rototy!e of the :) com!onents to evaluate
the !ro!osed design. :sa"ility testing can "e coordinated "y testing# "ut actual testing must
"e !erformed "y non2testers (as close to end-users as possible). esting will review the
findings and !rovide the !ro'ect team with its evaluation of the im!act these changes will have
on the testing !rocess and to the !ro'ect as a whole.
9
<<Test Plan Document-SOW # optional>>
2.1.3Unit Testing (Multiple)
:nit esting is conducted "y the Develo!er during code develo!ment !rocess to ensure that
!ro!er functionality and code coverage have "een achieved "y each develo!er "oth during
coding and in !re!aration for acce!tance into iterations testing.
he following are the e&am!le areas of the !ro'ect must "e unit2tested and signed2off "efore
"eing !assed on to regression esting.
Data"ases# 5tored 3rocedures# riggers# a"les# and )nde&es
8 5ervices
Data"ase conversion
.6CA# .D<<# .1A1 and other "inary formatted e&ecuta"les
2.1.4Iteration/Regression Testing
During the re!eated cycles of identifying "ugs and ta$ing recei!t of new "uilds (containing "ug
fi& code changes)# there are several !rocesses which are common to this !hase across all
!ro'ects. hese include the various ty!es of tests. functionality# !erformance# stress#
configuration# etc. here is also the !rocess of communicating results from testing and
ensuring that new dro!s9iterations contain sta"le fi&es (regression). he !ro'ect should !lan
for a minimum of @2? cycles of testing (dro!s9iterations of new "uilds).
-t each iteration# a de"riefing should "e held. 5!ecifically# the re!ort must show that to the
"est degree achieva"le during the iteration testing !hase# all identified severity 1 and severity
@ "ugs have "een communicated and addressed. -t a minimum# all !riority 1 and !riority @
"ugs should "e resolved !rior to entering the "eta !hase.
(elow are e&am!les. -ny e&am!le may "e used if deemed a!!ro!riate for the !articular
!ro'ect. 8ew content may also "e added that are reasoned to "e suita"le to the !ro'ect.
)m!ortant delivera"les re/uired for acce!tance into 4inal 7elease testing include.
-!!lication 51:3.1A1
)nstallation instructions
-ll documentation ("eta test scri!ts# manuals or training guides# etc.)
2.1.5Final release Testing
esting team with end2users !artici!ates in this milestone !rocess as well "y !roviding
confirmation feed"ac$ on new issues uncovered# and in!ut "ased on identical or similar issues
detected earlier. he intention is to verify that the !roduct is ready for distri"ution# acce!ta"le
to the customer and iron out !otential o!erational issues.
-ssuming critical "ugs are resolved during !revious iterations testing2 hroughout the 4inal
7elease test cycle# "ug fi&es will "e focused on minor and trivial "ugs (severity ? and B).
esting will continue its !rocess of verifying the sta"ility of the a!!lication through regression
testing (e&isting $nown "ugs# as well as e&isting test cases).
he milestone target of this !hase is to esta"lish that the a!!lication under test has reached a
level of sta"ility# a!!ro!riate for its usage (num"er users# etc.)# that it can "e released to the
end users and ca()* community.
$
<<Test Plan Document-SOW # optional>>
2.1.6Testing completeness Criteria
7elease for !roduction can occur only after the successful com!letion of the a!!lication under
test throughout all of the !hases and milestones !reviously discussed a"ove.
he milestone target is to !lace the release9a!! ("uild) into !roduction after it has "een shown
that the a!! has reached a level of sta"ility that meets or e&ceeds the client e&!ectations as
defined in the 7e/uirements# 4unctional 5!ec.# and ca()* 3roduction 5tandards.
2.2Test Levels
esting of an a!!lication can "e "ro$en down into three !rimary categories and several su"2
levels. he three !rimary categories include tests conducted every "uild ((uild ests)# tests
conducted every ma'or milestone (=ilestone ests)# and tests conducted at least once every
!ro'ect release cycle (7elease ests). he test categories and test levels are defined "elow.
2.2.1Build Tests
2.2.1.1 Level 1 - Build Acceptance Tests
(uild -cce!tance ests should ta$e less than @2? hours to com!lete (1C minutes is ty!ical).
hese test cases sim!ly ensure that the a!!lication can "e "uilt and installed successfully.
6ther related test cases ensure that ado!ters received the !ro!er Develo!ment 7elease
Document !lus other "uild related information (dro! !oint# etc.). he o"'ective is to determine
if further testing is !ossi"le. )f any <evel 1 test case fails# the "uild is returned to develo!ers
un2tested.
2.2.1.2 Level 2 - Smoke Tests
5mo$e ests should "e automated and ta$e less than @2? hours (@0 minutes is ty!ical). hese
tests cases verify the ma'or functionality a high level.
he o"'ective is to determine if further testing is !ossi"le. hese test cases should em!hasi%e
"readth more than de!th. -ll com!onents should "e touched# and every ma'or feature should
"e tested "riefly "y the 5mo$e est. )f any <evel @ test case fails# the "uild is returned to
develo!ers un2tested.
2.2.1.3 Level 2a - Bug Regression Testing
1very "ug that was D6!enE during the !revious "uild# "ut mar$ed as D4i&ed# 8eeds 7e2estingE
for the current "uild under test# will need to "e regressed# or re2tested. 6nce the smo$e test is
com!leted# all resolved "ugs need to "e regressed. )t should ta$e "etween C minutes to 1
hour to regress most "ugs.
2.2.2Milestone Tests
2.2.2.1 Level 3 - Critical Pat Tests
Critical 3ath test cases are targeted on features and functionality that the user will see and use
every day.
Critical 3ath test cases must !ass "y the end of every @2? (uild est Cycles. hey do not need
to "e tested every dro!# "ut must "e tested at least once !er milestone. hus# the Critical 3ath
test cases must all "e e&ecuted at least once during the )teration cycle# and once during the
4inal 7elease cycle.
:
<<Test Plan Document-SOW # optional>>
2.2.3Release Tests
2.2.3.1 Level ! - Standard Tests
est Cases that need to "e run at least once during the entire test cycle for this release. hese
cases are run once# not re!eated as are the test cases in !revious levels. 4unctional esting
and Detailed Design esting (4unctional 5!ec and Design 5!ec est Cases# res!ectively).
hese can "e tested multi!le times for each =ilestone est Cycle ()teration# 4inal 7elease#
etc.).
5tandard test cases usually include )nstallation# Data# *:)# and other test areas.
2.2.3.2 Level " - Suggested Test
hese are est Cases that would "e nice to e&ecute# "ut may "e omitted due to time
constraints.
=ost 3erformance and 5tress est Cases are classic e&am!les of 5uggested test cases
(although some should "e considered standard test cases). 6ther e&am!les of suggested test
cases include W-8# <-8# 8etwor$# and <oad testing.
2.3Bug Regression
(ug 7egression will "e a central tenant throughout all testing !hases.
-ll "ugs that are resolved as D4i&ed# 8eeds 7e2estingE will "e regressed when esting team is
notified of the new dro! containing the fi&es. When a "ug !asses regression it will "e
considered DClosed# 4i&edE. )f a "ug fails regression# ado!ters testing team will notify
develo!ment team "y entering notes into *4orge. When a Seerit! " bug fails regression#
adopters Testing team should also put out an immediate email to deelopment. he est
<ead will "e res!onsi"le for trac$ing and re!orting to develo!ment and !roduct management
the status of regression testing.
2.4Bug Triage
(ug riages will "e held throughout all !hases of the develo!ment cycle. (ug triages will "e
the res!onsi"ility of the est <ead. riages will "e held on a regular "asis with the time frame
"eing determined "y the "ug find rate and !ro'ect schedules.
hus# it would "e ty!ical to hold few triages during the $lanning phase# then may"e one triage
!er wee$ during the Design phase# ram!ing u! to twice !er wee$ during the latter stages of
the Deelopment phase. hen# the 5ta"ili%ation !hase should see a su"stantial reduction in
the num"er of new "ugs found# thus a few triages !er wee$ would "e the ma&imum (to deal
with status on e&isting "ugs).
he est <ead# 3roduct =anager# and Develo!ment <ead should all "e involved in these triage
meetings. he est <ead will !rovide re/uired documentation and re!orts on "ugs for all
attendees. he !ur!ose of the triage is to determine the ty!e of resolution for each "ug and to
!rioriti%e and determine a schedule for all Do (e 4i&ed (ugs>. Develo!ment will then assign
the "ugs to the a!!ro!riate !erson for fi&ing and re!ort the resolution of each "ug "ac$ into
the *4orge "ug trac$er system. he est <ead will "e res!onsi"le for trac$ing and re!orting
on the status of all "ug resolutions.
=
<<Test Plan Document-SOW # optional>>
2.5Suspension Criteria and Resumption Requirements
his section should "e defined to list criteria>s and resum!tion re/uirements should certain
degree and !re2defined levels of test o"'ectives and goals are not met.
3lease see e&am!le "elow.
2 esting will "e sus!ended on the affected software module when 5mo$e est (<evel 1) or
Critical 3ath (<evel @) test case "ugs are discovered after the ?
rd
iteration.
2 esting will "e sus!ended if there is critical sco!e change that im!acts the Critical 3ath
- "ug re!ort should "e filed "y Develo!ment team. -fter fi&ing the "ug# Develo!ment team will
follow the dro! criteria (descri"ed a"ove) to !rovide its latest dro! for additional esting. -t
that time# ado!ters will regress the "ug# and if !asses# continue testing the module.
2.6Test Completeness
esting will "e considered com!lete when the following conditions have "een met.
2.6.1Standard Conditions:
When -do!ters and Develo!ers# agree that testing is com!lete# the a!! is sta"le# and
agree that the a!!lication meets functional re/uirements.
5cri!t e&ecution of all test cases in all areas have !assed.
-utomated test cases have in all areas have !assed.
-ll !riority 1 and @ "ugs have "een resolved and closed.
8C) a!!roves the test com!letion
1ach test area has "een signed off as com!leted "y the est <ead.
C0F of all resolved severity 1 and @ "ugs have "een successfully re2regressed as final
validation.
-d hoc testing in all areas has "een com!leted.
2.6.2Bug Reporting & Triage Conditions:
3lease add (ug re!orting and triage conditions that will "e su"mitted and evaluated to
measure the current status.
(ug find rate indicates a decreasing trend !rior to Gero (ug 7ate (no new 5ev. 19@9? "ugs
found).
(ug find rate remains at 0 new "ugs found (5everity 19@9?) des!ite a constant test effort
across ? or more days.
(ug severity distri"ution has changed to a steady decrease in 5ev. 1 and @ "ugs
discovered.
8o H=ust 4i&> "ugs remaining !rior des!ite sustained testing.
3 Te+t De,*/er01,e+
esting will !rovide s!ecific delivera"les during the !ro'ect. hese delivera"les fall into three
"asic categories. Documents# est Cases 9 (ug Write2u!s# and 7e!orts. Here is a diagram
indicating the de!endencies of the various delivera"les.
%0
<<Test Plan Document-SOW # optional>>
ReAuire;
ments B)5C
)roDect )lan
B)5C
6unctional
&pec B)5C
/est )lan
/est &pec.
/ (utline
4etailed
4esign
B4evC
/est
'ases
1ugs
1ug
Results
/' 'overage
Reports
1ug Reports
Eee<ly
&tatus
Reports
/est 'ase
Results
-s the diagram a"ove shows# there is a !rogression from one delivera"le to the ne&t. 1ach
delivera"le has its own de!endencies# without which it is not !ossi"le to fully com!lete the
delivera"le.
he following !age contains a matri& de!icting all of the delivera"les that esting will use.
3.1Deliverables Matrix
(elow is the list of artifacts that are !rocess driven and should "e !roduced during the testing
lifecycle. Certain delivera"les should "e delivered as !art of test validation# you may add to the
"elow list of delivera"les that su!!ort the overall o"'ectives and to maintain the /uality.
his matri& should "e u!dated routinely throughout the !ro'ect develo!ment cycle in you
!ro'ect s!ecific est 3lan.
Delierable
Documents
est -!!roach
est 3lan
est 5chedule
est 5!ecifications
Test Case % &ug Write-'ps
est Cases 9 7esults
est Coverage 7e!orts
*4orge (ug trac$er for "ug re!orting
(eports
%%
<<Test Plan Document-SOW # optional>>
est results re!ort
est 4inal 7e!ort 2 5ign26ff
3.2Documents
3.2.1Test Approach Document
he est -!!roach document is derived from the 3ro'ect 3lan# 7e/uirements and 4unctional
5!ecification documents. his document defines the overall test a!!roach to "e ta$en for the
!ro'ect. he 5tandard est -!!roach document that you are currently reading is a "oiler!late
from which the more s!ecific !ro'ect est -!!roach document can "e e&tracted.
When this document is com!leted# the est <ead will distri"ute it to the 3roduct =anager#
Develo!ment <ead# :ser 7e!resentative# 3rogram =anager# and others as needed for review
and sign2off.
3.2.2Test Plan
he est 3lan is derived from the est -!!roach# 7e/uirements# 4unctional 5!ecs# and
detailed Design 5!ecs. he est 3lan identifies the details of the test a!!roach# identifying the
associated test case areas within the s!ecific !roduct for this release cycle.
he !ur!ose of the est 3lan document is to.
5!ecify the a!!roach that esting will use to test the !roduct# and the delivera"les (e&tract
from the est -!!roach).
(rea$ the !roduct down into distinct areas and identify features of the !roduct that are to
"e tested.
5!ecify the !rocedures to "e used for testing sign2off and !roduct release.
)ndicate the tools used to test the !roduct.
<ist the resource and scheduling !lans.
)ndicate the contact !ersons res!onsi"le for various areas of the !ro'ect.
)dentify ris$s and contingency !lans that may im!act the testing of the !roduct.
5!ecify "ug management !rocedures for the !ro'ect.
5!ecify criteria for acce!tance of develo!ment dro!s to testing (of "uilds).
3.2.3Test Schedule
his section is not vital to the document as a whole and can "e modified or deleted if needed
"y the author.
he est 5chedule is the res!onsi"ility of the est <ead (or De!artment 5cheduler# if one
e&ists) and will "e "ased on information from the 3ro'ect 5cheduler (done "y 3roduct
=anager). he !ro'ect s!ecific est 5chedule may "e done in =5 3ro'ect.
3.2.4Test Specifcations
- est 5!ecification document is derived from the est 3lan as well as the 7e/uirements#
4unctional 5!ec.# and Design 5!ec documents. )t !rovides s!ecifications for the construction
%"
<<Test Plan Document-SOW # optional>>
of est Cases and includes list(s) of test case areas and test o"'ectives for each of the
com!onents to "e tested as identified in the !ro'ect>s est 3lan.
3.2.5Requirements Traceability Matrix
- 7e/uirements racea"ility =atri& (7=) which is used to lin$ the test scenarios to the
re/uirements and use cases is a re/uired !art of the est 3lan documentation for all !ro'ects.
7e/uirements tracea"ility is defined as the a"ility to descri"e and follow the life of a
re/uirement# in "oth a forward and "ac$ward direction (i.e. from its origins# through its
develo!ment and s!ecification# to its su"se/uent de!loyment and use# and through !eriods of
ongoing refinement and iteration in any of these !hases).
1
-ttached is a sam!le "asic 7= which could !rovide a starting !oint for this documentation.
he im!ortant thing is to choose a tem!late or document "asis that achieves thorough
tracea"ility throughout the life of the !ro'ect.
C:\Documents and
Settings\523217\My Documents\caBIG\02 Delivey Management Coss\01!"em#lates\$inal %osted &l'esco Docs 1(&ug0(\)#dated *it+ ne* logo , uly 2007\%o-ect Management "em#lates\."M/"em#late01ls
3.3Defect Tracking & Debugging
3.3.1Testing Workfow
he "elow wor$flow illustrates the testing wor$flow !rocess for Develo!ers and -do!ters for
:ser -cce!tance and 1nd to 1nd testing.
3l. note the yellow highlighted !rocess where the -do!ter is re/uired to directly send defect list
with evidence to the Develo!er. 5imilarly# Develo!er is re/uired to confirm directly with the
-do!ter after "ug fi&es along with u!dating on the (ug%illa.
%
httpF//www.proDectperfect.com.au/infoGreAuirementsGtraceability.php
%+
<<Test Plan Document-SOW # optional>>
3.3.2Defect reporting using G FORGE
-<< defects should "e logged using H* 467*1># to address and de"ug defects. -do!ters are
also re/uested to send a daily defect re!ort to the develo!er. Develo!ers will u!date the defect
list on * 4orge and notify the re/uestor after the defect has "een resolved.
Develo!ers and -do!ters are re/uired to re/uest an account on * 4orge for the relative
wor$s!ace. De"ugging should "e "ased on 3riority I High , =edium , <ow# these !riorities
are set "y the -do!ters and are "ased on how critical is the test scri!t in terms of de!endency
and mainly "ased on use case scenario.
(elow screen shot dis!lays H-dd new Defect> screen# fields mar$ed with ( J ) are mandatory
fields and -do!ters should also u!load the evidence file for all the defects listed.
-ll )igh priorit! defects should "e addressed within 1 day of the re/uest and resolved9closed
within @ days of the initial re/uest
-ll *edium priorit! defects should "e addressed within @ days of the re/uest and
resolved9closed within B days of the initial re/uest
-ll +o, priorit! defects should "e resolved9closed no later than C days of the initial re/uest.
* 4orge :7< 2 htt!.99gforge.nci.nih.gov
:ser may either search for wor$s!ace or select from list of recent !ro'ect from the "ottom right
side of the window. 1.g. searching for Hcaties>.
-t the wor$s!ace# the user can re/uest -dministrators to setu! their user account for that
wor$s!ace.
-fter login# user can select Hrac$er> ta" to H5u"mit 8ew> defect. :ser can add defect info. -s
shown in "elow screen.
%#
<<Test Plan Document-SOW # optional>>
Field Comments
Hardware 2 <ist the testing environment hardware. e.g. 3C# =-C
3roduct 2 -dd default to wor$s!ace name e.g. ca)15
6!erating 5ystem 2 Win KL# Win @$# Win A3# =-C# etc.
Version 2 -!!lication version
5everity 2 )f it is an enhancement or a "ug with minor to ma'or severity that
may not interfere with further testing or com!letely "loc$ any future testing
efforts.
7esolution 2 6nly D1V1<6317 will u!date "ased on the defect
=odule 2 4or an a!!lication with multi!le modules# select a!!ro!riate
module for the defect re!orted.
:7< 2 -dd :7< if any
-ssigned to 2 o "e u!dated "y Develo!er# for whom the tic$et is assigned
to
3riority 2 5et a !riority "ased on severity
5ummary 2 5ummary of the defect# "ug or issue
Detailed Desc. 2 Details of the defect# "ug or issue
:!load file 2 -ttach evidence file
%8
<<Test Plan Document-SOW # optional>>
5u"mit 2 5u"mit the "ug tic$et
3.4Reports
he est <ead will "e res!onsi"le for writing and disseminating the following re!orts to
a!!ro!riate !ro'ect !ersonnel as re/uired.
3.4.1Testing status reports
- wee$ly or "i2wee$ly status re!ort will "e !rovided "y the est <ead to !ro'ect !ersonnel. his
re!ort will summari%e wee$ly testing activities# issues# ris$s# "ug counts# test case coverage#
and other relevant metrics.
3.4.2Phase Completion Reports
When each !hase of testing is com!leted# the est <ead will distri"ute a 3hase Com!letion
7e!ort to the 3roduct manager# Develo!ment <ead# and 3rogram =anager for review and
sign2off.
he "elow "ullets illustrates an e&am!le of what the document may include.
he document must contain the following metrics.
otal est Cases# 8um"er 1&ecuted# 8um"er 3asses 9 4ails# 8um"er Met to 1&ecute
8um"er of (ugs 4ound to Date# 8um"er 7esolved# and 8um"er still 6!en
(rea$down of (ugs "y 5everity 9 3riority =atri&
Discussion of :nresolved 7is$s
Discussion of 5chedule 3rogress (are we where we are su!!osed to "e?)
3.4.3Test Final Report - Sign-Of
- 4inal est 7e!ort will "e issued "y the est <ead. )t will certify as to the e&tent to which
testing has actually com!leted (test case coverage re!ort suggested)# and an assessment of
the !roduct>s readiness for 7elease to 3roduction.
3.5Responsibility Matrix
)nsert testing resource matri& I who is involved and what is the role.
$ Re+ource % En/*ronment Nee)+
4.1Testing Tools
4.1.1Tracking Tools
*4orge "ug trac$er is used "y ca()* to enter and trac$ all "ugs and !ro'ect issues. he est
<ead is res!onsi"le for maintaining the *4orge data"ase.
%9
<<Test Plan Document-SOW # optional>>
!.1.1.1 Con#iguration $anagement
3lease include your configuration management !lan
4.2Test Environment
4.2.1Hardware
)nclude the minimum hardware re/uirements that will "e used to test the -!!lication.
esting will have access control to one or more a!!lication9data"ase servers se!arate from
any used "y non2test mem"ers of the !ro'ect team. esting will also have access control to an
ade/uate num"er of variously configured 3C wor$stations to assure testing a range from the
minimum to the recommended client hardware configurations listed in the !ro'ect>s
7e/uirements# 4unctional 5!ecification and Design 5!ecification documents.
4.2.2Software
)n addition to the a!!lication and any other customer s!ecified software# the following list of
software should "e considered a minimum.
8 Wor$station B.0 or Windows KC.
=5 6ffice KC 3rofessional
=5 1&change
C= (esting ool 5erver)
as$ =anager (esting ool 5erver)
4.3Bug Severity and Priority Defnition
(ug 5everity and 3riority fields are "oth very im!ortant for categori%ing "ugs and !rioriti%ing if
and when the "ugs will "e fi&ed. he "ug 5everity and 3riority levels will "e defined as
outlined in the following ta"les "elow. esting will assign a severity level to all "ugs. he est
<ead will "e res!onsi"le to see that a correct severity level is assigned to each "ug.
he est <ead# Develo!ment <ead and 3rogram =anager will !artici!ate in "ug review
meetings to assign the !riority of all currently active "ugs. his meeting will "e $nown as D(ug
riage =eetingsE. he est <ead is res!onsi"le for setting u! these meetings on a routine
"asis to address the current set of new and e&isting "ut unresolved "ugs.
4.3.1Severity List
he tester entering a "ug into *4orge is also res!onsi"le for entering the "ug 5everity.
Seerit! -D Seerit! Seerit! Description
1 Critical he module9!roduct crashes or the "ug causes non2recovera"le
conditions. 5ystem crashes# *3 4aults# or data"ase or file corru!tion#
or !otential data loss# !rogram hangs re/uiring re"oot are all e&am!les
of a 5ev. 1 "ug.
@ High =a'or system com!onent unusa"le due to failure or incorrect
functionality. 5ev. @ "ugs cause serious !ro"lems such as a lac$ of
functionality# or insufficient or unclear error messages that can have a
%$
<<Test Plan Document-SOW # optional>>
ma'or im!act to the user# !revents other areas of the a!! from "eing
tested# etc. 5ev. @ "ugs can have a wor$ around# "ut the wor$ around
is inconvenient or difficult.
? =edium )ncorrect functionality of com!onent or !rocess. here is a sim!le wor$
around for the "ug if it is 5ev. ?.
B =inor Documentation errors or signed off severity ? "ugs.
4.3.2Priority List
$riorit! $riorit! +eel $riorit! Description
C =ust 4i& his "ug must "e fi&ed immediately; the !roduct cannot shi! with this
"ug.
B 5hould 4i& hese are im!ortant !ro"lems that should "e fi&ed as soon as
!ossi"le. )t would "e an em"arrassment to the com!any if this "ug
shi!!ed.
? 4i& When Have
ime
he !ro"lem should "e fi&ed within the time availa"le. )f the "ug
does not delay shi!!ing date# then fi& it.
@ <ow 3riority )t is not im!ortant (at this time) that these "ugs "e addressed. 4i&
these "ugs after all other "ugs have "een fi&ed.
1 rivial 1nhancements9 *ood to have features incor!orated2 'ust are out of
the current sco!e.
4.4Bug Reporting
esting team recogni%es that the "ug re!orting !rocess is a critical communication tool within
the testing !rocess. Without effective communication of "ug information and other issues# the
develo!ment and release !rocess will "e negatively im!acted.
he est <ead will "e res!onsi"le for managing the "ug re!orting !rocess. esting>s standard
"ug re!orting tools and !rocesses will "e used. *4orge is the com!any2wide standard (ug
<ogging 9 rac$ing tool. esting and develo!ment will enter their data into the *4orge
data"ase following the field entry definitions defined "elow.
& Term+'Acron.m+
he "elow terms are used as e&am!les# !lease add9remove any terms relevant to the
document.
T.(*%/C(0N1* D.F-N-T-0N
-3) -!!lication 3rogram )nterface
(-H (oo% -llen Hamilton
(C3 (usiness Continuity 3lan
C- Client -cce!tance esting
1nd2to 1nd esting ests user scenarios and various !ath conditions "y verifying
that the system runs and !erforms tas$s accurately with the
same set of data from "eginning to end# as intended.
%:
<<Test Plan Document-SOW # optional>>
T.(*%/C(0N1* D.F-N-T-0N
17;15 1lectronic 7ecords; 1lectronic 5ignatures
89- 8ot -!!lica"le
8C) 8ational Cancer )nstitute
0- 0uality -ssurance
7= 7e/uirements racea"ility =atri&
5=1 5u"'ect =atter 1&!ert
563 5tandard 6!erating 3rocedure
(3 issue (an$ and 3athology ools
(D o (e Determined
57 est 5ummary 7e!ort
%=