What does your Quality Strategy contain?

I’ve been asked as part of an interview process to put a presentaiton together, and one of the topics is what I think a quality strategy needs. In my mind a robust strategy contains a vision or direction of travel, and a bunch of tools, tips, on how to get there.

The vision should be compelling, easy to digest, and contain what this means in general terms for how we work together. It also could contain a narrative on quality: ownserhip, value, etc.

Each team will be at different points on the journey so it doesn’t make sense to me to have a set way to do things, but I’d love to hear what other people think, or have done, etc


Hi @gemma.hill1987 ,

I like your idea of what goes into a strategy.

I’ve had good success using the following section titles for various quality and testing-related strategies:

  • Why
  • What
  • How
  • Where
  • When
  • Who

For some audiences, one section might not land so the format provides an opportunity for another section to join it up with the others. The section titles also help with getting to the point so it doesn’t overwhelm the audience. The section titles tend to also be completely agnostic – as in, they are just useful prompts.

Good luck with the interview. :crossed_fingers:t2:

1 Like

Yeah so from experience, what I’ve done is lay out the quality narrative as it currently is - I leaned into Leading Quality with this one.

This gives you a good indication of what to focus on specifically in the org. Do this by running a survey and speaking to the employees directly.

There are a few streams you can take and I like the format proposed by @simon_tomes about incorporating the various questions.

Another angle could be from Process, People, Technology. What process(es) to follow and why, who needs to be involved (drivers and stakeholders), what technology is required to get there.

I’m going to take the risk of being too basic about this, but I still believe there are way too many organizations out there that think “testing=quality”. Every chance I get in my (rather large) company, I do my best to convey a broader vision for how each person has the opportunity to influence quality (positively or negatively) many times during a workweek or even a single workday. I hope this helps, and of course if your impressions so far in the interview process are “they understand testing is not just quality” then I hope this works out for you and your career goals.


I don’t think my thinking is far from yours. I’d say a strategy is your testing needs and how to use what you have to best fulfil them. So it’s the ideas that guide the project + how to apply your resources.

That means a good strategy needs a good understanding of the available resources and limitations - people, technology, tools, schedules, deliverables, scope, documentation, testability, hardware - our mission and everything that supports it, ideally.

It should be properly scoped to the product, focused on risk, pragmatic, practical and cover a diverse set of techniques, product aspects and quality criteria.

There’s also a notable difference between a good test strategy and a document. Most strategy and strategic decisions take place in the mind, and anything that gets written down can become outdated by new information and a shifting project environment. If a document is for the tester then that matters less, but if it’s a public record it may need to remain up to date and if it’s a communication tool to another person it will need to be more vague and probably contain less detail. It may be a subset of a bigger strategy that’s more tuned to what a tester or test team needs from someone else - access to production machines, logins, customer data for testing, etc.

The first place I’d look for ideas around strategy is the HTSM, in full. But that’s 5 pages long so I’ll just link it: Heuristic Test Strategy Model - Satisfice, Inc.


I think I couldn’t have said it any better.

Understanding the resources and limitations of those is key. If there is a lack of one of the resources mentioned by Chris it would good to highlight that and possibly change the situation by e.g. training, hiring more people (with other skillsets) etc.

I find these kind of exercises very complicated as you will be lacking a lot of information that is required for you to create that very test strategy, it is not something generic that you can create for any product out there but the HTSM by James is a great start.

If this is a company worth working for, they will understand that you can’t just work with the limited information that you have got now, but you can try and ask the right questions to get there. Good testers ask a million questions and never stop asking :stuck_out_tongue_winking_eye: .

Good luck with the job hunt!

1 Like

Hi Gem!

Have you considered Wardley Mapping for visualizing your strategy? Some years ago I realized that we can visualize test strategies as well in that format. … and I ended up writing a book about it and a new test plan format looking into the “maturity” of the elements.

For the last two test strategy documents I’ve written, I’ve been using the 4 quadrants as a way to anchor the document. I use that to describe who owns what quadrant, as well as what all we will be doing/are doing in that quadrant (as well as sometimes what we’re weak on or will focus on in the future).

Edit: The 4 Quadrants in question:


I wrote about the process we followed and the sections we created when writing our quality strategy How to Create a Quality Strategy and Testing Model


this is incredibly true for so many organisations - so many times I’ve asked a question about quality and I’ve got a response about testing. I tend to point that out and have a conversation about a) what I actually want to know about and b) what quality can mean/cover.


Oh yeah, they wanted me to answer with what things should be in a quality strategy, so I answered with some stuff around what I said, plus other bits from the thread - the point about the document needing to be useful, and easy to understand, and that it should talk to the narrative and culture we want to build


Similar to others a quality strategy is a very different thing from a Test strategy and it often greys into a quality action plan.

Strategy, get stake holders together and discuss quality, their goals and missions around quality and put in place an plan to manage quality throughout a project.

Picking up on another comment, our strategy could be to get stakeholders involved and gain to a good understanding of the available resources and limitations - people, technology, tools, schedules, deliverables, scope, documentation, testability, hardware - our mission and everything that supports it, ideally and create an action plan around those and then execute the plan.

Quality management plans or often simply quality plans may be what they are looking for. Usually not the testers responsibility but I dual hat and do these occasionally.

I had the following in a recent plan.
Quality goals and mission statement: Where are we now, short term and medium term business goals, any KPI’s or OKR’s to track quality against, primary stake holder needs, key quality milestones.

A set of principles that guide the plan.

Roles and responsibilities.

QA process activities, reviews, development model, retros, feedback loops, learning actions.

Change management process actions.

Environments, dev, CI process.

Development quality practices, reviews, unit tests, regression coverage, wc3 guidelines.

Acceptance criteria process.

Release management.

Product quality risk register. Primary input into Test planning.

Lessons learned and improvement activities.

Documents and deliverables of quality information.

QA review log.

So basically it was a list of quality related activities and how we will leverage from them.

Now if it was a Test strategy then I’d also go for a variation of HTSM but that is a very different thing than a quality strategy or plan.

I edited the above, but in case others don’t notice, these are the 4 quadrants I’m referring to:

1 Like

As far as Quality Strategy is concerned, mine would closely be aligned to what end-users want. I would keep my eyes and ears open on listening to the end-users needs. Quality is about providing what they need.


I appreciate that this is too late for your interview but I would answer that you shouldn’t write one.

Rather than writing documents with lots of words that no one will ever read, consider mapping it out in a ways of working diagram. I recently put one together for my work and it went down an absolute treat!

(I appreciate that this response is maybe not what they would want to hear in an interview)