10 tips to write a good Test Strategy

If you are here is probably because you were asked as a QA Analyst to write a Test Strategy or Test Plan for a new project or to document an existing one.

I have written and corrected several over the years and here are some tips you can follow:

1. Start with an overview of the project title, goal and description. This is general information, what is the purpose of the functionality, application or flow to be implemented.
2. Have a section dedicated to the “In scope” items (Can be tasks, user stories, flows you know you’ll need to test). Here you’ll include everything that is pertinent to the testing tasks. Where you will be testing, which applications, flows, in what browsers and devices, are you using mock data or not, are you hitting an external service, is it frontend testing only or are you also testing APIs?.
3. In the same way, have a section to state what is “Out of scope” for testing. This can be anything from a flow that is not integrated, to browsers that won’t need testing, to mobile devices.
4. Make a list for the e2e flows that would need regression testing (Manual or Automated) and what will be cover it that. Will it be executed after each Sprint? before the deploy to another environment?
5. Environments for testing. All Stories have to be in a QA environment? Can you test in Dev? Make sure you have this points in order in case things start to tangle once the project starts.
6. Types of tests that will be executed. Are you doing only functional testing? Maybe some performance testing? Automation is included? If that so, for which flows? Accessibility testing? Check the tool I advice to use here.
7. Data section. Here we clarify where we need our data from. Is this coming from several databases? from another tool? Does another team have to prep it for us? Ensure to include the team you’ll need the data from, and the different tools you will need working and integrated in order to be able to get that input you need for the testing.
8. Include graphics, charts and mappings if they are available. Flow diagrams and charts can come handy when trying to present and understand the big picture of the project. Some junctions are easy to miss when focusing in the separate tasks only.
9. Include the URLs for the sources you’ve gotten the information from. If you are using Jira or Confluence, Azure or even an email, be sure to include this on the document in case you need to confirm your sources.
10. Always ask for the sign off. Once you are finish with the document, ask your team members to give you feedback on it, corrections, and then, the sign off. Especially from the Product Owners, Functional Analysts, Project Managers and UAT Managers. That way you’ll be covered for the future if there is any misunderstanding or last minute things are added.