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.

Explain the concepts of (Institute of Electrical and Electronics Engineers) IEEE 829 standard?

The contributions in the field of electrical and electronics engineering by the IEEE or the institute of electrical and electronics engineers are not hidden from the world. The institute has its official head quarters situated in the city of New York.

It emerged as a non profit organization and since then is comprised of professionals from the fields of electrical and electronics engineering. The main aim of the association has always been to continually make excellent technological advancements in the field of electrical and electronics engineering.

ABOUT IEEE & IEEE 829

- IEEE currently has been reported to have around 40,00,00 members world wide and across 160 plus countries.

- Around 45 percent of the member population is from other countries besides United States.

- The history of the IEEE dates back to the 19s. IEEE was started as a non profit association in the New York City in the year of 1963.

- It was formed as a resultant the merging of 2 great individual non- profit institutes of that time namely the American Institute of electrical engineers (AIEE) and the institute of radio engineers (IRE).

- AIEE and IRE were formed in 1884 and 1912 respectively and in 1963 they merged together to give rise a new association i.e., institute of electrical and electronics engineers.

- Since then, IEEE has given so many standards for many fields like electrical, electronics and software testing etc.

- One such standard given in the field of software testing is “IEEE 829 – 1998” often called as “829 standard for software test documentation”.

- This standard has been designed especially for the documentation of the whole software testing process.

- It specifies what all documents are to be included in the currently defined 8 stages of the software testing cycle.

- Each stage has been stated with its individual document specifications.

- The IEEE 829 – 1998 standard just not specifies the documents to be produced but also lays down their formats.

But, it does not give any clear answer for whether or not all of the specified documents should be produced? Not only this, it also does not states what all content is to be included in these documents.

WHAT DOCUMENTS ARE PRODUCED?

As per the standard, the below mentioned documents are to be produced:

1. Test plan
The document that gives the management features of the testing cycle and includes:
(a) How the testing will be carried out?
(b) System under test or SUT configurations
(c) Who will carry out the testing?
(d) Estimated time
(e) Test coverage and quality level of the testing

2. Test design specification
The document listing all the detailed conditions as well as results and passing criteria.

3. Test case specification
The document specifying the input data for test cases.

4. Test procedure specification
The document having detailed description on how to run each and every specified test case and also describes the set up conditions and the steps to follow.

5. Test item transmittal report
The document giving the reports of one stage of the testing cycle after its completion.

6. Test log
The document maintaining the records of the test cases i.e., their title, executor, and final status i.e., pass or fail.

7. Test incident report
The document detailing the observations of the test cases that didn’t pass. It gives the causes of the failures of the test case and the expectations. The failure of a test case is often treated as an incident rather than a fault.

8. Test summary
The document providing a brief report of the whole testing cycle and also covers up the aspects that were not covered up in any of the above listed documents like software quality, quality of the testing efforts etc.