Template Test Plan Development Tests v1 0

TEMPLATE TEST PLAN DEVELOPMENT TESTS
Author Version Location Characteristics
SC 1.0 Vianen
Template test plan development tests Version information
VERSION INFORMATION
Version Date Remarks /Notes Author
Copyright Sogeti. This work or any part thereof! may not "e reproduced and#or pu"lished for whatever purpose! in print$ %hotocopy$ microfilm$ audio tape$ electronically or in any other way whatsoever without prior written permission from Sogeti. T&ap is a registered trademark of Sogeti 'ederland (.V.
Sogeti 'ederland (.V. August$ *1$ *00+
1.0 ))
DISTRIBUTION LIST
Name Company/function
Sogeti 'ederland (.V. August$ *1$ *00+ Template test plan development tests
1.0 )))
Template test plan development tests
1.0 )))
APPROVAL CLIENT
,, -ptional. /se this section to store written approvals if a hardcopy approval is re0uired from the client. 11 Client.
'ame.
2ivision.
2epartment.
3unction.
Location.
Telephone.
45&ail address.
2ate. Signature.
1.0 )V
1.0 )V
1.0 V
1.0 V
MANAGEMENT SUMMARY
Project objective ,61 Test objective and assignment ,61 hort description of the test approach ,61 Resu!ts to be rea!i"ed Result , e7ample. well e7ecuted and finished development test1 Document 2T Test report Delivery date ,mm5dd5 yyyy1
#ua!itative objectives ,e7ample. 4ach test level needs to "e completed on time and it needs to clearly state for each system o"8ect if it meets the acceptance criteria1 $stimate ,61 Test process risks and measures Test process risks 9 ,61 Mitigations 9 ,61
%oments of go/no&go decisions , 47ample. After each test level the test coordinator makes sure that a test report is drawn up. This report will$ after review with the pro8ect manager and test manager$ "e presented to the steering committee. The steering committee decides if it is possi"le to proceed to the ne7t test level.1
1.0 V)
1.0 V)
TABLE OF CONTENTS
VERSION INFORMATION......................................................................II DISTRIBUTION LIST..........................................................................III APPROVAL CLIENT...........................................................................IV MANAGEMENT SUMMARY....................................................................VI TABLE OF CONTENTS.......................................................................VII INTRODUCTION...............................................................................1 DOCUMENTATION.............................................................................4 3TEST STRATEGY.............................................................................5 APPROACH.....................................................................................7 INFRASTRUCTURE.............................................................................9 MANAGEMENT / CONTROL PHASE........................................................10 ESTIMATES & PLANNING....................................................................11 APPENDI 1 ! PRODUCT RIS" ANALYSIS..................................................13
1.0 V))
1.0 V))
INTRODUCTION
1.1
Objective of t e !eve"o#$e%t te&t #"'%
<< descri"e the o"8ective of the test plan$ as agreed to with the client. The te7t "elow can "e used as e7ample. 'ote. This test plan is for only for one test level or one of the development test levels for e7ample /nit )ntegration Test /)T!!. 11 The o"8ective of this Test %lan T%! for ,test level1 is to inform all who are involved in the test process a"out the approach$ the activities and the delivera"les concerning ,test level1 for ,pro8ect and#or assignment1. This test plan descri"es a concrete and more detailed ela"oration of what has "een descri"ed in the master test plan :reference; for the ,test level1.
1.( 1.2.1
A&&i)%$e%t Client
,The client is1 ,, The party that commissioned the creation of the test plan and the e7ecution of the development tests$ see T&ap< 'e7t =.>.1 11
1.2.2
Supplier
,The supplier is1 ,, The one who is responsi"le for creating the test plan and e7ecuting the test assignment$ see T&ap< 'e7t =.>.1 11
1.2.3
Assignment
,, The result to "e o"tained what will "e delivered! and goal what does the client want! of the system and acceptance tests. This is the responsi"ility of the client$ see T&ap< 'e7t =.>.1 11
1.2.4
Scope
?ive a short description of the application and the main changes in the new version if applica"le! as well as the limitations of the development tests. 'ithin scope( ,, 2escri"e what@s )ithin the assignment in detailed terms like pro8ects$ systems$ releases$ versions and test levels#activities. See T&ap< 'e7t =.*.= 11 *ut of scope( ,, 2escri"e the systems$ interfaces$ test levels#activities$ etc. that are outside of the assignment. Also mention who@s responsi"le. See T&ap< 'e7t =.*.= 11
1.2.5
Preconditions and assumptions
The list "elow is an e7ample. The test coordinator has to which preconditions and assumptions are relevant for each area. 3or each precondition there has to "e
Sogeti 'ederland (.V. August$ *1$ *00+ 1.0 1
conformity with the pro8ect manager of the commissioning organiAation a"out the e7pectancy of the pro8ect. The following demands apply to the test process. ,, 3or e7ample This test plan is part of the total test approach as descri"ed in the master test plan of ,name system#application1. The milestones as descri"ed in the master test plan name$ version and date of the master test plan!. 11 To make the test process successful the following things need to "e arranged. ,, 3or e7ample Agreements as made in a master contract#service contract 6B Agreements concerning the usage of and access to test environmentsB Stakeholders from the user organiAation will make real life test scenarioCs in order to verify the user5friendliness of ,name and version of the application1B Test strategy and test approach are in line with the commissioning organiAationB Commissioning organiAation makes sure there is the following support in domain knowledge. descri"e roles$ agreed effort and su"8ects of e7pertiseB %ro8ect manager of the commissioning organiAation makes sure that suita"le copies of production files for ,name application1$ and possi"le other connected systems are deliveredB 2emonstrate "y means of reports that the ,preceding test level1 has "een concluded$ and that the e7it criteria of this test level have "een metB 4ntry criteria for the ,test level1 have to "e complied "efore the e7ecution of the ,test level1 can start. 11
1.2.6
Accepted by and acceptance criteria
:Deference. T&ap< 'e7t E.*.*; Accepted by

Name +unction Department
Acceptance criteria The acceptance criteria for system and acceptance tests are.
Description Norm
%oment of re!ease ,, The acceptance release for the ne7t test level! will take place after a go#no go meeting organiAed "y the pro8ect manager#client. The starting point at this meeting is the test report. -r
Sogeti 'ederland (.V. August$ *1$ *00+ 1.0 *
Delease for ,ne7t test level 1 will take place after the verification that the ,e7it5 or acceptance1criteria are met. The test report will report the results "ased on the criteria set forth in the test plan. The decision to release will "e taken "y the ,client1$ who@s founding his decision partly! on the test report. 11
1.0 >
DOCUMENTATION
)n this chapter common used documents are descri"ed in relation to development testing. ?enerally these documents are also used for the development "asis. -ther documents with a relationship to the &aster Test %lan need to "e descri"ed in detail. ,, Deference. T&ap< 'e7t =.>.1 en =.>.F11
1.*
Te&t P"'% B'&i&
,,2ocuments that are used to create the Test %lan are listed here. 3or 47ample. &T% &aster Test %lan!$ %ro8ect %lan or %ro8ect Approach %lan$ or other specific %ro8ect5 or Test %lanning$ or an )mplementation %lan!11 The following documents are used to create this Test %lan.
Document Name &aster Test %lan Version Date Author
1.+
Te&t B'&i&
,, This Deferenced the documents that are used as a starting point for testing. 2ocuments like. 3unctional 2esign$ Technical 2esign$ 2ata &odels$ System Architecture$ manuals$ Gold@ test ware and other products from the 2evelopment phase. These documents are more detailed than the &T%. 11 The Test (asis is a com"ination of documents that are used to create Test Cases that will "e e7ecuted. The following documents are used to create the Test Cases.
Document Name Version Date Author
1.0 F
TEST STRATEGY
The availa"le time to test is limitedB not everything can "e tested to the same amount of detail. Choices need to "e made. The aim is to divide the Test capacity as effectively and efficiently possi"le over the whole test time frame. This is documented in the &T% in the Test strategy section for the whole pro8ect. The Test strategy details what is going to be tested, with what depth, and when per Test Level! it@s going to "e tested. )t@s focused on finding the most important defects as early as possi"le$ in other words ma7imum usage of availa"le capacity and time. The first step when creating the Test strategy in the &T% is doing a Disk Analysis. The results from that %DA %roduct Disk Analysis! are reflected in the Appendi7 1. Delevant for the ,Test Level1! )n this Test plan more detail is given for the ,Test Type1 mentioned in the &T% Test Strategy. See H>.1. )n chapter F the result of this test approach and the how is "eing e7plained. ,, See also G2etermining the Test Strategy@. T&ap< 'e7t =.>.1 I p>JE 11
1.,
Te&t St-'te). Deve"o#$e%t Te&t&
The entry for each column ,Test Level1 has to match the same column in the &T%. Any deviations from the &T% Strategy ta"le have to comply with the following conditions. They have to "e agreed upon with the customer The choice has "een made not to update the &T% otherwise the ta"le wouldn@t deviate from the Strategy ta"le from the new &T%! The deviations are "eing accepted and an e7ception motivation is documented in regards to the (2T& aspects. Desult$ Disk$ Time K &oney! The deviations are displayed as follows. Test lighter than the &T%. from average testing to lighter testing$ the white dot indicates what$ in depth is no longer "eing tested! Test heavier more depth! than the &T%. from lighter testing to average testing$ the underlined "lack dot indicates what is "eing tested more heavily # in more depth!. ,, The entries in the ta"le "elow are 4LA&%L4S -'LM. Deference. T&ap< 'e7t also see page 1=J#1=E for more e7amples!. Although T&ap< 'e7t doesn@t do this the ta"le could "e e7panded on the left! with a column that reflects Test ?oals. communication to the clientN!. -"viously the ta"le would contain more colums. The layout of the ta"le "elow is different from the ta"les displayed in chapter E. The information is the same. The ta"le is displayed in this way "ecause is resem"les the Strategy ta"le from the &T%. This ta"le is usually received as "eing clearer. )n the current Test &anager! courses the ta"le layout is as displayed "elow. 11
Characteristics Sogeti 'ederland (.V. August$ *1$ *00+ RC %TP ,N-T %TP .$/amp!e( va!idation creen .$/amp!e( Database .$/amp!e( %odu!e units0 1.0 J
routines0 3unctionality ,A#(#C1 ,# # #S# )1 %erformance online %erformance "atch ,61 ,A#(#C1 ,A#(#C1 ,A#(#C1 ,51 ,A#1
routines0 ,(#1 ,A#1
,A#1
,C#1
,Additional information for the ta"le a"ove.

DC &T% /')T &T% S ,n#a1 Disk class assigned to the characteristic from within the &T% 2epth of testing allocated from within the &T% Light Testing Average Testing Thorough Testing Static Testen. Checking and inspecting products without running software This means that the relevat evaluation or Test Level can ignore the characteristics. ,, Sometimes one chooses to reflect all characteristics from the &T% Strategy ta"le. Ohen this is the case ,n#a1 could mean that some items are "eing tested in other Test Levels. Another option is '-T to reflect some of the characteristics in the ta"le "ut only the ones that might influence the characteristic. Then there are no ,n#a1 cells. 111
1 ,, Ohen applica"le. the motivation to deviate from the &T% Strategy ta"le needs to "e documented. Ohy$ what is the impact$ et ceteraP )n regards to the (2T& aspects. Desult$ Disk$ Time K &oney. Deference. T&ap< 'e7t J.*.F en =.>.1 11
1.0 E
APPROAC/
)n this chapter the translation is "eing done from the Gwhat@ development Test Level Test Strategy! to the GQow@. ,, &ake sure that the Test Approach reflects the Test Strategy from the previous chapterN 4very element from the Test Strategy must "e reflected here tooN This paragraph will "e more detailed that the &T% refer to the &T% where applica"le!.
1.0
E1ec2tio% Te&t St-'te).
The Test Strategy from the previous chapter is given more detail in this paragraph. ,, )mportant. The te7t "elow is -'LM an indication of what the amount of detail is needed to descri"e the test steps that are going to "e e7ecuted. 11
1.6.1
Unit Test UT!
The development team e7ecutes the /nit Test in the development environment. )t is determined if for each modified program after the modification has "een made$ if the program is working correctly and according to the technical specifications. The focus is on part of the program not on the whole program. The development team needs to focus on the items that are specified in the Strategy &atri7 for the /T. The development team will also report on these items in their development report. ,, 2iscuss with the development team which part of the /T Test Strategy they are going to "e responsi"le for and document these specific items. 11
1.6.2
Unit "ntegration Test U"T!
The development team e7ecutes the /nit )ntegration Test in the development environment. )t is determined if for each modified program after the modification has "een made$ if the program as a whole or logical group of units is working correctly and according to the technical specifications. The focus is on integration of the programs. The development team needs to focus on the items that are specified in the Strategy &atri7 for the /)T. The development team will also report on these items in their development report. ,, 2iscuss with the development team which part of the /)T Test Strategy they are going to "e responsi"le for and document these specific items. 11
1.0 =
1.3
Deve"o#$e%t Te&ti%) P '&e&

Preparation pecification $/ecution Comp!etion
Contro! Ctr! P!an Prep V pec -nfra $/ec , Comp A
P!anning
etting up and maintaining -nfrastucture
)n the P!anning phase the Test coordinator and the client esta"lish the assignment. The determined approach is documented in the Test %lan. 2uring the Contro! phase activities from the Test %lan are e7ecuted$ monitored$ reported$ and ad8usted. The etting up and maintain -nfrastructure phase is used to specify$ realiAe$ maintain and preserve the )nfrastructure for the different T&ap< phases and activities. The goal of the Preparation phase is to create check lists$ collect and assess the test "asis to ensure that the test "asis has sufficient 0uality to create test cases. )n the pecification phase the tests are specified. These tests are then e7ecuted in the $/ecution phase. That@s how insight is created in the 0uality of the test o"8ect. )n the Comp!etion phase the test process is evaluated lesson learned and other e7periences are documented!$ the testware is preserved and can "e re5used in a future assignment.
1.4
E%t-. '%! E1it c-ite-i'
,, 'ote. -nly a few Test Levels are mentioned here as an 4LA&%L4. All Test Levels entry and e7it criteria have to "e specified here. 11 2ocument all entry and e7it criteria. These should "e in aligned with the &T% and confirmed with the creator of the System Test %lan and the creator of the Acceptation Test %lan. 2etected defects will "e fi7ed "efore the software is moved into System 5 and acceptation Test. 4very statement in the code is validated at least once within development testing.
1.0 +
INFRASTRUCTURE
,, Deference. T&ap< 'e7t =.>.> 11 -nly document the deviations from the &T% if there are specific re0uirements for the 2evelopment Tests in regards to the 2evelopment process.
1.5
Te&t E%vi-o%$e%t&
,, 2efine what the re0uirements are for each Test Level. 11
1.#.1
Unit Test
De0uired Test environment s!. QardwareB System SoftwareB Communication mediaB Tools for creating files and data"asesB %roceduresB -ther and Dules and regulations.
1.16
Te&t too"&
2ocument per test level which Test Tools are needed. Qigh level "ecause the actual detail will "e in the detailed Test %lans. See checklists on www.tmap.net
Test 1eve! Test Too! Notes
1.11
7o-8 #"'ce
2ocument per test level what sort of work place is needed. Qigh level "ecause the actual detail will "e in the detailed Test %lans. See checklists on www.tmap.net.
Test 1eve! Components Notes
1.0 R
MANAGEMENT 9 CONTROL P/ASE

,, Deference. T&ap< 'e7t =.>.* -nly document the deviations from the &T%. 11
1.1(
Te&t P-oce&& Co%t-o"
%rogress and Suality of the Test %rocess are monitored "y the Test Coordinator # Test Lead. %rogress Deports are e5mailed to the %ro8ect5 and or Test &anager on a weekly "asis. The %rogress#Status report provides an overview of Test %rogress and the current Status of the System#Software that is "eing tested.
1.1*
Defect M'%')e$e%t
,)n the /nit Test %hase defects will "e fi7ed and re5tested when detected. These defects will not "e documented unless that unit is already "eing tested outside the development environment. 1
1.0 10
ESTIMATES : PLANNING
The planning and estimates for the ,Test Type1 need to "e in line with the &T%. )f there are any deviations they need to "e communicated to the$ including the reasons for the deviation s!.. )mpact$ Disk$ Time K &oney! The overview "elow is a detailed overview on Test %lan Level. A higher level of detail can "e applied if needed. ,, Deference. T&ap< 'e7t =.>.111
1.1+
E&ti$'te&
,, The Test Type hours estimates should "e copied from the &T%. 11
'ho Test Coordinator Test Specialists %rogrammers Technical &anagement Tota!s( P!an Ctr! Prep pec $/ec Comp Tota!s
,, 47plain here how the estimate is "roken down. Ohich estimate techni0ue was used if applica"le! or which documents were used for input. 3or e7ample. (uild estimate! Also descri"e what the planning is for the infrastructure. The ta"le "elow is an 4LA&%L4 -'LM. N*T$. All involved parties must "e reflected. 11
1.1,
P"'%%i%)
,, %lanning tasks at a minimum!. Tasks per %hase Level!B Delations and dependencies with other activities inside or outside the Test %rocess and "etween the different Test Types!B Time LineB De0uired5 versus availa"le 5 resources organiAation and infrastructure!B De0uired5 versus availa"le 5 Time frame. 11
Phases & Activities Development Tests Planning Control Test Plan Infrastructure Preperation Specification !ecution Completion Week 10 11 12 12 12
1.0 11
,, The current ta"le entries are 4LA&%L4S -'LM and are provided for a "etter understanding. 11 The activities that will "e e7ecuted are listed in the overview "elow.
Activity $/ecuted by tart Date $nd Date Run Time Re!ations
1.0 1*
APPENDI; 1 < PRODUCT RIS= ANALYSIS

,, )n this appendi7 the results will "e documented from the e7ecuted product risk analysis. The results should "e copied from the &T%. 11 Test 2oa! Tab!e Test 2oa! $/amp!es Re!evant Characteristics
Risk Tab!e 'eeds to "e changed to an attachment! Characteristics 3Partia!4 56 / +unctiona!ity *bjects Chance of 8/%/1 +ai!ure Test 2oa!s Damage 8/%/1 8/%/1 8/%/1 ,, Deference. T&ap< 'e7t 5 Chapter R 11
57 8/%/1
5n 8/%/1
1.0 1>

Template Test Plan Development Tests v1 0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Template Test Plan Development Tests v1 0

Uploaded by

Copyright:

Available Formats

TEMPLATE TEST PLAN DEVELOPMENT TESTS

Author Version Location Characteristics

Template test plan development tests Version information

Sogeti 'ederland (.V. August$ *1$ *00+

Template test plan development tests Version information