How to Write a Software Test Plan
It is not uncommon to see that some software defects are encountered when it is time for the system to be delivered. This is often caused due to an ineffective test plan. One may have sufficient knowledge about software testing but when it comes to writing a good test plan, people often make blunders. It is a skill which can be achieved with detailed analysis of the system along with some experience in the field of software testing. Now this brings us to the matter of why a test plan have such an important place in the field of software testing. Well, it is the test plan which is a reflection of the testing schedule and approach. This brings us to the concern of writing a test plan which is effective and also takes all the aspects of the software into consideration.
How to Write an Effective Software Test Plan?
A test plan contains a detailed and systematic approach to test a software system. For a test plan to be effective, it should consist of the following:-
This section of the document briefly enumerates what the document is all about, its intended purpose and how the document should be used. In the introduction of the document, there are three aspects included, namely:
- Description of the document: The description section of the document has details like name of the project and the name of the team producing the said document. It also includes a brief account of the strategies to be implemented during the testing process, release date, etc.
- Related documents: The functional specifications, design specifications, etc., are also part of this document.
- Schedule and milestones: The schedule in detail along with the different testing estimates in brief are included in this section.
Location of the Document
It is important that the document is accessible to all members of the testing team and also to some key members of the development team, not to forget the higher management. Therefore, it is important that the location of the document be known to everyone along with the owner of the document. The location on the network where the document is stored is mentioned in this section.
Sometimes, testing starts towards the end of the software development process or the software testing process is outsourced to a third party. In such a case, the testing team needs to be given a brief account of the project background. The project background section consists of a list of documents such as business requirements, recommended test strategies, etc. It also contains a detailed description of the development process, use cases, data flow diagrams, flow charts, etc., which often prove to be useful while making the master test plan.
When a test plan is being made, this is an important aspect which needs close attention. The resources required in terms of hardware, software, testing tools, etc., are planned for. In the software resource requirements, different operating systems to be used often have prime importance. Depending on the kind of application being developed, the testing tools will be decided upon. At this point, I deem it fit to mention that the testing tools will be kept apart from the manual tests that will be carried out on the system. In the resource requirements, the team members required are also decided upon along with the responsibilities to be assigned to each one of them. There is a possibility that some of them may require some sort of training. Measures to be taken to train the staff are considered as well.
Kind of Testing to be Undertaken
The document may contain an introduction where details about the features of the software that have to be tested are included. There are chances of third party software being integrated into the software that is developed. At such times, the details of the integrated software have to be mentioned so that the testing team is aware about the depth of testing to be carried out. In case of media processes used, the same will have to be installed at the tester’s end and sanity testing needs to be carried out. It also mentions the features that are not to be tested. These features may be add-ons or third party features.
Along with the features to be tested and not to be tested, different types of tests to be undertaken on the system is also planned for. The testing strategy may consist of system testing, integration testing, performance, stress testing, security testing, regression testing, beta testing and other types of testing important to validate the system.
An important part of the test plan outline is the test schedule. The different tests to be performed, along with the timeline for the same, is what makes up this section of the test plan. The schedule for each testing task, along with its milestones, needs to be specified. Additional milestones, if any, should also be mentioned in this section.
Test Items and Test Deliverables
The functionalities to be tested, along with the priorities, make up the test items. Often, they are only listed and the entire description may not be included. If you take a look at any test plan template, you will see that test deliverables are a must. The important part of the deliverables are the different test cases. Matrices used for the testing process also find a mention there. The test cases may be divided into two parts, namely, automated test cases and manual test cases.
Problem reporting is the first part of control procedures. Often, a fixed problem reporting format is decided upon for problem reporting. However, there is a possibility that the format may not be decided upon either. The other part of the control procedures are the change requests. The process of modification is what is written in the change request. Modules that can be affected by the change find a mention here.
Risks and Assumptions
All of us are well aware that not every part of the software can be tested thoroughly. Also, when the software is tested, certain assumptions are made. The high risk assumptions are identified and contingency plan for the same is decided upon. The dependencies within the system also have to be mentioned here.
A test plan also includes the names of people who must approve it. It includes their titles or designations as well. Often, there is a column included for the date on which the said person has approved the test plan.
This was a brief overview on how to write a software test plan. A test plan can be made by the project manager or the test manager, depending upon the policies of the organization. Often, the members of different teams working on the software have to be consulted before the document is actually prepared.