Template Master test plan [TMap Next] v1 0.doc

< Template mastertestplan >

Template Mastertestplan

Sogeti Nederland B.V.1.01

28 augustus 2007

Master test plan

< Template master test plan >

Templatemastertestplan

< Authors: Gerrit de Vries en Ewald Roodenrijs, Sogeti Nederland B.V. - translation Folkwin Kloezen, Sogeti USA LLC

This document containsatemplatefor the drawing up of themastertestplan (MTP).

Thepartsnamed in thetable of contentsshouldbe presentin each mastertestplan and are thereforestandard;howeverthecontentof thoseparts is different depending on the situation and thereforecustom-made. Thiswill therefore beleft tothe author ofthe mastertestplan. >

< In thistemplatethere is text between twodouble hooks (< Blue text >). This text contains comment or explanation and has toberemoved orreplacedby the definitive text. There is also text betweensingle hooks (<Text>). This text containsexample elaborationand also needs to beremoved orreplacedby the definitive text. Allother standard text may be adjusted as need fits

Version information

Version / Date / Remarks / Author

Copyright Sogeti Nederland B.V. ©, based in Vianen, the Netherlands.

This work (or any part thereof) may not be reproduced and/or published (for whatever purpose) in print,

photocopy, microfilm, audio tape, electronically or in any other way whatsoever without prior written

permission from Sogeti Nederland B.V. (Sogeti).

TMap is a registered trademark of Sogeti Nederland B.V.

Sogeti Nederland B.V.2.01

Master test plan

< Template master test plan >

Distribution list

Name / Company/Function

Sogeti Nederland B.V.2.01

Master test plan

Table of Contents

ApprovalClient

< Optional: the approvalof the clientcan be represented here. In that casethesigned hardcopy needs to be archived. >

Client: / Signature
Name / <Nameclient
Division / Division
Department / Department
Function / <Function
Location / <Location
Telephone / Telephonenr.>
E-Mailaddress / emailaddress / Date: <date

Management summary

Project objective
<…>
Test objectiveand assignment
<…>
Shortdescription of the testapproach
<…>
Results to be realized
Result
  • example:wellexecutedandfinished systemtest>
  • example:well executed and finished user acceptance test>
  • example:well executed and finished total test project
/ Document
  • ST Testreport
  • UAT Test report
  • End report Testing
/ Delivery date mm-dd-yyyy
<mm-dd-yyyy
<mm-dd-yyyy
Qualitative objectives
example: Each test levelneeds to becompletedon time and it needs to be clear for each system objectif it meets the acceptance criteria>
Estimate
<…>
Testprocess risks and measures
Test process risks
•<…> / Measures to be taken
•<…>
Go/no-go decisions
Example:After each test levelthe testmanager makes sure thata test report is drawn up. This report will, afterreviewwith the projectmanager, be presentedtothekey stakeholders, whothendecideif it is possible to go to the next test level.
Atthe end ofthe test projecta test endreport will be drawn up, containing a risk based assessment of the test object. Based on this endreport the key stakeholdersmake the final decisionto go to production or not.

Table of Contents

1Introduction

1.1Project and project objective

1.2Objective of the master test plan

1.3Involved in creating the master test plan

2Assignment formulation

2.1Client

2.2Supplier

2.3Assignment

2.4Scope

2.4.1Within scope

2.4.2Out of scope

2.5Preconditions and assumptions

2.6Acceptants and acceptance criteria

2.6.1Acceptants

2.6.2Acceptation criteria

3DocumentatiON

3.1Basis for the master test plan

3.2Standards

3.3Test basis

4Test strategy

4.1Product risk analyses

4.2Test strategy

5Approach

5.1Test levels

5.2Evaluation

5.3The <name test level>

5.3.1Goal

5.3.2Short description

5.3.3Responsible

5.3.4< Optional: test environment to be used >

5.4Phasing per test level

5.5Test products

5.6Review plan

5.7Entrance and exit criteria for each test level

5.7.1< Optional: Functional Acceptance Test >

5.7.2< Optional: User Acceptance Test >

5.8Go/No go

6Organization

6.1Organization structure

6.2Roles, tasks and responsibilities

6.2.1< Optional: Trainings- and coaching’s necessity >

6.3Structure of meetings

6.4Structure of reporting

6.5Completion

7Infrastructure

7.1Test environments

7.2Test tools

7.3Office setup

8Management

8.1Test process management

8.2Test infrastructure management

8.3Test product management

8.4Defects procedure

9Test process risks and countermeasures

10Global Estimation & Planning

10.1Estimation

10.9Planning

10.10Milestones

11Glossary

Sogeti Nederland B.V.2.01

Master test plan

1Introduction

1.1Project and project objective

Describeconciselythe project andthe project objectives. >

This mastertestplan fitsto the project plan <name projectplan>.

1.2Objective of the mastertestplan

Theobjective of the Master Test Plan (MTP) is to inform all who are involved in the testprocessabout the approach, the activities, includingthemutual relations anddependencies, andthe (end) products to be delivered for the test project project name>.

The mastertestplan describes this approach, the activitiesand (end) productsthatneed further elaboration in theothersystem test plans. Thesesystemtest plansneed to beabstractedfrom this mastertestplan.

1.3Involved in creatingthe mastertestplan

Name / Function / Responsibility
WriteMTP>
<Review MTP>
<Approve MTP>

2Assignment formulation

2.1Client

Theclient is> The partythatgives the assignment for thecreating of the MTP andthe executionof the tests, see TMap® Next 5.2.1 >

2.2Supplier

SupplierThesupplieris> The person responsible for creating the MTP and/or theexecution of the test assignment, see TMap® Next 5.2.1 >

2.3Assignment

< The result to be obtained (what will be delivered) andobjective (whatdoestheclient want) of the test project. This is the responsibility oftheclient. See TMap® Next 5.2.1 >

2.4Scope

2.4.1Withinscope

Describe the scope in general terms. Specify the boundariesof the scope. It concerns the testactivities that need to be executed in particular. Describe the parts in scope as concrete and exhaustive as possible. At minimumthe following needs to be covered (if applicable):

  • Projects;
  • Systems (incl. release or version);
  • Functionality;
  • Conversions;
  • Administrative Organization (AO) procedures;
  • Test levels;
  • Testactivities
  • Interfaces.

Makeseparate paragraphs for these subjects.

See TMap® Next 5.2.1.

Tip: Add, ifpossible, (a) diagram(s)that shows a visual representation of the scopeby drawing a line around the in-scope systems, interfaces, AO, etc.

2.4.2Out of scope

Describe in concrete terms what parts are out of scope for testing. In addition tothe things from the previous paragraph (§2.4.1) also think of:

  • System changes not included in the project (e.g. hardware changes to the Mainframe platform);
  • Test activities executed by others;
  • Reorganizations;
  • Possible future projects that influence the current project (particularly if there are still uncertainties about the other project).

Also include who isresponsiblefor this. Also think of system changesthat are not included in the project, test levels/-activitiesthat are executed by other parties, reorganizationsand possible future projects that can be of influence.

See TMap® Next 5.2.1 >

2.5Preconditions and assumptions

Preconditionsconcernconditionsthat third partieslike the client, the project ortheusers, impose to the testprocessand within whichthe testprocessmust operate (definition TMap® Next). The followingdemandsare enforced:

Preconditions, for example:

  • The test projecthas to be finished not later thandetermined date>;
  • Theprevailing projectplan is boundaryforthis mastertestplan and theexecutionof the test projectis based on this

Assumptionsare external circumstances oreventsthat must occur to ensure the testprocess’ success, but that cannot be controlled by the test process. In other words, these are the requirements of the test process vis-à-vis others (definition TMap® Next).

Assumptions, for example:

  • The line organizationsareresponsibleforthe execution of thefollowing activities:
  • Reviewing test specifications / testscripts, withinthe fixedperiodofxxxdays;
  • Providing resources for UAT that are dedicated and prepared
  • ….
  • Thedelivery planning of the project has to be tunedwith, and where necessary adaptedto, thesequencethat is desired from the testproject.
  • Thedocuments identified as test basisneed to be accepted by stakeholders (includingthe test team), before the test specification can be started.
  • Changeson baselineddocumentsneed to followthe formal change procedure.
  • The test environmentsare delivered on time and correctly working in conformitywith the environment planand specification.
  • Test specificationfor a test levelwill start no earlier than when theentrance criteria for it are met (See §11.7).
  • Test executionfor a test level will start no earlier than when the entrance criteria for it are met (See §11.7).

2.6Acceptantsandacceptance criteria

See TMap® Next 5.2.2 >

2.6.1Acceptants

The table belowstates the acceptants of <system>:

Name / Function / Department

2.6.2Acceptation criteria

The table below states which acceptance criteria there are for <system> and to whichstandardthey should apply:

Description / Standard

3DocumentatiON

Thischapterdescribes the documentation used in relation with the master test plan.The described documentationconcernsa first inventoryandwill be elaborated,actualizedanddetailed ata later stage, duringtheseparatetest levels.

See TMap® Next 5.2.2. >

3.1Basis for the mastertestplan

Considera Project plan ora Plan of Approach for the project, specific projector testplanning, an implementation plan orother documentsof importance. >

Thefollowing documentsareused as basis for this mastertestplan.

Document name / Version / Date / Author

3.2Standards

< With regards to testingconsider TPI or test guide books. Development standards, documentation standards orquality conventionscan also be used. >

Thefollowingconventionsand standards areapplied for this testplan.

Documentname / Version / Date / Author
TMap® Next for result driven testing / 1eedition / 2006 / T. Koomen, L. van der Aalst, B. Broekman en M. Vroon

3.3Testbasis

The testbasis contains the documentationthat serves as basis for the tests that have to be executed.The overview below describes the documentationthat is the starting pointfortesting. Consider a functional or technical design, data models, system architecture, user manuals, ‘old’ testware and AO-procedures >.

Documentname / Version / Date / Author

< If it’s already definite thatthe testbasis is (partly) missing oris of poorquality, also mentionhere the measurestaken in this area, for example nterviews toget the necessary informationon the table. It is also possible to mention the document type if the document is not yet available at the time of writing this document. >

4Teststrategy

Thetime available for testing is limited; not everythingcan be tested with equal thoroughness. This means that choices have to be made regarding the depth of testing. Alsoit is strived todivide test capacityas effective and efficient as possible over the total test project. Thisprinciple is the basis of the test strategy.

The test strategy is based on risks: a system has to function in practice to an extentthat nounacceptable risks for theorganization arise from it. If the delivery of a system brings along many risks, thorough testing needs to be put in place; theopposite of the spectrumis also true: 'no risk, no test'.

The first step in determining the test strategy is the execution of a productrisk analyses. This is elaborated in §4.1.

The teststrategy is subsequently based onthe resultsof the risk analyses. The test strategy lays downwhat,how andwhen (in which test level) is being tested and is focusedin finding the most important defectsas early as possible for the lowest costs.This can be summarized as testing with an optimal use of the available capacity and time. The test strategy is described in §4.2.

Seealso

  • Productriskanalyses: TMap® Next 5.2.3 and 9
  • Test strategy: TMap® Next 5.2.4 >

4.1Product risk analyses

The product risks are determined in cooperationwiththeclientandthe other parties involved. This product risk analyses (PRA) is comprised of two steps:

  • Make an inventory of the risks that are of interest
  • Classifythe risks.

Thecomplete product risk analysis ismentioned in appendixappendix number>.

During the risk assessment the test goalswere also formulated. These can be found together with the corresponding characteristics in table below.

Test goal / Description / Characteristic
<…> / Descriptionof thementioned test goal / <functionality, performance, user-friendliness, suitability, etc.>

Theacceptants <optional: andother parties involved with the project> havedetermined the product risks. The extent of the risk (the risk class) is dependent on the chance of failure (how big the chance is that it goes wrong?) and it depends on the damage for the organization if it actually occurs.

The risk class (RC) determinesthe thoroughnessof the test. Risk class A is the highest risk class and C is the lowest. The test strategy is subsequently focusedon covering the risks with the highest risk classas early as possible in the test project.

First the chance of failure and damage are determined for each risk. The risk class has been takendirectly from this.Note: This is the contents from the TMap® Next table (See TMap® Next 9.6). Evidently it’s possible to deviate from this in consultationwith theclient.>.

Risk table
Characteristic / Part / RC / Argumentation
Functionality / … / A/B/C / …
User-friendliness
Performance
Security
Suitability
Etc.

4.2Teststrategy

For each riskfromthe product risk analysisthe risk classis qualifying thethoroughnessofthe test. Risk class A is the highest risk classand C the lowest. The test strategy is subsequently focused on covering the risks with the highest risk class as early as possible in the test project.

<Note: the content of the table below is only an example! Risk class A has to have in at least one test levela high thoroughness of the dynamic test (), risk class B has to have in at least one test level a medium thoroughness of the dynamic test() and risk class C has to have in minimal one test level alimited thoroughness of the dynamic test ()

Attention: There are some test levels mentioned in this table, but this is only done as an example. It can be possible that in your project there are more/lessand/or other than the in this table mentioned test levels

Characteristic /object part / PRA-RK / Evaluation / Development test / ST / FAT / UAT / Impl
Functionality / A/B/C
- part 1
- part 2
- total
User-friendliness
Performance
- online
- batch
Security
Suitability

Explanation for the table above:

PRA-RC / Risk class (from product risk analysis, where A=high risk, B=average risk, C=low risk)
Evaluation / Evaluation/review of the various intermediary products (requirements, functional design, technical design)
Development test / Unittest and Unit integration test
ST / Systemtest
FAT / Functional acceptance test
UAT / User acceptance test
Impl / Implementation
 / Limited thoroughness of the dynamic test
 / Medium thoroughness of the dynamic test
 / High thoroughness of the dynamic test
S / Static testing (checking and examining the products without executing the software
I / Implicit testing (including in another test type without creating specifically designed test cases
blank / If a cell is blank, it means that the relevant test or evaluation level does not have to be concerned with the characteristic

5Approach

In thischaptereach test levelin the test strategy (thewhat) will be translatedto a concrete test approach (thehow). Make sure that thedescribed testapproach reflects the test strategy fromchapter 4! Each element from the test strategy has to return here! This paragraph can be more concise if therewill be test plans(TP) drawn up for each test level. (Refer to the TP’s that have to be written). There are twoimportant factorsthat determinewhetherTP’s are being written or not:

  • The size of the project;
  • The levelof uncertainties and ambiguitiesthat are there at the moment of writing the MTP.>

5.1Testlevels

List the several test levels (SystemTest, FunctionalAcceptance Test, ProductionAcceptance Test, etc.) and evaluationswhere appointed in the test strategy. The details will be in a separate paragraphfor each test level

For this MTP the following test levels are acknowledged:

Test level / Goal

5.2Evaluation

Describe the evaluation strategy, ifevaluationbelongs to the scope of this mastertestplan. >

5.3The <name test level

5.3.1Goal

What is thegoalofthe test level. >

5.3.2Shortdescription

Short description on the contents of the test level (whatcharacteristics, who specifies, what test goals are covered, whoexecutesand on which kind of test environment). Subsequentlydescribefor eachcharacteristic howthe risks concernedare being verified and/or tested for this test level. >

5.3.3Responsible

Theresponsible and/orpeople involved ordepartmentfortheexecution of the test level. Consider the following:

  • The testmanager is actuallyresponsibleforthese tests: in that casethere should not be anyone else mentioned as responsible. In that case it concerns the 'involved' or, even better, the 'executers' (from that external party), who are managed by the testmanager (otherwise the test manager can’t beresponsible)
  • The testmanager is notresponsible for these tests (in that case these tests ortest levelshave to be listedin §2.4.2 “Out of scope”): it is possible to make certain demands (mainlyin the form of exit criteria that have to be met) to these tests, naturally after obtaining agreementwith the external parties.
  • The test levelsconcerned are described in the test strategy of the MTP, but the test manager is not responsiblefor these tests. He is responsible for obtaining agreement regarding the tests with the external parties, as well with the realizationof the test strategy andwith the execution of it, but not for the result and quality of these tests, as he has no mandatein this. Appointthis construction explicitlywithparagraph2.4.1and 2.4.2(In that case the design of the test strategy is within scope andis includingthe 'external tests' andverification of the exitcriteria. Out of scope is the actualmanagement andexecutionof these tests).

See for more in chapter 12 of this MTP.

5.3.4< Optional: test environment to be used

The <test levelwill be executed on the <test environment>. This will be elaborated in chapter13. >

5.4Phasing per test level

In the Planning phase, the test manager formulates a coherent approach that is supported by the client to adequately execute the test assignment. This is laid down in the test plan. In the Control phase the activities in the test plan are executed, monitored, and adjusted if necessary. The Setting up and maintaining infrastructure phase aims to provide the required test infrastructure that is used in the various TMap phases and activities. The Preparation phase aims to have access to a test basis, agreed with the client of the test, of adequate quality to design the test cases. The tests are specified in the Specification phase and executed in the Execution phase. This provides insight into the quality of the test object. The test assignment is concluded in the Completion phase. This phase offers the opportunity to learn lessons from experiences gained in the project. Furthermore activities are executed to guarantee reuse of products.

5.5Testproducts

See TMap® Next 5.2.7 >

The deliverables are:

Phase / Product / Comment / Delivery Date
<Planning> / <Mastertestplan>
Testplan for each test level
Management / <Risk report>
Setting upandmaintenance infrastructure / <Detail specification test environment
Preparation / <Report detailintake for each test level
<Specification / <Testscript pretest>
<Testscript for each test level
<Test script for each test level
Execution / Defect log>
<Status report>
Completion / <End report>
Release advice(for each test level)

5.6Reviewplan