REQUIREMENT DRIVEN TESTING

Test Plan for

Project name
Requirement Driven Testing
[Pick the date]

[Type the abstract of the document here. The abstract is typically a short summary of the contents
of the document. Type the abstract of the document here. The abstract is typically a short
summary of the contents of the document.]
Approval
AUTHOR

<name> <position>

APPROVED BY

<name> <position>
ACKNOWLEDGMENT
<enter text>

Related Documents
Ref # Document Name
01 High level system architecture
02 Project brief
03 Infrastructure design.. etc

Glossary
Term Definition
Bug See Defect
Defect Software function does not work as per specification
Defect Owner The person who created the defect
Issue Software function does not work as expected or is not specified
RDT Requirement Driven Testing
SDLC Software Development Life Cycle
SME Subject Matter Expert
TDD Test Driven Environment
UAT User Acceptance Testing
Contents
Approval................................................................................................................................................2
Related Documents...............................................................................................................................2
Glossary.............................................................................................................................................2
Introduction...........................................................................................................................................5
Purpose.............................................................................................................................................5
Project Overview...............................................................................................................................5
Testing objectives..................................................................................................................................6
Features to be tested........................................................................................................................6
Features Not to be tested and constraints........................................................................................6
TESTING APPROACH..............................................................................................................................6
Static Testing.....................................................................................................................................6
Component Testing...........................................................................................................................6
Entry Criteria..................................................................................................................................6
Suspension Criteria........................................................................................................................6
Resumption Criteria.......................................................................................................................7
Exit Criteria (Test Completeness)...................................................................................................7
System Testing...................................................................................................................................7
Entry Criteria..................................................................................................................................7
Suspension Criteria........................................................................................................................7
Resumption Criteria.......................................................................................................................7
Exit Criteria (Test Completeness)...................................................................................................8
User Acceptance Testing (UAT).........................................................................................................8
Defect Management..........................................................................................................................9
Defect Status...............................................................................................................................10
Defect Severity Levels..................................................................................................................10
Test Activities and Schedules...........................................................................................................11
Week 1 (date from – date to)......................................................................................................11
Week 2 (date from – date to)......................................................................................................11
Test Deliverables.............................................................................................................................12
Test Reporting.................................................................................................................................12
Test Environment Control................................................................................................................13
Summary.....................................................................................................................................13
 Release versioning.......................................................................................................................13
Testing Resources............................................................................................................................13
<person 1> - Project Manager.....................................................................................................13
<person 2> - Business Analyst.....................................................................................................13
Testing Tool.....................................................................................................................................13
Appendix.............................................................................................................................................14
Introduction
This test plan document describes the scope, approach, resources and schedule of intended testing
activities to be undertaken for <project name>. This document should be read in conjunction with
the Test Strategy.

Purpose
This document provides the following guidance:

 Testing Scope;
 Entry and exit criteria for each test level
 A description of resources and tools to be used to conduct testing;
 An overview of test schedules per development cycle;
 An overview of the types of testing that is to be conducted;
 Defect management work flow.

Project Overview
<enter project overview, business problem(s) or benefit(s) for the implementation>
Testing objectives
<describe the objectives i.e validate and verify system functionality works to specified requirements.
Provide confidence for business owner that the solution meet business needs .. etc>

Features to be tested
<list of features to be tested for this cycle>

Features Not to be tested and constraints

<list of features not to be tested and any limitations for partial implementation>

TESTING APPROACH
The purpose of the testing is to verify the functionality of all components, ensuring they satisfy the
defined and agreed technical and business requirements. Requirement Driven Testing 1 is the
preferred approach focussing on the following:

1. Building business requirement list where test cases will be derived from;
2. Requirement is used to select which test case(s) to execute and;
3. Report on business requirements instead of test cases.

Static Testing
Static testing is testing of a component or specifications without execution of that software. This is
usually done as soon as acceptance criteria or business requirements are ready for review before
code implementation such as conflicting rules, invalid data types, redundant process just to name a
few.

Component Testing
Component level testing focuses on the functionality of each component being developed. This is
crucial where different components are being developed before they are integrated together as one
system.

Entry Criteria
Component Testing may commence when the following criteria have been satisfied:

1. All codes have been unit tested and passed.

2. Test environment including software have been setup and configured correctly.

1. Business requirements and test cases are up to date as per user story.

2. <add more>

Suspension Criteria
Component testing will be suspended under the following condition:

1
http://www.requirementdriventesting.com/what-is-rdt/
1. Critical error(s) found preventing test completion.

3. Change of business requirements.

4. Change of environment components or technology including different version.

5. <add more>

Resumption Criteria
Component testing will resume when the following criteria are met:

1. All issues in suspension criteria have been resolved or mitigated

6. New software build has been redeployed or;

7. New build with fixed Critical and Medium severity defects has been deployed into Test.

8. <add more>

Exit Criteria (Test Completeness)

Component testing can be considered complete when the following conditions have been met:

1. All High and Medium priority requirements have been tested without Critical or Medium severity
defects.

2. <add more>

System Testing
The purpose of the system testing is to validate that the complete and integrated system complies
with functional requirements and business requirements.

Entry Criteria
System testing may commence when the following criteria have been satisfied:

1. Component Testing has been completed.

9. No change to business requirements and test cases are up to date.

10. Scenario based test cases have reviewed by business owners or business users.

11. <add more>

Suspension Criteria
System Testing will be suspended under the following condition:

1. Critical error(s) found affecting functionality of the whole system.

12. Change of business requirements

13. <add more>

Resumption Criteria
System Testing will resume when the following criteria have been satisfied:
1. All issues in suspension criteria have been resolved or mitigated

14. New build with fixed Critical and Medium severity defects has been deployed into Test.

15. <add more>

Exit Criteria (Test Completeness)

System Testing will be considered complete when the following conditions have been met:

1. All High and Medium priority requirements have been tested without Critical or Medium severity
defects.

16. Business owner(s) and/or business user(s) have been notified with any remaining defects and
understand the risks or limitations of current release.

17. All defects found during testing have been recorded in defect management tool.

18. <add more>

User Acceptance Testing (UAT)

UAT is a formal testing with respect to user needs, business requirements and expectations. The
idea here is to gain confidence from business owner on the software being developed. Although it is
not mandatory business owner(s) and/or business user(s) are expected to produce his/her own test
scenarios.
Defect Management2
<add text for explanation if required>

Anyone can report defects:

tester, developer, business
owner, project manager and
business analyst
New defect
reported

Defect status = New

Defect status Reproduce in

Investigate
= Investigate TEST?
Change Request requires
additional time and resouces

YES

New/update Existing
NO Add requirement
requirement requirement?

YES

Existing test Add automation

NO Add test case
case? script (optional)
In Requirement Driven Testing each defect is
linked to requirement and test case
Refer to www.requirementdriventesting.com/
software-test-methodology-rdtrule4/ for more
details Create defect &
linked to
requirement &
test case

Defect status = active (new)

Developer
Rejected fix defect

Defect status = active (failed)

Defect status = Resolved

Fixed in
TEST?

Defect status = closed

Figure 1 - Defect workflow

2
In Requirement Driven Testing it is recommended that each defect must be linked to at least one requirement
and test case.
Defect Status
Every defect must be assigned a status to identify its place in the defect management workflow.

Description

New <enter text>

Active <enter text>

Resolved <enter text>

Investigate <enter text>

Closed <enter text>

Table 1 - Defect Status

Defect Severity Levels

Every defect must be assigned a severity level according to the following table. If the tester is unsure
what level to assign to a defect, then advice must be taken from the business owners or business
users.

Level Description

1 High <enter text>

2 Medium <enter text>

3 Low <enter text>

Table 2 - Defect Severity Levels

Test Activities and Schedules
Week 1 (date from – date to)
Activities Entry criteria Exit Criteria Priority Status
Develop Test Strategy High level architecture Document completed and High Done
documentation and project reviewed
scope.
Develop Test Plan High level architecture and scope Document completed and High Done
for user story. reviewed
Static test and test case for <enter details> Business requirements have been Develop functional and negative Medium In progess
documented. test cases for each acceptance
criteria.
<add more>
<add more>

Week 2 (date from – date to)

Activities Entry criteria Exit Criteria Priority Status
<add more>
<add more>

The following tasks are carried over from last week or added

Done – task complete

In progress – currently working on it

Pending – ready to start but waiting for requirements

Not started – planned tasks

Removed – task no longer required
Test Deliverables
Testing Team will provide specific deliverables during the project. These deliverables fall into the
following basic categories:

1. Documents,

19. Test Cases / Bug Write-ups, and

20. Reports.

21. <add more>

Test Reporting
The following test reports will be used to monitor and manage test progress:

 The number of requirements (passed and failed results);

 The number of defects (bugs) identified over the test cycle sub-categorized by severity level
as shown in the following example.

Figure 2 - Defect Report Example using Team Foundation Server (TFS)

 A Final Test Summary Report will be issued by the Test Manager. It will certify the extent to
which testing has been completed, and provide an assessment of the product readiness for
Program End-to-End Testing <add more details>
Test Environment Control

Summary
<explain who will be managing and procedures>.

Release versioning
<explain how versioning works>

Version # Description of version

0.0.1 <explain>
0.0.2 <explain>
1.0.0 <explain>
1.0.1 <explain>
Table 3 - Version numbering example

Testing Resources
<person 1> - Project Manager
Responsible to:

 <enter details>

Responsible for:

 <enter details>

<person 2> - Business Analyst

Responsible to:

Testing Tool
<describe what testing tools to be used and for what>
Appendix
<add screenshots, templates, form that relates to testing or test software will be used>