How to create good test strategy document: definitive guide
First of all let us define that software test plan is not the same thing as 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 case you can just die without water and food because you have decided to sleep for the whole year.
So what is the test strategy, why it is so important and how to do it.
Test strategy document is not just document and the idea behind it is mandatory for every QA member. It is not mandatory that it will be a document at all. It is way of thinking. Every company has its own experience. Every company have already done and will do mistakes. So test strategy is like codex in army where every record covers some fail. Each time you fail and recorde it you prevent other similar fails. You should understand that there are lots of 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 a it and each time you hit your car. It will happen with next car and then with next one. You do not have strategy how to avoid it. Same things are going on in testing. If you want to avoid “pits” you should have 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 main 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 test strategy plan should be related to dev and product teams. You should know their requirements, estimates, capacity etc.
Product want to release this version in 10 weeks
Devs are able to write code for it in 5 weeks
So seems like QA team will have 5 weeks to test but it is illusion due to blocker and critical issues which will occur and they will be resolved on week number 9. This is just example to illustrate how it is important to cooperate with dev and product teams. So your plan is nothing without this cooperation.
When you will choose whatever format discus it with all teams (QA, Product, Devs). It is very important that each member will understand what is written there.
Know your role and roles of each member of the team. You should know that this dev is doing server part and this one is doing client part etc. This product is owner of this PRD and this one is owner of these documents. It is very important to minimise time lost in redirecting issues from one member to another.
Depends of BUG tracking system that will be used create general format for bugs, features, 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 project that you have. Try to use something in the middle (it is also depending of team members that 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. Good solution is to have two test environments. One will have current version of production (in order to verify bugs that was spotted there) and another one will have future version that you are going to release. So it should be defined which of environments should keep each version.
Priorities is the very important part of any activity. You should know what is the most important story to test and what is the most important part of project is. For example company which does a lot of money transfers should not have bugs at least in part which is related to calculations. Another example if company is doing interactive book then the most important part to test will be client interface.
Another important part of any testing activity is documentation. Every requirement should be documented. It is not relevant where but should be safe and accessible place. So any documents like PRD (Product requirements document), STP (Software Test Plan) or even comment for some story should not be lost.
Depending of 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 over. When you get some experience making 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!