Test Plan

Before getting started with the Test Plan, first look at some of the important terms.

Test Policy – A high level document describing the principles, approach and major objectives of the organization regarding testing.

Test Strategy – A high level description of the Test Levels to be performed and testing within those Levels for an organization or program.

Test Approach – The implementation of the Test Strategy for a specific project. It includes the decisions made based on the project’s goal and the risk assessment carried out, starting points regarding the process, the test design techniques to be applied, exit criteria and test types to be performed.

Test Plan – A document describing a scope, approach, resources and schedule of intended test activities. It identifies, amongst others, test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.

Master Test Plan – Master Test Plan describes the “how” of testing for a single Project, spanning multiple levels of testing. It describes the relationship between Test Levels (e.g. Unit, Integration, & System) and the division of work across the Levels. Master Test Plan should be aligned to Test Policy and Test Strategy.

Level Test Plan/Detail Test Plan –The detail Test Plan describes the “how” of testing for a single Test Level on a single Project. It provides level-specific schedule, tasks, and milestone details.

Below is the Master Test Plan template that can be used in Waterfall/Traditional Method. Remember; Test Planning should be a planning exercise not a documentation exercise. So based on your requirements, you can modify the below template.

Item	Description
Test Plan Identifier	·         ID of the Test Plan
Introduction	·         High level Description of the Project ·         References, Acronyms & Definitions
Test Items	·         Those things that will be delivered for Testing
Features to be Tested	·         Features those will to be Tested during Test Execution
Features not to be Tested	·         Features those are out of scope for Testing
Test Approach	·         Implementation of the Test Strategy (description of the Test Levels to be performed and Testing within those Test Levels) ·         Test Types (Functional, Non–Functional, Structural, Regression) to be performed ·         Test Design Techniques (Specification–based/Black-box, Structure–based/White–box, Experience–based) to be applied ·         Risk assessment ·         Tools used
Entry Criteria	It is a set of generic and specific conditions agreed upon with the stakeholders for permitting a Testing Process to go forward with a defined task. It can include below conditions – ·         All developed code must be unit tested, and signed off by the Development Team ·         All human resources must be assigned and in place ·         Test Environment (Hardware/Software/Environmental Configurations) must be in place
Exit Criteria	It is a set of generic and specific conditions agreed upon with the stakeholders for permitting a Testing Process to be officially completed. It can include below conditions – ·         All Test Cases must be executed ·         All Critical and High priority defects must be fixed and tested ·         Product Manager must sign off the Business Acceptance Test / User Acceptance Test ·         Any Medium/Low priority defects must be accepted as implementation Risk by Product Manager
Suspension and Resumption Criteria	Suspension criteria – It's a criteria used to stop all or a portion of the testing activities on the test items. Criteria can include items as below – ·         Testing can't proceed because of the Critical bug found ·         Unavailability of the dependent External or Third Party system during Test Execution Resumption criteria – It's a criteria used to decide when testing can resume after it has been suspended. Criteria can include items as below – ·         Critical bug is successfully rectified and Testers can resume Testing without any hurdle ·         Dependent External or Third Party system becomes available again
Test deliverables	Testware that will be delivered for Maintenance Testing at the end of the Test Execution. Testware – Artifacts produced during the test process which is required to plan, design, and execute tests. It includes documentation, scripts, inputs, expected results, set–up and clear–up procedures, files, databases, environment, and any additional software or utilities used in testing.
Environmental Needs	·         Hardware/Software/Environmental Configurations ·         People
Roles & Responsibilities	Defining Test Team Members and their Roles. ·         QA Manager – Activities performed by a QA Manager ·         QA Lead – Activities performed by a QA Lead ·         QA Analyst – Activities performed by a QA Analyst
Training needs	·         Domain/Product/Project specific Trainings ·         Training on Testing Tools used ·         Training on Third Party system used
Schedule	·         Test Schedule (Smoke, Cycle 1, Cycle 2, Cycle 3, Regression)
Dependencies	·         Dependency on External/Third Party system ·         Dependency on Change Control Team/Infrastructure Team ·         Dependency on other Products/Projects
Assumptions	Process specific assumptions – ·         Involvement of QA at all stages ·         Test Environment & required Interfaces availability & stability ·         Compliance with Change Control Processes Project specific assumptions – ·         Co-ordination with Partner/Team member ·         Consideration of impact of New Requirements
Risks and Contingencies	Risks Identification and its impact – ·         Project Risks – Factors relating to the way the work is carried out, i.e. the Test Project, e.g. Time & Budget risks ·         Product Risks – Factors relating to what is produced by the work, i.e. the thing we are testing, e.g. Technical & Business risks, Quality risks Risk Mitigation – List of the Risk Mitigation plans/solutions to handle the risks.
Approvals	Sign-off needed on the document

As noted earlier, in Waterfall environment/methodology Detail Test Plan can be created for a specific Test Level (e.g. System Testing) and a Master Test plan can be created for all the Test Levels (e.g. Unit, Integration, & System).

If you are working in Agile environment/methodology (e.g. Scrum), Test Plan can be created for the entire Release as well as for individuals Sprints. The above Test Plan Template (with some changes) can be used for the same. In my future post I will address the Test Planning in Agile methodology.