Transforming QA from Gatekeeper to Quality Assistance
Context
Bykea's QA team was the last line of defense before every release. Engineers threw code over the wall, QA found bugs, devs fixed them, repeat. This model was creating slow releases, adversarial dev/QA dynamics, and a culture where quality was QA's problem — not the whole team's.
Decision
Shift the entire QA function from traditional Quality Assurance (finding bugs late) to Quality Assistance (embedding quality thinking from day one)
Alternatives Considered
Hire more QA engineers to speed up reviews
- Immediate capacity increase
- No process change required
- Low disruption to existing teams
- Doesn't fix the root cause (late-stage quality)
- Expensive and doesn't scale
- More people in the bottleneck doesn't remove the bottleneck
Automate the existing QA gate
- Faster regression execution
- Reduces manual effort
- Still a gate — just a faster one
- Doesn't change the cultural dynamic
- Automation of a broken process is still a broken process
Embed QA thinking throughout the development lifecycle
- Quality becomes everyone's responsibility
- Bugs caught earlier = cheaper fixes
- Better dev/QA relationship and shared ownership
- QA engineers become strategic contributors, not manual testers
- Significant cultural change required
- Needs buy-in from engineering leadership and product
- Takes 2-3 sprint cycles before results show
Reasoning
The fundamental problem wasn't testing speed — it was testing placement. Every bug found in QA had already cost developer time to write, reviewer time to approve, and QA time to re-test after fix. Moving quality upstream meant all those costs dropped. The cultural shift was harder than the technical one, but the ROI was undeniable: 50% reduction in QA cycle time and 20% fewer production bugs within two quarters.
The Breaking Point
By 2022, Bykea had grown to 3+ squads shipping features simultaneously. The QA queue was the most visible bottleneck on every sprint board. Developers would finish features days before QA could review them. By then, context had switched, bug fixes took longer, and release dates slipped.
More damaging was the culture: developers saw QA as a hurdle, not a partner. “Is QA done yet?” was the most dreaded question in sprint planning.
The Shift
Quality Assurance asks: “Does this work correctly?”
Quality Assistance asks: “How do we make sure this is correct from the start?”
The practical changes:
1. QA in Epic Reviews (not just Sprint Testing)
QA engineers now joined epic kick-offs and user story refinement. Before a line of code was written, we were asking: What does success look like? What are the failure scenarios? What’s the acceptance criteria?
This sounds simple. The impact was enormous. Vague acceptance criteria — the root cause of most late-stage rework — got caught before development even started.
2. Developers Own Unit + Integration Tests
We redrew the testing responsibility boundary. Developers were responsible for unit tests and basic integration tests on their own code. QA focused on system-level, E2E, and exploratory testing — the work that genuinely requires external perspective.
3. Shared Quality Metrics
Instead of “bugs found by QA” as the success metric, we moved to “bugs found in production” as the shared failure metric. When the whole team’s sprint velocity depended on keeping production stable, everyone cared about quality — not just QA.
4. Post-Mortems as a Ritual
Every production bug became a learning moment with a lightweight post-mortem: what happened, why it wasn’t caught earlier, and what process change would prevent the next one.
Results
- QA cycle time reduced by 50% within two sprint cycles
- Production bug leakage dropped 20% over six months
- Dev/QA relationship shifted from adversarial to collaborative
- QA engineers started being included in product strategy discussions, not just test execution
What I’d Tell My Past Self
Start with one squad. Don’t try to change everything at once. Pick one team, embed a QA engineer as a true squad member, and let the results speak for themselves. The social proof from one successful squad converts skeptical engineers faster than any top-down mandate.