Monthly Archives: February 2025

Building Quality In: A practical guide for QA specialists (and everyone else)

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.

Are we undervaluing the benefit of junior developers?

With the rise of GenAI coding assistants, there’s been a lot of noise about the supposed decline of junior developer roles. Some argue that GenAI can now handle much of the grunt work juniors traditionally did, making them redundant. But this perspective is short-sighted. Junior developers bring far more to the table than just writing code, and if anything, GenAI highlights just how valuable they really are.

Developers only spend a small amount of time coding

As I covered in this article, developers spend surprisingly little time coding. It’s a small part of the job. The real work is understanding problems, solving problems, designing solutions, collaborating with others, and making trade-offs. GenAI might be able to generate some code, but it doesn’t replace the thinking, the discussions, and the understanding that go into good software development.

Typing isn’t the bottleneck. I’ve written about this before, but to reiterate – coding is only one part of what developers do. The ability to work through problems, ask the right questions, and contribute to a team is far more valuable than raw coding speed and perhaps, even deep technical knowledge (go with boring common technology and this is less of a problem anyway).

If coding isn’t the bottleneck, and collaboration, problem-solving, and domain knowledge matter more, then the argument against juniors starts to fall apart.

What juniors bring to the table

One of the best examples I’ve seen of this was when we started our Technical Academy at 7digital. One of our first cohort came from our content ingestion team. They’d played around with coding when they were younger, but had never worked as a developer. From day one, they added value – not because they were churning out lines of code, but because they were inquisitive, challenged assumptions, and made the team think harder about their approach. They weren’t bogged down in the ‘this is how we do things’ mindset. (It also benefited they had great industry and domain knowledge, which meant they could connect technical decisions to real business impact in ways that even some of our experienced developers struggled with).

This is exactly what people underestimate about junior developers. In the right environment, curiosity and problem-solving ability are far more important than years of experience. A good junior can:

  • Ask the ‘stupid’ questions that expose gaps in understanding.
  • Challenge established ways of working and provoke fresh thinking.
  • Improve team communication simply by needing clear explanations.
  • Bring insights from other disciplines or domains.
  • Grow into highly effective engineers who understand both the tech and the business.

GenAI doesn’t replace the learning process

There’s also the issue of long-term talent development. If we cut off junior developer roles, where do our future senior engineers come from? GenAI might make some tasks easier, but it doesn’t replace the learning process that happens when someone grapples with real-world software development (one challenge, however, is ensuring junior devs don’t become over-reliant on GenAI and still develop fundamental problem-solving skills).

Good juniors add more value than we often realise. They bring energy, fresh perspectives, (and even sometimes, domain knowledge) that makes them valuable from day one. In the right environment, they’re not a cost – they’re an investment in better thinking, better collaboration, and ultimately, better software.

Rather than replacing junior developers, GenAI highlights why we need them more than ever. Fresh thinking, collaboration, and the ability to ask the right questions will always matter more than just getting code written.

And that’s precisely why juniors still matter.

A plea to junior developers using GenAI coding assistants

The early years of your career shape the kind of developer you’ll become. They’re when you build the problem-solving skills and knowledge that set apart excellent engineers from average ones. But what happens if those formative years are spent outsourcing that thinking to AI?

Generative AI (GenAI) coding assistants have rapidly become popular tools in software development, with as many as 81% of developers reporting to use them. 1Developers & AI Coding Assistant Trends by CoSignal

Whilst I personally think the jury is still out on how beneficial they are, I’m particularly worried about junior developers using them. The risk is they use them as a crutch – solving problems for them rather than encouraging them to think critically and solve problems themselves (and let’s not forget: GenAI is often wrong, and junior devs are the least likely to spot its mistakes).

GenAI blunts critical thinking

LLMs are impressive at a surface level. They’re great for quickly getting up to speed on a new topic or generating boilerplate code. But beyond that, they still struggle with complexity.

Because they generate responses based on statistical probability – drawing from vast amounts of existing code – GenAI tools tend to provide the most common solutions. While this can be useful for routine tasks, it also means their outputs are inherently generic – average at best.

This homogenising effect doesn’t just limit creativity; it can also inhibit deeper learning. When solutions are handed to you rather than worked through, the cognitive effort that drives problem-solving and mastery is lost. Instead of encouraging critical thinking, AI coding assistants short-circuit it.

Several studies suggest that frequent GenAI tool usage negatively impacts critical thinking skills.

I’ve seen this happen. I’ve watched developers “panel beat” code – throwing it into an GenAI assistant over and over until it works – without actually understanding why 😢

GenAI creating more “Expert Beginners”

At an entry-level, it’s tempting to lean on GenAI to generate code without fully understanding the reasoning behind it. But this risks creating a generation of developers who can assemble code but quickly plateau.

The concept of the “expert beginner” comes from Erik Dietrich’s well known article. It describes someone who appears competent – perhaps even confident – but lacks the deeper understanding necessary to progress into true expertise.

If you rely too much on GenAI code tools, you’re at real risk of getting stuck as an expert beginner.

And here’s the danger: in an industry where average engineers are becoming less valuable, expert beginners are at the highest risk of being left behind.

The value of an average engineer is likely to go down

Software engineering has always been a high-value skill, but not all engineers bring the same level of value.

Kent Beck, one of the pioneers of agile development, recently reflected on his experience using GenAI tools:

Kent Beck Twitter post “I’ve been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant. The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate”

This is a wake-up call. The industry is shifting. If your only value as a developer is quickly writing pretty generic code, the harsh reality is: if you lean too heavily on AI, you’re risking making yourself redundant.

The engineers who will thrive are the ones who bring deep understanding, strong problem-solving skills, the ability to understand trade-offs and make pragmatic decisions.

My Plea…

Early in your career, your most valuable asset isn’t how quickly you can produce code – it’s how well you can think through problems, how well you can work with other people, how well you can learn from failure.

It’s a crucial time to build strong problem-solving and foundational skills. If GenAI assistants replace the process of struggling through challenges and learning from them (and from more experienced developers), and investing time to go deep into learning topics well, it risks stunting your growth, and your career.

If you’re a junior developer, my plea to you is this: don’t let GenAI tools think for you. Use them sparingly, if at all. Use them in the same way most senior developers I speak to use them – for very simple tasks, autocomplete, yak shaving. But when it comes to solving real problems, do the work yourself.

Because the developers who truly excel aren’t the ones who can generate code the fastest.

They’re the ones who problem solve the best.


The evidence suggests GenAI coding assistants offer tiny gains – real productivity lies elsewhere

GenAI coding assistants increase individual developer productivity by just 0.7% to 2.7%

How have I determined that? The best studies I’ve found on GenAI coding assistants suggest they improve coding productivity by around 5-10%.1see the following studies all published in 2024: The Impact of Generative AI on Software Developer Performance, DORA 2024 Report and The Effects of Generative AI on High Skilled Work: Evidence from Three Field Experiments with Software Developers

However, also according to the best research I could find, developers spend only 1-2 hours a day on coding activity (reading/writing/reviewing code).2see Today was a Good Day: The Daily Life of Software Developers, Global Code Time Report 2022 by Software

In a 7.5-hour workday, that translates to an overall productivity gain of just 0.7% to 2.7%.

But even these figure aren’t particularly meaningful – most coding assistant studies rely on poor proxy metrics like PRs, commits, and merge requests. The ones including more meaningful metrics, such as code quality or overall delivery show the smallest, or even negative gains.

And as I regularly say typing isn’t the bottleneck anyway. The much bigger factors in developer productivity are things like:

  • being clear on priorities
  • understanding requirements
  • collaborating well with others
  • being able to ship frequently and reliably.

GenAI might slightly speed up coding activity, but that’s not where the biggest inefficiencies lie.

If you want to improve developer productivity, focus on what will actually make the most difference