What should a test plan test?

It is common tendency of us to chalk out a plan before we start doing any task! Why do we make plans? Simply because we don’t want our process or task to go astray. We want to keep a track of the processes and make sure that they are being guided in to the right direction and also most of the errors and faults are avoided.

Same philosophy holds hundred percent true for the software testing life cycle also. It also requires a test plan to prevent itself from going astray and slip out of track! To say it scientifically, we mean that a test plan is required for determining whether the software system or application meets the specifications and requirements listed for it or not?

WHAT SHOULD A TEST PLAN DO?

- A test plan is prepared by the test engineers after struggling with all the requirements of the testing phase and the software and after assessing all the risks associated with the project.

- As a normal plan would do i.e., test plan details out a systematic approach to the accomplishment of a certain task, so does a test plan with the only difference being the task.

- For the test plan the task is the successful completion of a particular software testing.

- A test plan gives a detailed approach of all the processes or activities to be undertaken during the testing.

- A test plan marks the work flow of the software testing mechanism.

- A test plan states the strategy to be followed to make the software testing successful or in other words we can say that it provides a means to check whether or not the software system or application meets all the requirements and specifications as mentioned by the client or the customer in the documentation.

ITEMS OF A TEST PLAN

A typical test plan has to have one or more of the below mentioned items according to the norms and responsibilities levied on the organization:

(a) Compliance test or design verification
- This is the first step in the testing process and involves the development of the smaller units or modules of the software system or application after they have been approved by the senior developers or testers.
- In this the objectives of the software system are established and defined. But, it is not defined how that system will be designed or achieved.
- It also involves the generation of user requirements documentation.

(b)Production test or manufacturing
This step is executed when the software product is being assembled and for the purposes of controlling the quality.

(c) Commissioning test or acceptance
This step is carried out before the final product is released to the client or the users.

(d) Repair test
It can be performed any time during the service life of the software.

(e) Regression test

WHAT ITEMS ARE COVERED IN A TEST PLAN VIA IEEE 829 STANDARD?

IEEE has laid down what all the items are to be covered by a test plan via the 829 standard for software test documentation:
1. Test plan identifier
2. Background
3. Introduction
4. Assumptions
5. Test items
6. Features to be tested: Functionalities and requirements that have to be tested.
7. Features not to be tested: Functionalities and requirements that don’t have to be tested with reasons.
8. Approach: description of the data flow, live execution, simulation and philosophy behind it.
9. Item pass/fail criteria: expected outcomes and tolerances.
10.Suspension criteria and resumption criteria: description of the check points.
11.Test deliverables
12.Testing tasks
13.Environmental needs
14.Responsibilities
15.Staffing and training needs
16.Schedule
17.Risks and contingencies
18.Approvals

One cannot expect the two cycles namely the STLC or software testing life cycle and the SDLC or software development life cycle to succeed without a test plan.