It’s about quality, not testing
When QA roles focus too much on testing, especially finding bugs, they risk being seen as less valuable to engineering teams. We get pushed to the end of the process and are seen as just testers, not collaborators. That mindset not only sidelines us but also narrows what quality really means.
It’s no wonder QA is often left out of early discussions, when we’re seen as the final check, we’re excluded from the start.
From testing to quality
What we need to do is shift the narrative from testing to quality. More specifically, it means helping teams understand how quality is created, maintained, and lost within socio-technical systems. That's not to say that QA's no longer do testing or, more accurately, inspect for quality, but that the value lies in helping teams build and maintain quality, not just reporting whether it’s present.
How do we make this shift from testing to quality?
This is not likely to be an easy shift for most organisations without leadership buy-in. There is a good chance that a lot of leaders are likely to think you're making a fuss over words. But a good place to start is what you can control:
1. Shift Your Language to Shift the Narrative
Stop framing your work around what you tested and what bugs you found. Start talking about what your testing revealed about quality.
Instead of: “We tested A, B, and C and raised 5 bugs.”
Try: “Quality in these areas is currently at risk due to regressions in X and unclear behaviour in Y. Confidence in releasing remains low until these are addressed.”
This reframes your work as contributing insight into product health, not just delivering test results.
2. Frame Engineering Practices as Creating and Maintaining Quality
Help your team see that quality isn’t just something you inspect for but something you build in. For example:
Highlight how TDD improves code quality through clean, tested code.
Show how pairing, code reviews, or static analysis all contribute to maintaining quality by catching issues earlier.
Reposition automated UI tests not just as “coverage” but as early feedback loops on the user experience.
This builds a narrative that quality is everyone's responsibility, and QA helps make it visible.
3. Use Real Examples of Quality Loss
Stories change minds better than data, so bring examples from adjacent teams, past incidents, or industry news to show the real impact of quality loss. For example:
A missed redirect that broke login flows.
A stale test environment that led to a production bug.
A lack of observability that turned a minor defect into a major outage.
Ask: “Could something similar happen to us? What early signals might we be missing?”
4. Talk About Feedback, Not Just Testing
Every time you say “testing,” try asking yourself: “What feedback are we getting from this?” This helps reposition testing as part of a larger feedback ecosystem:
Feedback from users (support tickets, social media, app store reviews).
Feedback from production (metrics, logs, errors).
Feedback from code (unit tests, linters, CI failures).
This starts getting people looking at testing as one of many tools, not the only one.
5. Evolve Your Docs from 'Test Strategy' to 'Quality Strategy'
If you've got the appetite for more radical change, then start expanding the test documentation scope:
Rename it to Quality Strategy.
Include how the team maintains and monitors quality, not just how it tests.
Add a section on “Historical Quality Losses”, what’s gone wrong before, and which practices help prevent similar issues now. This creates shared memory, encourages forward thinking, and shows QA’s broader value.
Over time, this shifts the narrative: from QA as testers to QE's as stewards of quality. It shows our value isn’t just in inspecting for quality, but in helping teams build quality in from the start, not the end.
Quality Engineering Newsletter is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Don't just stop there
Other smaller nudges that can shift the narrative from testing to quality:
Champion Quality Beyond the Test Case: Propose lightweight reviews of requirements, designs, and pull requests with a quality lens (e.g. usability, resilience, testability).
Encourage small feedback loops: Help teams adopt practices like feature toggles, dark launches, or canary releases to further the narrative around other ways to get feedback about the product.
Run test strategy workshops with developers to explore risks and trade-offs rather than dictate coverage. Switch the narrative from what you want to what they can do.
Introduce exploratory testing sessions as a team activity, not just a QA task. To help uncover gaps and encourage shared curiosity.
Create a “Quality Signals” dashboard to track key metrics, including defect trends, lead time to fix, flaky tests, and production incidents. Then use this to tell stories with data using bugs and test findings to illustrate systemic issues, not just symptoms.
Collaborate with product, support, and UX: Understand what quality means from their perspectives and incorporate that into the team's definition of quality.
Review user feedback or support tickets regularly and feed insights back into the team’s priorities.
Don’t say “it's tested”, say “we have confidence in…” and explain what’s been tested, what hasn’t, and where uncertainty lies.
Introduce “risk-based coverage”: Help teams prioritise test depth where it matters most and show that you're being pragmatic about not testing everything.
Advocate for testability through feature-level logging, stubs, IDs for automation, and other testability hooks during development to help build quality in.
Create feedback tools for non-technical team members to trigger tests, view quality signals, or explore features safely.
Run internal “Quality Clinics” on topics like resilience, risk storming, or testing heuristics.
Write up learnings from bugs or outages and turn them into team-wide lessons (e.g. “5 questions we now ask before we ship”).
Closing
Whether it’s shifting your language or running team-wide quality clinics, every step helps reposition QE's as a partner in building quality, not a checkpoint at the end. And when teams see that, they’ll stop asking if something has been tested and start asking how we know it’s good to ship.
What do you think? Have you shifted the narrative from testing to quality, or are you just getting started with it? Perhaps you disagree and believe we should still focus on testing? Let me know in the comments.