← Case Studies

Flagship Case Study

Replacing QA gatekeeping with a Quality Assistance model.

This work changed quality from a downstream checkpoint into an engineering capability shared by developers, QA, and release processes.

Led the operating-model shift, the automation strategy behind it, and the delivery practices that made the change durable across a growing product team.

Summary
  • Role Lead Software QA Engineer
  • Focus Quality operating model, automation strategy, CI/CD integration, release confidence
  • Outcome 80% fewer post-release defects and a faster, more accountable engineering workflow

Impact

Key outcomes

80% reduction in post-release defects
70% improvement in automated execution speed
25% reduction in test cycle time
20% faster time-to-market via CI/CD integration

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

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, 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
  • Playwright
  • Cypress
  • GitHub Actions
  • Sentry
  • Metabase
  • Testomat
← All case studies Discuss a similar challenge →