15 things to include in a Test Plan

Most IT project teams are aware that their software should only go live following thorough (and successful) testing by Software Testing professionals.

 

These days this testing is usually done as part of the sprint in an Agile delivery process, but sometimes projects can require the testing to take a more formal, documented approach.

 

This may be to satisfy regulatory or auditory requirements, or where external vendors are delivering certain aspects of the solution. In any case, sometimes it becomes important to know HOW it will be tested,  WHAT will be checked, WHEN, and by WHO.

 

This is where a Test Plan comes in, usually prepared by a Test Lead or Test Manager with the intention of addressing all of the software testing questions which may arise on the project.

 

Useful for capturing everyone’s agreement about what exactly will be happening from a testing standpoint, a Test Plan is a detailed document that outlines all of the testing phases in the Software Development Life Cycle (SDLC). You may prepare a Test Plan for each phase/level (Level Test Plan) or one that covers all levels (Master Test Plan). The requirement for detail for each can depend on who is performing the testing and what level of planning or sign-off is required.

So, why invest your time and effort in writing a Test Plan? Well, if you want to minimise the bugs in your software, leverage the project team’s knowledge up front, and do this within some specified time constraints, then a Test Plan is essential.

 

15 things to include in a Test Plan

 

If you wish to go down the formal and professional route, it is best to follow an internationally recognised Test Plan outline. IEEE, the world’s largest technical professional organisation has defined the 829 Standard for Software and System Test Documentation (IEEE-829).

 

According to IEEE-829, your Test Plan should include the following:

 

1. Test Plan identifier – As the name suggests, this aims to uniquely identify the project. This naming convention must include version information and the Test Plan type (Detailed or High-Level, Test Phase, etc).

 

2. Introduction – Now that you have labeled your Test Plan, it’s time to add the project brief. The introduction section is a summary of your project and test goals. It should include objectives, goals, budget restraints, and resources.

 

3. Test focus items – Which systems need to be tested?  This segment must answer this question by providing a list of systems (standalone and/or integrated) to be tested. It may also include different system modules.

 

4. Features to be tested – (in scope). All the functionalities to be tested are recorded in this section at a high level. You must also include references to the detailed descriptions of the listed features.  

 

5. Features not to be tested – (out of scope). If your software testing plan excludes some features or systems, they must be mentioned along with the appropriate reasons for not including them and a link to any risk that this may present.

 

6. Approach – This is the most crucial portion of the Test Plan as it includes a detailed methodology of how to test the software. The software testing approach must include test data sources, inputs, outputs, testing protocols, and priorities. It must outline clearly to the reader what will happen during testing.

 

7. Item pass/fail criteria – In this segment, you should describe the success parameters for each feature to be tested. The completion criteria may include maximum number of defects (of a particular severity) allowed, minimum number of tests (of a particular priority) that must pass, etc. This can be done as an overarching statement.

 

8. Suspension criteria and resumption requirements – In this section, you list the criteria that would lead to test suspension. For example, if a particular number of critical or blocking defects are reported, the testing may be unable to continue and would be suspended. You must also list the requirements that must be satisfied in order to resume the testing efforts.

 

9. Test deliverables – This outlines the items that will be produced as part of the testing process. It may include test cases, data outputs, test execution reports, defects reported, test summary reports, etc.

 

10. Testing tasks – This includes any outstanding tasks that need to occur prior, during, or post-execution and dependencies between any of these tasks.

 

11. Environmental needs – Test environment needs such as hardware, connectivity, system and version requirements, devices, etc. are logged in this section.

 

12. Roles and responsibilities – The testing team members and any other key project personnel are listed here.

 

13. Test schedule – The schedule includes a specific timeline for executing various tasks of the testing process. This ensures the testing cycle is completed within the specified time.

 

14. Risks and contingencies – Any testing risks such as delayed software delivery and other variables are noted in this section, along with their suggested treatment.

 

15. Approvals – List the authorised persons (key stakeholders) required to sign off on the test plan and accept the approach.

 

In Summary

 

Software testing is a very important phase of the software development cycle. It thoroughly examines the software product with a view to exposing and facilitating the removal of any impacting defects, before they are released to production.

 

A well-written, communicated and accepted Test Plan is an essential part of establishing a quality software testing process on your project.

 

If you need help with creating a Test Plan, reach out to us at [email protected], we can provide templates, guidance, or a ‘done-for-you’ service.