At the start of a project, every software development team sets out with a vision of creating high-quality software and a commitment to delivering it. But, as costs rise, deadlines approach, and stakeholder requirements shift, maintaining that commitment can be extremely challenging. These challenges often call for trade-offs, distracting the teams from their original quality-first vision.
To stay on track and maintain the commitment to quality that they began the project with, every team needs voices that push for software quality — continuously advocating for it as conditions and requirements change.
Increasingly, Quality Analysts are stepping into that role — going beyond basic bug-hunting and seizing the opportunity to become Quality Advisors. These Quality Advisors help keep decision-making aligned, mediate trade-off conversations, support collaboration, and maintain a quality-first mindset across the development team.
It’s a role I've frequently stepped into myself, and one I’ve learned much about during my career. I share here five tenets that have helped me play the role of Quality Advisor for my teams.
Empower your team with relevant knowledge
Communication is essential for maintaining quality in any project — and software development is no exception. Once teams understand why something is required to maintain software quality, and they’re given a chance to discuss it, they’re far more likely to stick with it.
For example, if teams find themselves questioning some of the more laborious aspects of the quality testing process, like dev box testing or writing tests at different layers, they’ll see them as a chore, stop owning them, and eventually not engage with them unless directly mandated or monitored.
Every time I join a new team, I have an open session to discuss quality-related topics. We often document and share key practices, so we can look back on them and ensure they’re accounted for if our team changes. I also make the effort to impart relevant knowledge to business stakeholders, encouraging them to make decisions that put quality first.
But this knowledge sharing and conversation shouldn’t be a one-off exercise. It needs to be a continuous process, with teams regularly meeting to discuss and catch up on quality-related items. I frequently invite QAs and developers to talk about the tools or methods they’re experimenting with and share articles about testing with the team, even if they’re not immediately relevant to the project. Every one of these discussions or touchpoints serves a purpose: keeping quality at the front of the team’s mind and giving them a voice in how it’s upheld.
Collaborate with team members closely
Quality Advisors can have a lasting impact when they can demonstrate the ‘how’ of the quality-first mindset. They need to show how everyone can influence quality and become an advocate for it themselves. To do this, you need to collaborate with the entire team to build a robust quality strategy that’s both comprehensive and realistic.
For instance, collaborate with business stakeholders to seed quality into feature discussions and educate them on the benefits of prioritizing quality aspects. Similarly, by working with business analysts, you can help review stories to identify missing edge cases or collaborate during IPMs to call out missing CFRs.
The other major benefit of close collaboration with everyone across the team is that it can help you identify the pain points that lead to reduced software quality, and alleviate many of them. Some of the most common issues in test strategy that I’ve seen are:
The test framework needs a workstation setup that’s different from the development setup
Tests are fragile and give false feedback
The team finds it difficult to track all the cross-functional testing scenarios
If these issues aren’t addressed, they can have a significant impact on quality, and I wouldn’t have discovered any of them without pairing and collaborating with developers.
Additionally, you can adopt relevant tools to enhance collaboration on quality. For instance, a living mindmap of application-specific functional and cross-functional test cases can be a common practice to collaborate across roles.
There are specific practices too that can help teams hone quality collaboratively. Some of the most successful practices I’ve seen are:
Pair programming to enhance code quality
Story kickoff, dev box testing, etc. where BAs, QAs, and dev pairs catch up before and after development to hash out the quality aspects
Architectural decision records (ADRs)
Sticking to continuous integration certification test
Spikes before picking a tool
Overall, collaborate with teams daily wherever needed to instill awareness around the quality-first approach so it’s always at the front of their minds.
Track quality metrics
If you want to sustain enthusiasm for your quality-first approach, the best way to win long-term support is to clearly demonstrate its value. When there’s enough evidence that the practices yield results, the team will naturally want to follow them.
Some metrics that I’ve found useful to track are:
Defects caught by automated tests in all layers: Automated tests create a safety net for the team, helping to detect a majority of defects early. Tracking this metric helps reinforce the strength and importance of that safety net and gives teams the confidence to make changes.
Time taken from commit to deployment: Fast feedback is critical to make progress. If the time taken from commit to deployment — which includes running automated tests — is an hour, then there’s productivity loss in the whole cycle for all roles.
Number of automated deployments to testing environments: This and the previous parameters will show the tempo of the team in making new changes. Ideally, you need the team to be set up with a good safety net that will yield faster and more stable deployments.
Regression defects caught during story testing or manual testing: Regression defects found during manual testing indicate a missed business use case or an automated test. Tracking them can enable teams to reflect on the root causes of these defects, helping to avoid them in the future.
Automation coverage of functional and cross-functional requirements: Teams should keep track of their coverage across all layers with the goal to have no backlog. You should also track your automation coverage for the application’s cross-functional requirements such as performance, security, accessibility, visual quality, etc.
Production defects and their severity: This shows you the bigger picture of missing business use cases, missing configuration, data mismatch, or anything else the team may have overlooked.
Start by identifying their root causes and automating tests around them. It’s also worth building a living test strategy that can evolve as the application and team venture into new ground.
Failures due to infrastructure issues: By tracking how frequently infrastructure issues lead to failures in testing environments, you can detect inconsistencies between dev and test environments that can lead to repeated quality issues.
Many of these metrics tie back to the ‘4-key metrics,’ which measure quality in terms of stability and delivery tempo. For instance, when there’s a good safety net of automation coverage, the team can make changes confidently. As Nicole Forsgren, Jez Humble, and Gene Kim recommend in their book, Accelerate, the time for change for a high-quality performer should be less than an hour, with teams effectively achieving on-demand deployment.
Image source: a page from Accelerate
When you measure the time taken from commit to deployment, and the number of deployments in a day to testing environments, you discover the team’s delivery tempo. Production defects will tell you about the change fail percentage, which for a high performer should be 0-15%.
When tracked and discussed consistently, these metrics let the team develop a common language to collaborate in and shared goals to work towards. This builds the team's confidence in their way of working and what they’re producing — supporting high-quality outputs.
Build team and stakeholder confidence in quality
The greater a team’s confidence in their ability to deliver high-quality software, the higher the chance that they’ll actually deliver it. Here are a few techniques I’ve used in the past to improve team and stakeholder confidence:
Hosting bug bashes where teams use the application end-to-end in various scenarios to root out bugs. When quality practices are followed correctly, teams should only find trivial bugs, which should boost their confidence in their abilities.
Iteration showcases where we share metrics and talk about how they help the business directly. For example, the fact that it took 15 mins to run all tests and deploy ten times to QA environments on average shows how quickly they can go to market with stability.
Holding retrospectives where teams discuss quality-related feedback, both positive and negative. This platform also helps business stakeholders hear about the wider team’s confidence in application quality, which in turn builds confidence in them.
Story sign-off sessions where we walk client stakeholders through functional test cases, beyond just the acceptance criteria, to give them a sense of broader and deeper quality. Once they’ve seen first-hand what good quality software looks like, they’re more likely to prioritize it.
Building dashboards to show the consistency of quality being built in for external and internal teams.
Showing individual appreciation to individuals who have gone the extra mile to achieve quality — whether that’s enhancing a test framework, or reporting defects when they’re found accidentally — to affirm the quality-first mindset.
Be a beacon of quality
As a Quality Advisor, it’s your job to be the sensor that raises alarms when quality goes down and the bright green light that shines when the team does a tremendous job.
I remember in one of my teams, defects began surging suddenly. When looking for patterns, I noticed that whenever there were changes to DB-related code, there were defects in the surrounding areas. I called a quick team meeting and shared my observations. The team soon identified the area of code that needed refactoring and we added a tech debt card. Doing this before any other story helped the team save a lot of to-and-fro defect fixing, and helped them watch out for similar bad code patterns in the future.
If you can make the team proud of the quality they’ve delivered, you’re most of the way towards inspiring a quality-first mindset. Be an advocate for the work the team has done, help them see their impact on quality, and inspire them to keep striving for higher and higher product quality across their projects.
Becoming quality-first
The transition towards a quality-first development team is certainly not a one-person job. But you, as the Quality Advisor, can bring about significant technological and cultural changes by being the catalyst for the process. By educating, strategizing, planning, implementing, and following through on quality aspects, you can help operationalize software quality as a priority, and consistently improve software outcomes and team satisfaction.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
