What is a software test plan?
A test plan describes how your QA team will tackle testing a particular piece of the software product. A test plan includes objectives, schedule, deliverables, and resources required to achieve them. A quality test plan is well worth the time investment, as a careful approach yields good bug detection and mitigates QA-related time & financial risks.
The beauty of test plans lies in their practically company-wide reach. Few test plan components are particularly technical. The document is mostly accessible to all the stakeholders, painting a picture of quality assurance that resonates with everyone on the project. Testers generally tend to spend less time around their non-tech colleagues than developers, so providing a glimpse into QA work is on the list of benefits as well.
Test plan and test strategy: are they the same?
While some use the terms interchangeably, this actually screams conscious or unintended disregard for nuance. Test plans cover a rather narrow scope — they help to ensure that certain parts of the software are up to the standards. The test planning process is, just like the name suggests, much more so about the deliverables and getting there. It’s the test strategy that provides the big picture of why your QA specialists are doing all of this.
To better illustrate the difference from test plans, here is what a test strategy could include:
- Technology stack used in the project and how it affects QA
- Project-wide technical risks
- Levels of testing (unless you go full Agile, of course)
- Types of testing
- General schedule aligning with product development timeline
Get a testing strategy template that enables us to release 2 times faster
What are the test plan requirements?
Like I mentioned, both the necessity for test plans and the plans themselves can be pretty fluid. Still, there are a few criteria that are wise to apply if you do create a test plan document.
- Conciseness. Avoid long sentences if possible. Introductory phrases should be omitted when possible. A test plan (unlike this article) is not a piece of prose: it’s a daily manual where fluff gets old pretty fast
- Structure. When you prepare test plan, take the time to organise the content in a neat manner. A good table of contents goes a long way, especially for frequent users that are not always in the context (e.g. programming staff)
- Readability. As mentioned earlier, your test plan should bring value to all stakeholders. Avoid the QA-specific jargon if you can. When you are the one to write test plan, get some feedback from non-tech colleagues to see if they stumble where they shouldn’t
- Adaptability. Things can go wrong, and not necessarily on the QA side of things. A setback on the product, design, or development teams will mean a setback for you. Account for such risks to keep the plan relevant
- Accuracy. Not everyone will be consulting the plan on a daily basis, especially if their job doesn’t require that. An incorrect statement may give some team members wrong ideas that stick with them for months
Steps of developing test plan
Step 0: Analyse the product
This step may not be as relevant if you have been working on the project for a while. On the other hand, test plan development for a new project always means doing the homework. This is even more relevant if the team uses an automated software testing tool. The more you understand what makes the software tick, the more options for automation you will see.
It’s not just fellow QA specialists that should help you understand the product. Ask the product owner about the launch and high priority features, since quality may have been sacrificed in favour of speed. Talk to the project manager to see if they have been facing recurring issues. Ask developers where technical debt risks turning into a point of failure.
Step 1: Define the scope
Test plans are indeed not meant to cover everything about your product. You usually focus on the level of testing (e.g. unit or system testing) and may additionally limit yourself by the types of testing. Functional vs non-functional testing is often quite a distinction in itself.
Let’s look at banking software testing as an example. Your bank may have introduced a lifestyle section where clients can buy a concert ticket or reserve a table at a restaurant. Your bank also grants loyalty points for all transactions, including lifestyle purchases. If the task is to make sure that loyalty points are correctly granted for these new lifestyle purchases, your test plan concerns integration testing.
Step 2: List test criteria
Once you know what to look for, it’s only logical to define what constitutes QA success and failure. Feel free to introduce benchmarks that are relevant to the scope. Some examples include defect rate percentage, test case pass rate, and threshold of severe open defects.
Find more test criteria in our article on when to stop testing.
Step 3: Map the environment
Now that we know both the scope and the criteria, it’s time to decide how you go about them. Write down all the tools that your team uses for software testing. Evaluate whether this suite is enough for the scope. Research and add new solutions if necessary.
Especially on a new project, extra care is needed when preparing QA team for test automation. Run the QA specialists by automation ideas that you gathered during the analysis stage. Make sure they are proficient enough with the necessary automation tools to carry out this vision. Resource planning can very well be part of this step even without automation.
Step 4: Create a schedule
The next step is to create a schedule of activities to fulfil the scope. Knowing the schedule of product and developer teams is 90% of creating your own schedule. Make sure to account for potential missed deadlines on both your and their ends.
Test automation can really help the planning effort. If individual modules are checked as development happens, your QA specialists spend less time sitting and waiting for the devs to send them the upcoming build. This time can be better spent on exploratory testing and, if necessary, making up for otherwise missed deadlines.
Step 5: Write down deliverables
All that’s left now is to formalise the expected output. The test plan that you may be writing right now is a deliverable as well. So are the new test cases that your team will make as well as any fruits of the automation labour.
Test results are arguably the ultimate deliverables, as they shape future QA and potentially bug resolving efforts. You may also come up with a way to present your work to non-QA colleagues at a certain milestone or the end of the sprint.
Conclusion
Test plan is a useful tool with advantages that go beyond QA effort. It formalises software testing, opens it up to other stakeholders, and helps navigate potential challenges within and outside the QA team. Great preparation does yield great results, and software quality assurance is no exception.
