Test Plan

Test Plan

Test Plan or Software Test Plan is a document that describes Scope, approach, schedule, Resources, environments, Test Cycles and other details involved in testing activities. 

Test Plan also documents features to be tested, features that would not / cannot be tested, exit & Entry criteria, assumptions, risks identified, how the identified risks are tracked and mitigated and roles & responsibilities of the people involved. 

Test plan template, based on IEEE 829 format

1) Test Plan Identifier:- A unique identifier e.g.:-

TestPlan_project_app-Name_release-Num_version-Num.doc Naming convention depends on the Organization standards followed.

2) References: – Business Requirements, Functional Requirements, Project Plan, High Level and Detail design documents, Documents detailing organization’s process etc.,

3) Introduction: – objective or scope of the Test plan, process to used for change control, communication.

4) Test Items: – Functionality that would be tested. It contains delivery schedule of key deliverables.

5) Software Risk Issue: – Known or anticipated risks associated with project or testing activities, tools or people.

6) Features to be tested: – List of features that will be tested.

7) Features not to be tested: – List of features ‘not’ to be tested. There are several reasons why some of the features are not being tested, they are

a) Functionality already exists, found to be stable and not impacted by current implementation.

b) Functionality will not be used in this release.

 Approach:- This is the most important part of the Test Plan. Below are the details covered in Approach.

a) Types of tests carried out and details of the responsible team/individuals.

b) Pass Execution details.

c) Hardware, Software and tools used for testing.

d) Levels of regression testing that would be carried out.

e) CM (Configuration Management) setup and usage.

f) Metrics collected during different stages of the project.

9) Item Pass/Fail Criteria:- Criteria used to determine each test item has passed or failed.

10) Entry & Exit Criteria:- Explains on when to start and stop testing.

11) Suspension Criteria and Resumption Requirements:- criteria used to suspend all / portion of testing activities. Similarly resumption criteria specify when to resume testing after it was suspended.

12) Test Deliverables:- Documents, process deliverables, Metrics, Reports to be generated during different phases of testing.

13) Remaining Test Tasks: – This section details on the parts of the application that this plan does not address, because the testing may be done by external team or company.

14) Environmental Needs: – Specific details of Hardware configuration, Operating System and other software requirements.

15) Staffing and Training Needs: – Training needs of domain knowledge, Automation or any other tools required for testing etc.,

16) Responsibilities:- Details on who is responsible for what task and what is the escalation mechanism.

17) Planning Risks and Contingencies:- Details on over risk of the project but detailing more on risks associated with testing phase and also a plan on how to mitigate the risk.

18) Approvals:- Different stake holders of the project can approve certain deliverables e.g.:- Business approves UID (User Interface Design) document etc. Most of the deliverables will require approvals from multiple stakeholders.

Entry and Exit Criteria

Entry and exit criteria are the set of conditions that should be met in order to commence and close a particular project phase or stage. Each of the SDLC (Software Development Life Cycle) phase or stage will have one or more Exit/Entry Criteria conditions defined, documented and signed off.

Incase any of the conditions specified in Entry and Exit criteria cannot be met after they are documented and signed off, approval should be taken from stake holders who were involved in signing off on the Exit /Entry Criteria or the document containing Entry and Exit Criteria e.g.:- Application Test Approach document contains Entry and Exit criteria for the APT phase, so any changes done to Entry and Exit criteria conditions of the document will require taking written approval from stake holders who signed off on this document.

Every Test Stage, be it AT (Assembly Test), APT (Application Product Test) or IPT (Integration Product Test) or Performance Test or User Acceptance Test will have its own set of Entry and Exit Criteria.

Incase modification of Entry / Exit criteria involves wavier of a deliverable (e.g.:- Requirements Traceability Matrix) then a wavier request should be sent to SQA (Software Quality Assurance) team and a written approval should be obtained.

Below is a sample Entry and Exit Criteria for Application Product Test stage:

Entry Criteria

• Build notes is provided to APT team.

• All defect logged during earlier phases (Requirements, Design or Development) and planned to be fixed during APT phase are logged in Test Management software with a target resolution date.

• Business Analysts, Technical Architects, Developers, DBAs (Database Administrators), build deployment and support resources are identified and are made available as required during APT (Application Product Phase) testing.

• RTM (Requirements Traceability Matrix) is signed off by required stakeholders.

• Test Closure Report for AT (Assembly Testing) is signed off by required stake holders.

Exit Criteria
• All planned Test Scripts of Pass3 are executed and 95% of the Pass3 Test Cases have passed.

• Any Application Product Test Cases that are marked as NA (Not Applicable) should be reviewed and approved prior exiting APT (Application Product Test).

• There are no open/pending Severity 1 and Severity 2 defects, any pending Severity 3 and Severity 4 defects can be deferred only if they have been reviewed and approved by UAT users, Business users and other project stake holders.

• All the defects found pre-APT phases are closed or deferred by taking approval from all the required stake holders.

• Application Product Test resources, Business Analysts, Technical Architects, Developers, DBAs (Database Administrators), build deployment and support resources are identified and are made available for next phase of testing IPT (Integration Product Test).

• Test Closure Report for APT (Application Product Test) is signed off by required stake holders and handed off to IPT (Integration Product Test) team lead.

• Following deliverables are completed and signed off (Test approach, Test conditions and Expected results, Test scenarios, Test scripts, and common Test data sheet) before APT (Application Product Test) can start.

• APT (Application product test) environment is ready in terms of Hardware, Software and Build and is made available for APT team.

• Build deployed in Application Product Test environment has met the Exit Criteria defined for Assembly Testing.

• There are no pending Severity 1 Defects logged during Unit Testing or AT (Assembly Testing) phases.