How to create a useful test strategy document: the definitive guide
First of all, let us define that the software test plan is not the same as the test strategy plan. It is if there is a plan that contains information you should eat, drink, and sleep, but no one tells you how to do it and what you should do first. In such a case, you can die without water and food because you have decided to sleep for the whole year.
So what is the test strategy, why is it so important, and how to do it?
The test strategy document is not just a document, and the idea behind it is mandatory for every QA member. It doesn't need to be a document at all. It is a way of thinking. Every company has its own experience. Every company has already done and will make mistakes. So test strategy is like codex in the army where every record covers some fail. Each time you fail and record it, you prevent other similar failures. It would help if you understood that there are many different types of mistakes that you did or are doing right now. Each mistake has its hidden goal - to reduce your account balance.
You have bought a new car, and you know about a pit near your home. You have no idea how to avoid it, and each time you hit your car. It will happen with the next car and then with the next one. You do not have a strategy on how to avoid it. The same things are going on in testing. If you want to avoid "pits," you should have a good strategy plan.
Now we came to the most important part of this article - to the question "how." As we have already said, the main goal of any testing is finding bugs, and the primary resource is time. Since you will never have enough time to test everything, you should know your strengths and weaknesses. So let us highlight several mandatory tips.
First of all, the test strategy plan should be related to dev and product teams. You should know their requirements, estimates, capacity, etc. Example:
Product want to release this version in 10 weeks;
Devs can write code for it in 5 weeks;
It so seems like the QA team will have five weeks to test, but it is an illusion due to blocker and critical issues that will occur, and they will be resolved on week number 9. This is just an example to illustrate how it is important to cooperate with dev and product teams. So your plan is nothing without this cooperation.
When you choose whatever format, discuss it with all teams (QA, Product, Devs). Each member must understand what is written there.
Know your role and roles of each member of the team. You should know that this dev is doing the server part, and this one is doing the client part, etc. This product is the owner of this PRD, and this one is the owner of these documents. It is vital to minimize time lost in redirecting issues from one member to another.
It depends on the BUG tracking system that will create a general format for bugs, features, and stories.
It is mandatory to define testing objectives and testing flow. Sometimes it is enough to do checklists on new features without doing any regression. Sometimes it is not enough to perform manual testing with heavy test cases and automated regression testing. It's all depends on the project that you have. Try to use something in the middle (it also depends on team members that the QA team has) e.g., manual checklists with automated regression. Then move to the side, which you think your project is required.
It is a bad idea to perform tests on one test environment or even at production. A good solution is to have two test environments. One will have a current version of production (to verify bugs that were spotted there), and another one will have a future version that you are going to release. So it should be defined which of environments should keep each version.
Priorities are an essential part of any activity. You should know what the most crucial story to test is and what is the most important part of the project is. For example, a company which makes a lot of money, transfers should not have bugs at least in a part which is related to calculations. Another example is that if the company is doing an interactive book, then the most important part of testing will be the client interface.
Another important part of any testing activity is documentation. Every requirement should be documented. It is not relevant where but should be a safe and accessible place. Any documents like PRD (Product requirements document), STP (Software Test Plan), or even comment for some story should not be lost.
Depending on how you work (outsource or not), decide when and how you will do meetings and calls.
Well, after all, there is a lot of things to think about. When you get some experience making a strategy plan becomes easier, of course, so it's just a question of time. The tips given above are for people who begin their way in QA. But even if you are not a newbie, don't forget that there's always room for perfection. Plan your work and analyze yourself!