Test Strategy vs Test Plan
Test strategy and test plan are not the same. Let us repeat — they are not the same!
Test strategy and test plan are two important things you need to create when starting a software testing project. They both have different roles, but they can be used together to achieve a common goal.
The difference between them is that a test strategy is more of an overall outline of the entire testing process — from beginning to end — including deadlines, resources, and other details. It also includes information about what types of tests will be performed and who will perform them. The test strategy is created before any actual testing begins.
On the other hand, test plans are documents that include all of this information and specifics about individual tests, like what kind of data is required for each one or what specific steps need to be followed for them to work correctly (or not).
A test plan is more specific than a test strategy because it contains detailed instructions for carrying out tests on an application or website — tools like scripts or checklists that allow testers to record their findings during each round of testing. So they can compare them later on against previous versions of the same app or site.
Additionally, a test plan tells you exactly how much time each task will take and which tasks need to be done first. For example, if we wanted to create a test plan for software testing, you might write down what you need to do:
- Plan out tests based on what needs to be tested and how many times each feature should be tested before moving on;
- Write up a schedule for when each test should occur, when it should be completed by, where we’ll do it (in-house or at a third-party location), and who’s responsible for completing each task;
- Create documentation explaining how all of these things are going to happen.
So if you’re just trying to figure out what kinds of tests should be performed or how they should be conducted, consider using a test strategy; if you’re planning on creating an actual document with all this information, use a software test plan instead.
But remember, test plans are created after the test strategy has been finalised so that testers know exactly what needs to happen next!
Hierarchy of test documentation
As quality assurance makes or breaks business endeavours, it is no wonder that there are different layers to test documentation. QA testing strategy is not at the top of the pyramid, and it’s not something that testers directly interface with either.
The test documentation hierarchy is the following:
- Test policy is the high-level overview that covers the company’s primary goals and principles of testing. It focuses on the business value of QA without diving into any details. Test policy doesn’t undergo changes often, but that is not a problem as it is other levels of test documentation that deal with practical matters
- Test strategy by definition covers at least several projects. It covers enough ground to be a practical guide, e.g. scope of testing, test levels and test types, addressed risks and even methodology for actual tests. Preparing a test strategy is also a great insurance for your new projects, as your staff will have something to work off before going low-level. Test strategy may also have some distilled testing objectives, even more so if there is no test policy in place
- Test plan describes how you as a company can achieve the goals outlined in your test policy and test strategy. This is a per project or even per sprint low-level overview that includes test schedule, the tech stack used for QA (including an on-premise or web-based test case management tool), and project/sprint-specific risks. You can learn more about the overlap between test plan and test strategies in our earlier article.
Get a testing strategy template that enables us to release 2 times faster
How to write test strategy document
When you create strategies for testing, it is important to remember about the business side of things. This is why the QA lead is usually the right person for the job. Here is how it would go:
- Consult test policy to see company-wide QA and business principles
- Meet project stakeholders to discuss project’s workflows, potential risks, and developer expertise in early testing
- Create a test strategy draft (more on that in a test strategy sample below)
- Invite stakeholders for a review and amendments
- Share the strategy with the QA team to discuss concerns and potential changes
- Adopt the strategy
Types of testing strategy
There is a variety of testing strategies, and the choice is not as binary as picking a manual vs automation testing strategy. Here are some examples:
- Methodical strategy deals with pre-requisites like ISO standards
- Consultative strategy involves key stakeholders to help you identify potential risks
- Analytical strategy implies creating tests based on requirements before features were implemented
- Reactive strategy concerns testing after the product was already launched in production
- Regression-averse strategy covers regression risks for updates to both newly developed and in-production software
- Model-based strategy uses a model that simplifies real-life performance of entire software or a system to speed up test execution
Example of a good test strategy
As the company providing testing tool for agile software development since 2013, here is what a good test strategy would include:
- Test scope
- Test levels
- Testing tools
- Entry and exit criteria
- Change management
- Environment (e.g. dev, test, prod)
- Compatibility requirements
- Risks
This list is not exhaustive: we’ve listed the main components that a testing strategy should have. Adding anything extra (such as specifying deliverables) depends on the state of your test documentation and QA maturity. We will be following up on this article with a full-fledged sample test strategy.
Tips to develop successful QA test strategy
- Have a look at test strategy templates available on the internet. They may give you some inspiration even if the described project comes from a completely different industry
- Consult other stakeholders to make sure that the test strategy aligns with the business goals
- Ensure that your test strategy slots well into the test hierarchy. Don’t go too high-level if you have a test policy to lean on. Don’t go too low-level if you know there is a test plan coming as well.
- Find the right QA tools. This is a key part of implementing a test strategy: you need a reliable test management solution with integrations to handle all other QA tools
Your test strategy will benefit greatly from using an innovative test management solution. We suggest aqua, a proven tool that we further enhance with an AI Copilot. You can auto-generate tests, prioritise them, and remove duplicates while using your test suite for context. Automating routine to free time for tasks that need more creativity is an essential piece of any test strategy.
AI testing to give your test strategy wings
5 decisions to make before you create a testing strategy
Why do you even need to make decisions before creating a test strategy? This is a reasonable question.
First of all, sometimes you don’t need to create test strategy. It might be too overwhelming to create a strategy when a product that you are going to verify is too simple for extra documentation.
Secondly, if you decide to go without a test strategy, it is good to have at least some prototype of a test plan. You still need to figure out what kind of test plan is best for your team and whether or not there are any limitations on your budget or time frame.
It’s important that everyone on your team is clear about the project goals and business objectives. This will help ensure that everyone is moving in the same direction and that no one gets left behind.
Once all those pieces are in place, and everyone knows what they’re doing (and why), it’s time to create an actual plan! This plan should include things like deadlines and milestones so that everyone involved knows what’s expected from them at all times during the project lifecycle (i.e., from concept through implementation).
Only when all criteria mentioned above are taken into consideration, you can finally go to these five decisions you should make towards preparing for a test strategy:
- Decide what you’re testing;
- Decide who’s going to test it;
- Decide when the testing will begin and end;
- Decide how you’ll report the results of your tests;
- Decide what is the criteria when your software is ready for release!
Once those are taken care of, it’s time to create your software test strategy!
Conclusion
Testing strategy is arguably the most crucial piece of the test documentation hierarchy. It connects business objectives with the practicalities of quality assurance to drive company-based and project-based testing efforts. A good testing strategy requires an experienced QA lead and good communication with other stakeholders to tailor the best practices to your project.
Flexible solution for any testing strategy
