I think it was Jamie Arnold who first introduced me to this phrase.

In engineering teams it’s – sadly – still all too common that Quality Assurance (QA) is the last step in the delivery process. Developers code, then throw it over the wall to QAs to test. Teams working this way typically have a high rate of failure and large release bottlenecks – features and releases pile up, waiting on the QAs. Developers pick up more new work whilst they’re waiting. Bugs come back and developers are now juggling bug fixes and new work.

It’s slow, inefficient and costly!

What I dislike the most is the cultural aspect – the implication that quality is the responsibility of QAs, not the developers who wrote the code.

Quality is a team sport. The most valuable role for QAs* is to ensure quality is baked into the entire end-to-end delivery process. This has become known as “shift-left” – QAs moving away from spending all their time at the end of the delivery lifecycle and focusing more on how we can “build quality in” throughout.

What does this look like in practice?

– QAs involved in requirements gathering and definition, making sure requirements are clear, well understood and we’ve considered how we’re going to test it (inc. automated tests).

– QAs ensure we’re following our agreed Software Delivery Lifecycle (SDLC) and the steps and control we have in place to ensure quality is front of mind.

– QAs collaborate with developers to write automated tests, developers collaborate with QAs on mutation testing, compatability testing, performance testing.

– If there’s any manual testing required, /everyone gets involved/. QAs make sure everyone in the team is capable of doing it.

It’s a much richer role for QAs, and far better for everyone!



*Some teams don’t have QAs. That’s fine, I’m agnostic, as long as everyone cares about quality 🙂