Marcin Łojewski
Table of Contents
Recently we have created a few articles on test planning and test management. The core of this content was the test plan - a document that defines and outlines the testing effort of a web application.
You may check our articles here:
You can download and use the test plan templates we have included there.
One of the crucial points in high-level testing management is to understand the difference between test plan and test strategy. The test strategy term is often used in different contexts. This might be quite confusing for a test team that is slightly less experienced. Let’s grab a flashlight then and shed some light on the topic.
The differences between Test plan and Test strategy
If we want to understand the topic we need to create some sort of brief definitions of the test plan and test strategy.
Test strategy is an extensive and high level document that presents the overall approach to the testing process. It usually guides on all repeatable decisions that need to be made when on software testing.
Test plan is an operational document describing the testing process of a specific application. It is an instruction for the testing effort of this particular software.
On the first sight, the test strategy is a high-level document, whereas test plan is operational. The goals of each documents are different. Test plan document describes what to test in one specific app and will include the list of specific testing activities. Test strategy document shows the test manager and each test engineer how to perform testing and what is the general test approach. You will find the detailed comparison below.
For your comfort we have compared both documents in a table below.
| Test Plan | Test Strategy |
|---|---|
| A project based instruction on how to test the software in hand | A document that describes a company wide approach to test design |
| Test plan is a dynamic document in which may change in each testing cycle | An effective test strategy rarely changes |
| Will include the test environment, list of features to be tested and specific test scenarios | Will include test objectives, test conditions, decision on test automation and bug reporting pathway |
| Highly detailed information specific do the project | General information based on company situation, experience and general approach |
| Test plan document guides the testers through the bug finding process | Test strategy describes how testing is being performed not only to the manager or test lead but to non technical personnel too |
| Is fitted with test cases and test schedule relevant to the software development process | Is created once and significant for each type of testing or the subject matter |
For now let's skip to a different question. Which is...
Test strategy and Test plan - why the confusion?
One of the reasons both terms might get switched and confused is the fact that the test strategy might actually occur in two different contexts. In both of them test strategy defines how the tests will be performed.
First, we have already described above - test strategy is a set of rules relevant to all testing efforts held by the company.
Second, as you might remember from our articles, it may become a part of the test plan. Every reasonable person should now ask “why would that be?”. The answer is relatively easy and lies one level above the test planning - within the company, that wants to test a product in the first place.
Let’s compare two business entities. One - a startup that does its first software development process. Two - a well established company that develops and supports multiple applications.
Company one is doing many things for the first time and testing process is definitely one of those firsts. That means that (in 99% cases) they do not have a high-level testing strategy in place yet. Nevertheless they prepare an approach or a strategy if you will, that is relevant to their single product.
Company two on the other hand is not the new kid on the block anymore. They are well established in their market and have performed many iterations and life cycles. Creating separate strategies per each product is not feasible for them anymore, since they were basically rewriting the same stuff over and over again. They have reached a point where creating a company-wide test strategy would cost less man hours than redoing single strategies per software testing process.
The former approach to test strategy should be considered as temporary whereas the latter, as the optimal.
Test plan vs Test strategy - what should come first?
Let us give you the bad answer first - well.. it depends. In fact we are not too far away from the proper answer anyway. It really does depend if your strategy is a high level document or a part of the test plan.
Considering the natural way of business development it would be natural to create a few test plans for different products and then draw the similarities into a separate document. That way we can come into the conclusion that a test plan will come first. But that is not the case actually.
Even if you are a startup and are in the process of creating the first master test plan, you should start it by creating the strategy chapter. Try to place all information, that might be reused in future projects. Those components of test strategy chapter might be as follows:
- test deliverables
- industry standards you want to follow
- high level test objectives
- releasing process
- bug reporting
If we are talking about a more mature business the order should be the same. Strategize first, plan second. The test plan and all its individual aspects should be created with the company test strategy in mind.
If for example the strategy foresees a bug reporting track, you do not put bug reporting into the plan at all. What you do put into the plan are all project related deviations from the strategy and individual decisions such as a specific test technique. Remember to put the root cause of the change there as well.
BugBug hints on how to plan and strategize testing
We understand that we are deep into the theory of test management. But we can not stress this enough in our content. Test your software! Even without automation it will save you money. When you add test automation to the equation, it will immediately save you time, money and image.
Coming back to the topic in hand. In our opinion a good test strategy is developed by repetition of test planning. If your startup will move to later development stages, each product will require a separate test plan. This will obviously result in a company-wide experience increase but also will give you some material to compare, contrast and have some self feedback. If your products "forced" you to create different types of test plans, it's even better.
When you have the resources that you can invest into creating a separate strategy, just browse to those components of test plans, which occurred in all of them.
All of the test strategy elements, that you will find in our and different articles, are just a suggestion. Make sure it is relevant for your company and your overall business strategy.
One hint we might give you here - even though you have had the same environment set up for all previous testing efforts, try not to put it into the strategy. There are two reasons for that. First - always make sure that the test plan includes environment and data relevant to this specific project. Second - by putting specific testing software into the strategy you discourage yourself and the team from being open to new solutions.
Test strategy vs Test plan - Summary
Hopefully we were able to set test plan and test strategy apart for you. Remember test plan is a document created per project whereas a test strategy is created per company. There is an exception for startups, which can place a "microstrategy" so to speak as a chapter of the plan.
Happy (automated) testing!
