Test Plan – An Authenticated QA Document For Building Client’s Trust

As said by John Lasseter, “QUALITY IS THE BEST BUSINESS PLAN”. Quality matters in all fields either in entertainment or IT industry.

Trust is another factor that forms the basis of this quality delivery. Isn’t it obvious? Yes! A quality work is appreciated in all spheres of work fields and this appreciation helps in the further building of a good and may be a long-term relationship between a Client and the Service Provider.

For achieving the best quality, you must have a proper planning and planning needs required preparation.  In software testing, the planning phase is one of the most important phases. Taking the first and foremost step towards this approach, let’s get started with the introduction of a “Test Plan”…

Test Plan: A Brief

A test plan document refers to a descriptive form of a systematic approach to testing a system or software. It typically contains the thorough understanding of eventual workflow of all testing activities in a project lifecycle. This document is the most common document prepared by testing team to share with clients and all stakeholders of a project.  It provides a glimpse of the whole testing process, its standard and strategy to be followed for the project.


A well-written test plan document helps to gain client trust on QA of the application and also maintain stake holder’s confidence for a successful launch of that project. It helps all stakeholders to get an overview of all testing related information  and some other aspects:

  • Effort estimation: Preparing a test plan document enables us to estimate required efforts for validating the acceptance criteria of a software product.
  • Provide testing overview to stakeholders: A test plan document helps all stakeholders to understand the why and how of product validation will be done.
  • Standardize the testing phase: Having a test plan document in regulated environments maintained standard of the testing phase of all software and organization of course.
  • Important aspects of the software testing effort: A test plan includes the all important aspects of the software testing effort for example objectives, scope, approach, team and duration.
  • Repeatable document: A test plan document can be used repeatedly for a number of projects of the same type.

Usage And Importance Of A Test Plan

To understand usage and importance of a test plan, we must have knowledge of software testing and its different phases.  In very simple words, software testing is a process to detect differences between existing software and required software. These differences are generally referred as defects or bug, which are fixed by techies in order to develop the required application.

There are following phases in Software Testing Life Cycle as given in below image:

In the second phase of STLC, we prepare the test plan document. If there is no test plan document, then there can be multiple problems faced by team members such as lack of knowledge of software problems, breaching financial and scheduling limits and Contrasts in expected quality and end quality.

Test planning is essential to bring software to an acceptable level of quality and to identifies as many bugs as possible. There are following other activities involved in this phase:

  • Scheduling and estimating the system testing process.
  • Establishing process standard.
  • Describing the tests that should be carried out.

All the above activities help to collect information for preparing test plan document.

Prerequisites To Prepare A Test Plan

To Prepare a test plan, you must have project reference document and a predefined template.

Reference document:

Apart from test planning activities, there are few documents also referred for writing a test plan document. These documents are :

  • Business Rule Specification (BRS)
  • Software Requirement Specification (SRS)
  • Functional Requirement Specification (FRS)
  • Project Plan Document
  • High-Level Design document (HLD)
  • Low-Level Design document (LLD)

Test plan format:

Whatever format is decided for a test plan, it must include all upcoming testing effort in terms of:

  • Testing Scope
  • QA cycles and Schedule
  • Test Deliverables
  • Release Criteria of each cycle
  • Risks and Contingencies

Test Plan: IEEE 829 Standard

Each organization has its standards and format for test plan document on the based on standard provided by IEEE. IEEE is an institution at the international level that defines globally recognized standards and template for documents. This institute introduces IEEE 829 standard for system and software documentation. According to IEEE 829 test plan standard, a test plan should consist of all sections given in below image.

1. Test plan identifier

A test plan document commences with a  test plan identifier, which is a unique company generated number. It helps identifies the test plan, it’s testing level and the level of software it is related to. It also assists in coordinating software and test ware versions.  is an example of test plan identifier.

Example Test Plan Identifier: ‘Unit Test plan for LW-RDCFP 1.2

2. Introduction

Introduction of test plan provides an overview of test process and project. It also summaries all constraints, limitations and risk involved in the testing process.

3. Test items

Test Items is a segment that essentially indicates the things should be tested inside the extent of the particular test design. This section generally includes list of all functions and modules of the software. These items are identified from the FRS and SRS document provided to the team.
Correct name and version of these functions and modules should be provided in test plan document. For example, Registration module version 2.2 (includes all new enhancements)

4. Features to be tested

This section contains a list of features that are planned for testing. It should include low-level non-technical descriptions of each feature and level of risks identified. The planner should set the level of risk for each feature. Use a simple rating scale such as (H, M, L): High, Medium and Low. These types of levels are understandable to a User.

Redesigned Online screens (Risk level: High)

5. Features not to be tested

This section lists the features not to be included in the testing process after identifying the reason behind its exclusion. This section of a test plan directly affects the levels of acceptable risk within the project. In other words, If a feature does not get tested, how it affects the level of risk of the project.

6. Approach

This area distinguishes the technique for this test plan, contrasting relying on the level of the test design (Unit, Integration, Acceptance).The approach expressed ought to be proper and in concurrence with all higher and lower levels of test plans.

The level of detail of this section differs depending on the level of the test plan. For instance, a Unit test plan will really expound on singular unit tests and test data. The greater part of data on testing procedures and techniques will be incorporated into this area.

It contains information related to sources of test data such as test inputs and outputs, techniques used for testing and their priorities. The approach section should also define the guidelines for other testing activities such as requirements analysis, scenarios development, acceptance criteria etc..

This section also defines the entry and exit criteria followed for testing.

Entry Criteria

Entry Criteria refers to a checklist or criteria, which should be completely fulfilled before start testing. Few examples of Entry criteria points are:

  • Test plan is created.
  • All test cases cover all requirements.
  • Testing assets such as test cases and test data are approved and reviewed.
  • RTM is created for all requirement.

Exit Criteria

Exit Criteria refers to criteria followed for completion of Testing. Few examples of Exit criteria points are:

  • All discovered defects have been tracked.
  • Priorities bugs have been verified and fixed/not fixed (with reason) and closed.
  • All known issues should be conveyed to all stakeholders
  • Release completion report should be handed over to all stakeholders

7. Item pass/fail criteria

This section provides success criteria to evaluate the test results for each feature. Success criteria must be provided in a detailed way in this section of the test plan. Item pass/fail criteria is directly based on pass/fail status of test cases. The normal criteria for assessing pass/fail are: if the actual result is same as the expected result then test case should be pass and if the actual result is not equal to expected result then it should fail.

8. Suspension criteria and resumption requirements

This section describes the criteria when to pause the testing activities. A test planner specifies what constitutes stoppage for a test and what is an acceptable number of defects to allow testing to continue. In case number of defects reaches a point, where the follow-on testing has no value, it makes no sense to continue the test and waste the resources.

This decision directly implies on number of bugs and their severity

9. Test deliverables

This section specifies a list of all documents that need to deliver as resultant of different testing activities. Following are few examples of Test Deliverables:

  • Incident reports
  • Corrective actions taken
  • Test plan document
  • Tools and their outputs
  • Test cases
  • Problem reports and corrective actions.
  • Test design specifications
  • Test logs ,i.e., Error logs and execution logs

10. Testing tasks

In this section, all testing tasks such as test case writing techniques,  testing techniques are defined. All dependencies of tasks, estimation and resources are also provided in this section.

11. Environmental needs

This section specifies any special requirements including necessary hardware and software required for testing to proceed. Documenting the physical components required for test execution recognizes potential gaps in what is required and what actually exists. For example, Access to a nightly backup/recovery system.

12. Responsibilities

This section contains information related to roles and responsibilities of all the Testing Team right from QA manager to Tester. Few example points of this section are:

  • Understanding Requirements
  • Writing test cases
  • Reviewing test case
  • Executing test cases
  • Preparing test log
  • Defect reporting

13. Staffing and training needs

This section specifies the names of the testing team members, who will involve in this project. It also contains information related to required training of the application or tool. In case any training is required then its schedule also provided in this section of the test plan.

14. Schedule

This section depicts testing schedule followed the testing. Scheduling should be based on sensible and approved evaluations for software testing. Contingent upon the level of test, the measure of this segment will contrast, e.g. Master test plan will involve all the test plan schedules below it making it fairly large. It lists all needy and relative dates which should play out the testing activities.

15. Risks and Contingencies

Software Risk is the risk which QA thinks could go wrong or could hamper testing. to add content in this section, a test planner should aware of all unclear, confusing and un-testable requirements.
All software risks related to the product and its testing should be distinguished in this segment. It should also contain further plans for risks and contingency and their solutions.  There are few examples of some risk possibilities:

  • Lack of personnel resources when testing to be begin
  • Lack of availability of required hardware, Software, data and tools
  • Late delivery of the software/ hardware and tools
  • Delays in training on the application and/or tools
  • Changes to the original requirement or design

16. Approvals

All test plan should be approved by all stakeholders. This section includes signatures of all stakeholders, who approved the document for further processing.

To Conclude

A Test Plan is a managerial document that has many levels differing in content and depth. We have Test Plans to ensure testing stages are performed to the best quality. Successful test planning enables the mapping of tests to the software requirements, i.e., Traceability matrix. IEEE 829-1998 Standard provides us with a Test Plan Structure to successfully plan for testing stages.

Without a detailed Test Plan, problems will arise definitely. Hence, choose Test Plan over Issues!

Follow me!

Leave a Comment