Quality is informed confidence. If my product is high quality, I should be confident it is doing the right things in the right way, and I should be able to prove this.
Identify the sources which would cause a lack of confidence - risks to the product or the product could cause to the business (eg, does it add an attack surface to security?)
Learn about the concerns the stakeholders have regarding the product and what it would take to assuage those concerns. Sometimes they stem from the stakeholder’s own experiences you might not have considered, sometimes from a lack of knowledge.
Finally in analysis, you want to identify the goals of the project and ways to measure or otherwise prove it is doing its job.
The test strategy should follow one simple goal: “Every layer has a purpose and every concern has a layer”.
For the items identified in analysis, you want to ensure everything is covered in some way.
The strategy should be put together in such a way that you can pick up any piece of work and easily identify the needed tests using it.
Reiterating what was covered in analysis - what metrics can be placed around the product to prove it is both working and doing the right things?
Example Tech metrics
Example Business metrics
- Time required to do task (ensure you collect this metric prior to solution being implemented as well if relevant)