Hopefully, there are some useful suggestions that you can consider and even add your own thoughts!
Here are some great suggestions:
If it’s an existing project: What have the biggest pain points been in the past? Does it effect our productivity? (e.g. flaky tests in a pipeline). What are our biggest risks? What do we definitely not want to go wrong in prod?
Appetite for risk.
What does this system/component do, and who cares about it. Who expects to benefit and who could be hurt by it, and how. How can we best use the resources available to get information that will enable them to decide whether/when it’s good enough.
Since I mostly deal with automation, my answer is specific to that, but most of it translates to general testing as well, I think…
- Why? (what are the larger goals we want to achieve by implementing automation)
- Who? (who are responsible for creating the automation, and how are they organized)
- What? (what test-related activities do we want to automate, and at what level of scope)
- When? (how is automation made part of our day-to-day work and our development cycle)
- How? (what tools and languages best fit the answers given to the previous questions)
The resulting strategy doesn’t need to be a lengthy document at all.
I would say simply what problem are we trying to solve?
I use the Heuristic Test Strategy Model and try to think through each area. I document only those things that are relevant to the project.
What is in-scope
What is out-of-scope
What level of test is required (E2E, component, UA)
What are the dependencies
What is the risk factor
What is the timeline for test completion