Impact
Key outcomes
Context
The problem with the old model
The team had outgrown a traditional QA workflow where development happened first and quality validation happened later. That model made QA the final bottleneck, delayed feedback, and encouraged a false assumption that one function could "own" product quality alone.
As product complexity increased across mobile, web, and backend services, the costs became visible: recurring regressions, slow release cycles, and too much energy spent on late-stage verification instead of prevention.
What needed to change
- Developers needed earlier quality signal and clearer ownership
- Automation investment had to be tied to business risk, not volume
- Release confidence needed to come from systems, not heroics
My role
What I owned directly
- Defined and socialised the Quality Assistance model across the engineering team
- Designed the automation strategy for Android, web, and API layers
- Introduced lean test pyramid principles to improve feedback speed and suite quality
- Integrated continuous testing into CI/CD and strengthened release-readiness workflows
- Coached engineers on shift-left testing, acceptance criteria, and risk-based thinking
- Used production monitoring and quality metrics to guide where intervention was needed most
Approach
How the model worked in practice
1. Shift quality left
I worked with developers earlier in the lifecycle: shaping acceptance criteria, identifying edge cases up front, and improving testability before implementation hardened.
2. Prioritise by risk
Instead of automating everything, I focused on flows where failure would block learning journeys, break assessments, or silently corrupt data.
3. Build a lean test pyramid
Broad API coverage, selective UI coverage, and only critical-path E2E tests produced faster and more reliable signal than a UI-heavy approach.
4. Put feedback inside delivery
Test execution moved into pull request and CI workflows so quality feedback reached developers immediately rather than after a separate QA phase.
Key decision
QA as amplifier, not approver
The most important change was role definition. QA stopped acting as the final approver of quality and started amplifying the team’s ability to build quality in from the start through coaching, systems design, and targeted exploratory work.
Results
What changed after the shift
- Post-release defects dropped sharply The team achieved an 80% reduction because the highest-risk issues were caught earlier.
- Automation became faster and more useful Execution speed improved by 70% because suite design became more intentional and less UI-heavy.
- Delivery moved faster with less uncertainty Test cycle time dropped by 25% and time-to-market improved by 20% after quality checks were integrated into CI/CD.
- Quality ownership became normalised Developers increasingly wrote and maintained tests for their own features rather than relying on handoff-based QA.
Stack
Tools and systems involved
- Kaspresso for Android automation
- Playwright and Cypress for web coverage
- GitHub Actions and CI/CD workflows for continuous testing
- Sentry for production monitoring and regression visibility
- Metabase for quality metrics and SLA tracking
- Testomat for test management and reporting structure
Takeaway
Why this case study matters
This project is the clearest representation of how I work: I do not just build test suites. I redesign quality systems so engineering teams can move faster, make better decisions, and sustain reliability as complexity grows.