I use the [[Heuristic Test Strategy Model]] (HTSM) to create test strategies. It's not unusual for me to be working on multiple test strategies if the context demands it. When I am working on one app, and projects within that app, I will create an overall strategy to test the app, and specific strategies for the projects. ## Where to start My advice is to start with a Product Coverage Outline (PCO), using the SFDIPOT heuristic from the HTSM PDF; it's on page 4. A mindmap can be a good choice to think about the Product Factors, to get your thoughts on (virtual) paper. I like to use Quality Criteria to think about the relevant risks, usually this is done with other people present. Schedule about 30-60 minutes if you want to do this with your team. When I have those two things roughly thought through (PCO + Risks), I'll use the Project Environment to write down a summary of the System under Test. Finally, I pick the Test Techniques that are going to be most relevant. This results in a pretty lean Test Strategy. ## Where do I write the test strategy? A public place, usually Confluence. I want other people to critique my work, and I want them to be able to edit. This is a living document, and it will be amended based on what we learn during development. I want the document to stay relatively short because people don't have time and don't want to read long documents about testing. I don't blame them. # My Minimum Viable Test Strategy What is the bare minimum that should be done in order to create a test strategy? In my opinion and experience - a basic description of the main testing mission in the given context - a risk assessment and analysis - figuring out what and where your test oracles are The purpose of a test strategy for me is that I want to grow my own understanding of the product, show others what I'm going to be focusing my efforts on, and give accountability for the testing process. When the test strategy is out of sync with reality, it should be updated. A possible problem with a test strategy is that, when it's a long document, people won't read it. That might be a reason to experiment with a more barebones test strategy and see if you actually use it more. Since all testing should be risk-based, this isn't something we can skip in the test strategy. I use the SFDIPOT heuristic to make a visual map of the application to spot risks. I also do a risk analysis session with other people involved in the development of the product. The result of this is a list of risks + mitigation options that drive the testing of the system(s) under test. Another thing that shouldn't be overlooked is that you should figure out where and what your test oracles are. How do you know if there are problems? If you can't answer this question, it's going to be hard to test. The answer to this question can never be a single thing, that's a red flag. It's usually a mix of requirements, example mock data, documents, people's expertise and unwritten expectations. I'd also never skip writing down a basic description of the product under test. Not so much for others, but to prove to yourself that you've understood the problem(s) the software is trying to solve. The list of risks and test oracles isn't going to be complete, and might change based on new insights gained during the development and testing of the product. Amend the test strategy if this occurs. I'm sad I have to add this, but since we live in this ridiculous LLM-age: do NOT use LLM's to write the test strategy for you. Just, don't. The point of all testing is learning, and you won't learn much if you ask the LLM to spit out grammatically correct sentences to give the impression of a coherent looking test strategy. If writing is a weak spot for you, have you considered doing it more often so you get better at it? Crazy idea, I know. Anyway, this is what I consider the bare minimum viable test strategy. Your mileage and opinions may vary!