Early in my career, I believed that quality engineering was about finding bugs. The more bugs you caught, the better QA engineer you were. The job was simple: stand at the end of the pipeline, test the software, send it back when it failed.
That mental model broke somewhere around my third year at Al Jazeera. We had strong automation, rigorous test plans, and a QA team that was genuinely good at its job. And yet, we kept shipping defects that our automation had never seen — because they were coming from decisions made upstream, in design meetings and sprint planning sessions we weren't in the room for.
The Gatekeeping Trap
The traditional QA model is a gatekeeping model. QA sits at the end, decides what passes and what doesn't, and the rest of the team waits. This creates a perverse incentive: developers rush to get something "over the wall" to QA, QA rushes to get it back, and quality becomes a score rather than a property of the work itself.
The problem isn't the people. It's the structure. When quality is owned by a single team, the rest of the organisation is implicitly absolved of owning it.
"Quality is not what happens in the QA phase. Quality is what happens in every decision made before code is ever written."
What Actually Works
The shift that made the biggest difference — at Toptal and later back at Al Jazeera — was moving quality thinking upstream. This meant:
- Being in the room early. QA presence in sprint planning, story refinement, and design reviews changes what gets built, not just how it gets tested.
- Shared test ownership. When developers write unit tests and own them, quality becomes a craft conversation rather than a handoff.
- Making quality visible. Dashboards, coverage metrics, defect escape rates — data changes conversations from "we think it's fine" to "here's what we know."
- Treating test code as production code. Automation that nobody maintains is worse than no automation. It generates false confidence.
The Harder Part: Culture Change
None of this is technically difficult. The hard part is the human part — getting developers, product managers, and leadership to see quality as their shared problem, not the QA team's problem.
The most effective lever I found was asking one question in every retrospective: "What decision, made earlier in the sprint, created the bug we found at the end?" When you trace defects to their root cause — which is almost never "the tester missed it" — the conversation naturally shifts.
On Tools and Frameworks
I have strong opinions about Playwright, Pact, and contract testing at scale. But I've learned that the team that has a mediocre framework and genuinely owns quality will outperform the team with perfect tooling and a gatekeeping mindset every time.
Start with the culture. The tools will follow.
If this resonated, I'm easy to reach. Or connect on LinkedIn.
Did this resonate?
Share this article