16 minutes to read
What is a Test Plan? A Detailed Guide to Writing a Software Test Plan From Scratch
Ievgen Ievdokymov
Senior QA Engineer
To gain success in any project, it is indeed important first of all to design a well-thought-out plan. Still, taking into account the hectic pace of modern life and commitment to Agile methodologies, some teams tend to ignore test plan design due to lack of time, work overload, and frequent project changes. Nevertheless, this approach is not effective. As Benjamin Franklin said, "By failing to prepare, you are preparing to fail." A proper test plan can help you prevent poor performance and avoid numerous risks and challenges. So, let's consider the subject in detail.
What is a Test Plan?
A test plan is a test artifact defining test objectives, test strategy, intended testing activities, deliverables, needed human and technical resources, schedule, estimations, possible risks, and ways to mitigate them. In other words, a test plan serves as a guideline or roadmap helping turn all testing activities into a single defined and smooth QA process.
Test Strategy vs Test Plan - What is difference
Both test artifacts serve to guide a QA team through the whole QA process. A test plan and a test strategy are interrelated and, therefore, are often mixed up. If you have a vague idea about the difference between them, you are not alone here. So, the issue is worth to be considered in greater detail. As we have already defined what a test plan is, let's also give a definition of a test strategy. So, a test strategy can be defined as a high-level document that outlines the core principles of software testing. So while a test plan can be considered as a detailed location map, a test strategy can be compared to a compass giving the right direction.
| Test strategy | Test plan |
|---|---|
| Provides a general outline of software testing | Gives a minute description of software testing |
| Prepared by a product manager | Prepared by a QA lead |
| As a rule, a test strategy is a constituent component of a test plan | A test plan is independent |
| Very rarely undergo changes | Can undergo numerous changes |
| Concentrates on the general principles and approaches | Concentrates on the project specifications and peculiarities |
| A test strategy involves information on activities related to each test level. | A test plan contains detailed information about the work scope, possible risks, peculiarities of the test environment, required equipment, resources, time frames, etc. |
Why is Test Plan Important?
There are plenty of reasons to pay heed to test plan design. It provides the whole team with numerous benefits, some of which are mentioned below:
Test Plan Components
In essence, there are no strict requirements for the content of a test plan. It can significantly vary from team to team and from project to project. The IEEE 829 standard can come in handy and serve as a good template if you are just a newbie. So, let's have a look at the most common test plan components.
1. Test plan identifier
It is essential to generate a unique identifier to be able to find your test plan easily and quickly.
2. References
It is highly recommended to prepare a list of all documents with their links that refer to a test plan. You can mention the following documents:
3. Introduction
Here you can provide a brief test plan overview, as well as key test objectives and restraints.
4. Test items
List here all software modules or parts that should undergo testing.
5. Test tasks
This plan item contains information on all testing activities that should be performed.
6. Features to be tested
Specify product features that should undergo testing with references to project specifications that describe them.
7. Features not to be tested
List product features that should NOT undergo testing and provide the reasons (e.g.not included in the next release, considered to be stable enough, etc.).
8. Approach
It is reasonable to add here your test strategy. As we have already mentioned this document is often included in a test plan as it highlights the core principles of software testing.
9. Test pass and fail criteria
Provide criteria to clearly understand whether a test can be considered passed or failed.
10. Suspension Criteria and Resumption Requirements
In this plan item, you can present criteria for test process suspension as well as requirements for its resume. For instance, further test activity can be considered useless and, therefore, can be suspended if more than forty percent of defects have an open status or several blockers are not fixed.
11. Environmental needs
Provide detailed information on the requirements for the test environment. List required equipment, software, and tools. Besides, it is essential to point out which systems and tools are available and which must be procured.
12. Test deliverables
Make up a list of test artifacts that should be created during the course of software testing. Make it clear which information they should contain, as well as a schedule for their generation and conveyance. In this context, it makes sense to mention test cases, bug reports, scripts, test data, and test reports.
13. Responsibilities
Enlist all members of your team and specify their duties in order everyone can understand who is in charge of particular tasks.
14. Staff training needs
This plan item is relevant if a particular staff training is required to succeed in the testing activities.
15. Risks and contingencies
Provide a list of risks, as well as their likelihood and possible consequences. Moreover, it is advised to offer also a risk mitigation plan.
16. Schedule
A test plan is not complete without a work schedule and core test milestones. All your time frames should be based on realistic estimations and get updated if required.
17. Estimate
Provide information about testing costs and efforts or add at least a link to a corresponding document.
18. Approvals
Make up a list of all employees who must review and approve a test plan, certifying it by a signature.
How To Write a Test Plan - Guideline on Test Plan Design
A consistent, realistic, and accurate plan can significantly simplify a test procedure and provide QA team members with valuable information. To help you write a really helpful test plan that will not collect dust but serve as a go-to document for any incomprehensible situation, consider the following tips:
Study a product thoroughly
It may sound corny, but it is indeed impossible to proceed to test planning without knowledge of the main peculiarities of the project. Thus, it is crucial to thoroughly study all available project documentation to understand clearly the way the app should work, when and how it should be used, who should use it, what software or/and hardware it requires, etc.
Start off with your test strategy
We strongly advise you to leverage a test strategy as a jumping-off point for a test plan creation as it helps understand a broad picture of testing. Only after that, you can segue into working on the rest of your test plan.
Keep your test plan succinct
On the one hand, a test plan should be consistent and contain all the required information. On the other hand, it should not be overelaborate. A succinct plan is considered to be more effective and easier to read while a too long test plan is more than likely to be neglected. Still, there is no particular advisable length for a test plan as it mostly depends on the nature of a project. Generally, test plans for sophisticated and large-scale projects are pretty long. The main thing is to strike a happy medium and include only indeed important information.
Keep your test plan structured and well organized
To make your test plan easy readable, it is important to structure provided information, avoid too long paragraphs, and use instead lists, bullet points, tables, and charts whenever possible.
Be accurate and specific
Team members should feel the reliance on the information provided by the test plan. Therefore, it must be utterly accurate. In case any mistakes are found, they should be eliminated at once. Besides, important information should be complete, i.e. it is not enough to specify only the OS name required for your test environment, you should also mention its version.
Your plan can contain gaps to be filled later
It is a usual practice to have some gaps in the drafts of your test plan. The important information very often may be discovered over time. In essence, certain aspects of testing can even get clear just before the test execution.
Involve your colleagues in a test plan design
To fill in the gaps in your test plan, you will have to conduct an investigation to hunt up the required information or just to ensure the accuracy of available information. Consequently, it is a good practice to entrust particular sections of the test plan to your colleagues who have in-depth subject-related knowledge. Later you can combine and edit delivered information.
Keep your test plan updated
Project requirements can undergo frequent changes, and new requirements and considerations can be revealed as well. All these should be reflected in a test plan. As a consequence, It is important to keep your test plan up-to-date, otherwise, it will be just useless.
Review your test plan carefully
First of all, you should review a test plan with the whole QA team. Later, after corresponding amendments and corrections, the test plan can be reviewed by competent stakeholders like PMs, team leaders, BAs, subject matter experts, and other specialists who can provide actionable advice.
Make up a test plan with a target audience in mind
Actually, it is a rule of a thumb. Any plan should be written with a purpose not to prepare one more document, but to help people who will use it. In this context, your test plan should not only contain useful information but should convey it properly. For example, your test plan obviously will be read by business-oriented team members and tech-savvy specialists. Therefore, your main task is to present technical information in a way that can be clear for the business. Whenever possible, avoid heavy use of technical jargon to make the test plan easily understood by all stakeholders, irrespective of their role.
Of course, one should put a great deal of effort to write an effective test plan, still, it is worth it. At the end of the day, all team members will highly appreciate this document as it simplifies their work and helps avoid numerous difficulties.