Quality Strategies - Who, What, When, Where, Why, & How
I'm sure many people have heard the term "Quality Strategy" or "Test Strategy" before. It's a concept/document/process that has been around for quite some time in the software industry. The original intention being a way for teams or organizations to formalize the approach that they will be taking to testing their product or feature. These days, many teams have evolved their strategies into including not just strictly the specific testing they will be doing but also the processes and approaches that can be taken as a whole to improve the overall quality of the product/feature etc.
This post is going to be all about my personal approach to quality strategies, how it's evolved over time, why I do them the way I do and then a whole lot of details on how you could implement them on your own team or in your company! I also always welcome feedback and would love to know how this differs from the way you've either seen them done or implemented them yourself. With all of that said, let's get started!
What is a Quality Strategy?
A quality strategy is a way for teams, or even organizations, to track the approach that they are taking to quality with respect to a particular product, feature, or organization-wide quality concept.
For teams, this usually means that they will have a quality strategy for each project they work on. That project may be creating a new product, working on adding a big new feature to an existing product, refactoring an existing feature in a product into a microservice etc. Having a quality strategy for teams per project allows them to ensure that they are all on the same page about what quality means, how they're going to be measuring it, and what the approaches are that they will take with respect to it throughout the project. Its goal is to be used as a guideline as the team works through the project that they can reference and update as they learn more or implement new strategies.
For organization-wide quality strategies, this usually means a strategy intended to focus on a particular aspect of quality that can be used as a guideline across all of the teams in the organization. This could be a security quality strategy, or a performance quality strategy, really any quality approach that can be used as a guideline across many teams with respect to a quality initiative. These tend to be more of a best practices guide and outline how to track metrics against this particular type of quality so that trends can be tracked more uniformly across multiple areas of the product.
There's also certainly the case where you may have both within an organization. Teams may have their own quality strategy for their project which also implements the recommendations of the organization with quality strategy with respect to a particular quality approach. So a team can have their own approaches and their approach to performance as a quality measure is just an implementation of the performance strategy that is already in place, with the specifics called out for their particular project.
Why are Quality Strategies useful?
The goal of quality strategies is generally about alignment and understanding. Many teams already have well defined quality processes in place, but they may not have a great way to track them. This can be an issue when you have new people joining the team, or you want to try out a new approach but have no way to measure its success compared to the current approach when you don't have that approach formalized.
By writing down your quality strategy and working through it together you're able to ensure that everyone on your team is in alignment not only on how you're approaching testing and quality but also about what quality means. I'm always surprised by the different things that come up when teams work on defining what having a high quality result will mean for any given project. That exercise alone seems to really help teams to speak the same language and work towards a common goal where quality remains a priority and a focus. By working through the entire strategy you ensure that you're all aligned on how to achieve that result and it makes working through the project less daunting and adds clarity for what it means to successfully complete the project.
Another benefit to having quality strategies in your teams is the focus on quality aspects outside of testing specific tasks. Although we do discuss what types of testing we'll be doing in a project (which we'll cover in more detail later), we also discuss other approaches we may need to take in our development process to improve or maintain quality. These can be things like demos, merge reviews, creating test plans etc. which aren't specific tests we write or perform but do contribute back to the overall quality.
The final benefit I want to discuss for quality strategies is that they let us track changes or decisions we make over time. Maybe we started out using Selenium as a testing framework but then found it didn't suit our needs. We can change our mind and implement Cypress instead. We'll then update our quality strategy to reflect that and call out why Cypress is better for our use case. That lets us understand how things change over time and lets us share that information to improve not only our project's quality, but could also help us to improve other teams as well based on the knowledge we gained and then shared.
Who can benefit from having a Quality Strategy?
When should I create a Quality Strategy?
The best time to create a quality strategy is the beginning of a new project. As your team is kicking off and moving from the ideation phase of a project and into that planning phase creating a quality strategy is a great goal to have. Discussing your quality strategy can really help to plan out the work, help the whole team to understand how much additional time may need to be accounted for with quality initiatives and help to think about things from a quality focused lens.
That being said, the second best time to create quality strategy is as soon as you learn about them. Even if you're halfway through a project it can be really beneficial to just write down what the strategy is that the team has already been following, even if it wasn't formalized. It can be really helpful even towards the end of a project to think things through with that quality mindset and see if there's any gaps we may want to address before we call this project 'done'.
Where should I store a Quality Strategy?
This may seem like a silly question, but I want to address it anyway. Many teams have the instinct to keep team specific documents (which you may view your quality strategy as) in a private workspace. This could be a google drive, wiki, dropbox, etc. that only your team has access to. I highly advise against this. My recommendation is to have your quality strategies stored in a publicly accessible space.
Having your quality strategies in a publicly accessible place means that your strategy can always be used as a reference in the future when a new team may need to work on the product/feature that this strategy is for. It can then be used to help them understand what your team approach was and can be used as a jumping off point for them!
Having them publicly accessible also means that it's easier to share information with other teams. If you have an integration point with another team for example it can be beneficial to understand what their quality processes are and for them to understand yours. This can help make that integration more seamless and allow for great testing across that integration point in collaboration with one another.
Quality Strategy Template
In order to make it as easy as possible for teams to use the quality strategy template I'm going to simply provide a link out to the google doc which can be downloaded and used! Although these are the sections that myself and my teams have found the most helpful, it's important to remember you can change this up in any way that helps your team stay aligned on quality for your project. You may find yourself removing some sections or adding to it over time and that is great! Having your quality strategy template evolve with your team means that they're getting value out of it and it's capturing all of the relevant aspects for your team.
How do I create a Quality Strategy?
This is definitely the heart of this entire post - how do I create a quality strategy? I'm going to call out again that this is my approach to quality strategies and the approach and template that I have been using with my teams. There are definitely many other templates or approaches out there and I encourage you to research them or change this template up in whatever way best fits your team.
This next part is going through the step by step process that I go through with teams as we create our quality strategies. It may be beneficial to open the template in a new window as you are reading through this section since I'll be referencing parts of the strategy template that may be new concepts or just worded differently than you're used to and the explanations for each section live within the template.
With that being said... these are the steps my teams have gone through when creating their quality strategies.
- Have at least a basic understanding of the project goals, plans and resourcing across the team
- Before you can work on a quality strategy for the project, everyone needs to understand what it is and what the intentions are
- Schedule a series of meetings to create your quality strategy
- Trying to tackle the creation of the entire document at once would be overwhelming and exhausting. By breaking it up you increase the engagement you can get from attendees
- How many meetings you need will depend on the size of the team and project, but try to limit them to 1 hour sessions
- Work through the template either outlined above or the template that you have created. The steps from here will be specific to my template
- Project Overview
- Define the project in a way that the entire team can understand and agree on. This is usually a type of elevator pitch for the project which may already exist from the product side of things
- Strategy Scope & Objectives
- Define what the scope of this strategy is (usually either project bounded scope or organization wide scope as we discussed above for things like performance strategies that apply to the whole organization)
- Define what the objective is for having the strategy; usually to produce a high quality product/feature
- Quality Definition
- Define what it will mean to your team to deliver a high quality project
- This could come in the form of quality in relation to the customer experience, the usability, increased accessibility, an easier developer experience for backend work, there's many options for how to define quality and you have quite a few different ones that may all be important to the project
- Quality Metrics
- Based on the definition of quality that the team made, define what metrics you will need to measure that quality effectively
- If you have a performance related definition of quality, you should have a metric to track performance for example!
- Functional Quality Considerations
- Determine what high level considerations will be needed throughout the development of this project and define what they are and what they mean in relation to the project itself
- Disaster Recovery for example is something that may be applicable to the project but it's not something that we necessarily need to do on every single code change or even in every single small feature, it's more of a project wide consideration and may result in it's own piece of code or work unit to address
- Development Level Quality Approaches
- Determine what approaches and test types will be used in the development process throughout the project and define what the expectations and goals are of each
- Generally applies to at least the epic level and many are applicable to every code change
- Once you've decided what testing and approaches will be taken, define where they fit into your development pipeline in terms of when they happen, are created, are run etc.
- Organization & Resourcing
- Define what the organization looks like for owning this project long term, focusing on what teams or subject matter experts may be leveraged as part of that implementation and maintenance
- This section is particularly important to organization-wide quality strategies and allows you to define who is responsible for maintaining that strategy, who may own the framework that is used etc.
- Environment
- Define what environments the code throughout the project will be deployed to, what data is available in those environments and how you would test your code/project in each
- Tools/Libraries
- Define what development tools will be used with this project which could include third party tools and frameworks and how you will test the integration or dependency you have on each
- Frameworks
- Define what testing frameworks will be used throughout the project and add additional details around each or links to documentation for how to write tests within those frameworks
- This should match to the test type you defined in the Development Level Quality Approaches and there should likely be a framework associated with each test type
- Assumptions & Constraints
- Define what assumptions have been made in relation to this project which could be things like this being a proof of concept which will not be used widely, that it's an internal only tool, that some other piece is being developed by another team etc
- Define what constraints the project may have which could include things like requiring backwards compatibility during a refactor, browser requirements, needing to wait for another piece to be developed before yours can release etc.
- Issues & Risks
- Define any risks that are associated with the project and call out how they will be mitigated
- If you've done a Risk Analysis this can just be a link to that document
- Throughout the project, as quality specific issues come up and are addressed use this section to track the issue and the resolution
- Decisions
- In a similar vein to issues, this section can be used to track decisions that may be made that have a substantial impact on your strategy
- If you move away from one process to another for example it's a great spot to track that and highlight why the decision was made
- Have the team review the strategy
- Once the first draft is done have the team members review it themselves to ensure it's accurate and captures their interpretations accurately
- Review your quality strategy on a regular basis
- Once your strategy is made it's important to revisit it from time to time (I like doing this at least every quarter, ideally after each epic in the project is completed) and ensure that it is being followed, that it's still accurate for the process being done on the team, and to highlight any gaps we may need to address with it to improve it moving forward
Wrapping Up
In the end, quality strategies can be very beneficial for teams to get aligned on their approaches to quality, to improve their approaches to quality and to define and share the progress they make around quality with other teams. They take a bit of work up front to get started and some effort to keep up to date but in the end they can really help teams stay on track.
Although I provided my template here it really is up to the team how they want to track their quality strategies. Even if yours is more light weight, or even longer, as long as it captures what matters to your team and everyone is on the same page, it's a great quality strategy. Mine is still evolving and may look different in a year, which I'll be sure to post about! In the meantime, if you have any questions or comments on quality strategies I would love to hear them in the comments to improve my own strategy and help others improve theres as well!
Comments
Post a Comment