Beyond Bugs: What if We Talked About Confidence in QA?

Shifting the conversation from bugs to outcomes and informed confidence.

A few weeks ago, I asked a simple question on LinkedIn: 'If you could change just one thing about how your team talks about QA, what would it be?' My immediate answer? Shifting from 'bugs' to 'confidence.' This sparked a lively debate, with fascinating agreements, disagreements, and new perspectives.

This question was off the back of my recent post, It's about quality, not testing. In it, I argued that if QA's only talk about the testing they perform and the bugs they uncover, they risk being undervalued. This narrow view often sidelines QA, pushing testing to the end of the development process. My core suggestion was to shift the narrative from 'testing' to 'quality.' This doesn't mean we stop testing or reporting bugs, but rather, it means reframing how we talk about these activities, emphasising their contribution to the overall quality that our stakeholders care about. Which ultimately helps them decide if the product is truly ready to ship.

The LinkedIn comments added some great nuance to this view.

Building quality in

Anupam Krishnamurthy reframed his perspective, focusing on building quality into the product from the beginning, with Thomas Howard sharing how 'QA isn't a filter - it's part of the foundation.' Bryan Jones also agreed, emphasising the need to talk about building quality in and providing solid information about the product. I'm hearing about the shift from solely focusing on issue detection to issue prevention, and advocating for quality as a shared responsibility more and more.

The Importance of "Value" and "Outcomes"

Christopher Henderson made a great point: we should be talking more about the value of our efforts and how that connects to the bigger picture. It's all about the story we weave with the work we do and how we share that with others. Ard Kramer made a similar insightful point, suggesting we stop talking about the output of testing and instead focus on how testing contributes to the outcomes our teams and organisations are striving to achieve

The "Confidence" vs. "Information" Nuance

Paul Seaman offered a very insightful perspective: it's not simply about providing confidence, but about providing the information our testing reveals about the product (a point echoed by Bryan Jones). This is crucial, true confidence isn't blind belief that a product functions as intended. It's informed by data that our testing reveals about the product.

Reality Check: But bugs are still important

Michael Bolton made an excellent point: if we don't discuss bugs, it could lead to unwarranted confidence in our products. This highlights that there's still a crucial place for talking about defects. As LogiQ aptly put it, 'Yes, confidence in a product is the ultimate goal of QA, but bugs are the breadcrumbs that lead us there.' Finding issues isn't going away and remains a critical task within engineering teams.

Is QA the correct term?

Wayne Roseberry also highlighted how QA is an incorrect term to be using for testers, which I have to agree with. Testers can't assure quality they can only report on it. And while I don't like using the QA term, most people tend to understand that it covers pretty much any role that involves quality and testing to some degree. So I tend to use it as a shortcut to cover all quality-related roles, which is probably making things worse. Maybe quality professionals is a better catch-all?

Conclusion

I still firmly believe in shifting the narrative from testing to quality, but that's not about ignoring bugs, but recontextualising them. They provide valuable information that helps contribute to the overall picture of informed confidence.

I also believe that testers and all quality professionals should resist the 'bug hunter' label. Instead, let's refocus our efforts on helping teams build quality in from the start. You may not be writing the code, but your insights are invaluable to those who do, contributing to truly great products. This shared responsibility ensures that quality isn't just a QA task, but a collective achievement for the entire team.

What's one way you're helping shift the conversation about quality in your team?