Introduction
I wrote this guide because I’ve struggled to find useful, practical articles to share with QAs and teams for how to shift away from traditional testing approaches to defect prevention. It’s also based on what I’ve seen work well in practice.
More than that, it comes from a frustration that the QA role – and the industry’s approach to quality in general – hasn’t progressed as much as it should. Outside of a few pockets of excellence, too many organisations and teams still treat quality as an afterthought.
When QA shifts from detecting defects to preventing them, the role becomes far more impactful. Software quality improves, delivery speeds up, and costs go down.
This is intended a practical guide for QA specialists who want to move beyond testing into true quality assurance. It’s also intended to be relevant for anyone involved in software development who cares about building quality in.
The QA role hasn’t evolved
Something similar happened to QA as it did with DevOps. At some point, testers were rebranded QAs, but largely kept doing the same thing. From what I can see, the majority of people with QA in their title are not doing much actual quality assurance.
Inspection doesn’t improve quality, it just measures of a lack of it.
Too often, QA is treated as the last step in delivery – developers write code, then chuck it over the wall for testers to find the problems. This is slow, inefficient, and expensive.
Unlike DevOps (which is a collection of practices, culture and tools, not a job title), I believe there’s still a valuable role and place for QA specialists, especially in larger orgs.
QA’s goal shouldn’t be just to find defects, but to prevent them by embedding quality throughout the development process – not just inspecting at the end. In other words, we need to build quality in.
The exponential cost of late defects and delivery bottlenecks
The cost of fixing defects rises exponentially the later they are found. NASA research1Error Cost Escalation Through the Project Life Cycle Stecklein et al 2004 confirms this, but you don’t really need empirical studies to substantiate this, it’s pretty simple:
The later a defect is found, the more resources have been invested. More people have worked on the it, and fixing it involves more rework – it’s easy to tweak a requirement early, but rewriting code, redeploying, and retesting is much more expensive. In production, they impact users, sometimes requiring hotfixes, rollbacks, and firefighting that disrupts everything else. Beyond direct costs, there’s the cumulative cost of delay – the knock-on effect to future work.
Late-stage testing isn’t just costly – it’s often the biggest bottleneck in delivery. Most teams have far fewer QA specialists than developers, so work piles up at feature testing (right after development) and even more at regression testing. Without automation, regression cycles can take days or even weeks.
As a result, features and releases stall, developers start new work while waiting, and when bugs come back, they’re now juggling fixes alongside new development. It’s an inefficient and expensive way to build software.
The origins of Build Quality In
“Build Quality In” originates It comes from lean manufacturing and the work of W. Edwards Deming and Toyota’s Production System (TPS). Their core message: Inspection doesn’t improve quality – it just measures the lack of it. Instead, they focused on preventing defects at the source.
Toyota built quality in by ensuring that defects were caught and corrected as early as possible. Deming emphasised continuous improvement, process control, and removing reliance on inspection. These ideas have shaped modern software development, particularly through lean and agile practices.
Despite these well-established principles, QA and testing in many teams hasn’t moved on as much as it should have.
From gatekeeper to enabler
Quality assurance shouldn’t be a primarily late stage checkpoint, it should be embedded throughout the development lifecycle. The focus must shift, left. Upstream.
This means working closely with product managers, designers, BAs, developers from the start and all the way through, influencing processes to reduce defects before they happen.
Unless you’re already working this way, it probably means working a lot more collaboratively and pro-actively than you currently are
Be involved in requirements early
QA should be part of requirements discussions from the start. If requirements are vague or ambiguous, challenge them. The earlier gaps and misunderstandings are addressed, the fewer defects will appear later.
Ensure requirements are clear, understood and testable
Requirements should be specific, well-defined, and easy to verify. QA specialists should work with the team to make sure everyone is clear, and be advising on appropriate automated testing to ensure it’s part of the scope.
If those criteria are not met, it’s not ready to start work (and it’s your job to say so). Outside of refinement sessions/discussions, I’m a fan of a quick Three Amigos (QA, Dev Product) before a developer is about to pick up a new piece of work from the backlog
Collaborating with developers
QA specialists and developers should collaborate throughout development, not just at the end. This means pairing on tricky areas and automated tests, having open discussions about risks and edge cases. The earlier QA provides input, the fewer defects make it through.
Encourage test automation
QA should help developers think about testability as they write code. Encourage unit, integration, and end-to-end tests as part of the development process, rather than relying on manual testing later. If a feature isn’t easily testable, that’s a design flaw to address early.
Get everyone involved with manual testing
Manual testing shouldn’t be a bottleneck owned solely by QA. Instead of being the sole tester, be the specialist who enables the team. Teach developers and product managers how to test effectively, guiding them on what to look for. (Note: the clearer the requirements, the easier this becomes – good testing starts with well-defined expectations). Having everyone getting involved in manual testing not only removes bottlenecks and dependencies, it tends to mean everyone cares a lot more about quality
Embedding Quality in the SDLC
Quality isn’t something to check at the end – it should be built into every stage of the SDLC (Software Delivery Lifecycle). QA specialists should ensure requirements are clear and testable before work starts, collaborate with developers during coding to embed testability, and prevent late-stage bottlenecks by testing incrementally rather than leaving everything to a final phase. Post-release, production issues should feed back into the process, driving continuous improvement. When QA is fully embedded, quality becomes part of how work gets done, not a separate step.
Incident analysis and fixing root causes
Every production defect is an opportunity to improve. Instead of just fixing the immediate issue, QA’s should dig deeper – was it caused by unclear requirements, missing test coverage, or gaps in deployment processes? Recurring issues often signal systemic weaknesses, not just individual mistakes. Post-mortems should be about learning, not blame, ensuring that fixes don’t just patch symptoms but prevent similar problems in the future. The best teams treat incidents as a way to refine their development process over time. QA specialists should be front and centre in all of this.
Shifting from Reactive to Proactive
There are far more valuable things a QA specialist can be doing with their time than manually clicking around on websites. Performance testing, exploratory testing, reviewing static analysis, reviewing for common recurring support issues, accessibility. The list goes on and on. QA should be driving these conversations, ensuring quality isn’t just about finding defects, but about making the entire system stronger.
The value of modern QA specialists
I firmly believe QA specialists still have a valuable place in modern software teams, especially in larger organisations. I don’t want to see their role disapper but I want it to evolve faster. The traditional tester role needs to go. The best QA specialists aren’t testers; they’re quality enablers who shape how software is built, ensuring quality is embedded from the start rather than checked at the end.
This isn’t just better for organisations and teams – it makes the role QA a far richer, more rewarding career.On multiple occasions I’ve seen QA specialists who embody this approach go on to become Engineering Managers, Heads of Engineering and other leadership roles.
The demand for people who drive quality, improve engineering practices, and embed testing into development isn’t going away. If anything, with the rise of GenAI generated code, it’s becoming more critical than ever.