Q15 of 32 · Behavioural
Tell me about a time you advocated for testing investment when leadership wanted to ship faster.
Short answer
Short answer: Lead with data: bug-escape rates, customer impact, dev hours lost to flake. Frame the investment in terms of speed, not against it — 'this gets us faster, sustainably.' Show you gave leadership a clear ask and a measurable success criterion.
Detail
Advocating for testing investment fails when it's framed as "we need to slow down for quality." It works when framed as "this is how we go faster sustainably."
STAR walkthrough — sample answer:
Situation: A previous team had been pushing release cadence from biweekly to weekly. Velocity was up, but bug-escape rate to production had crept from ~2 per release to ~7 per release over a quarter. Leadership wanted to keep pushing — the next quarter target was every 3 days.
Task: As QA lead I was watching the trajectory and could see we were heading for an incident-driven slowdown rather than a sustainable speedup. I needed to make the case for investment in the test infrastructure before something broke badly enough to force the conversation.
Action: I spent half a sprint preparing data, not opinions:
- Pulled six months of escape rate vs release cadence — showed the correlation clearly.
- Estimated time spent on production firefighting (engineering time logs from the bug tracker): about 18% of dev time was reactive, up from 8% the previous quarter.
- Modelled the trajectory: at the current rate, a 3-day cadence would push reactive time over 30%, eroding the velocity gains entirely.
- Costed a specific intervention: 3 weeks of dedicated engineering time on the most-flaky areas of the test suite + adoption of a smoke check before merge. Estimated reduction: bring escape rate back below 3, reactive time back below 10%.
I took it to the engineering director not as "we need to invest in QA" but as "here's the data on why our velocity is degrading and how to fix it." Framed in their language (velocity, reactive time) not mine (test coverage).
The director pushed back initially: "we don't have 3 weeks." I'd anticipated this and had a phased option: 1 week of focused work on the worst flakes immediately, defer the rest to start of next quarter. They agreed to the phased plan.
Result: After the first week, escape rate dropped from 7 to 4 per release. The next quarter included the second phase as planned, and we reached the 3-day cadence with escape rate at 2. The director referenced the phased approach in subsequent decisions about technical investment.
What I learned: leadership doesn't reject testing investment because they don't value quality — they reject it when it's framed as a cost rather than a speed enabler. The framing changes the conversation entirely.
Why this works: data-driven case (numbers from real metrics), framed in business language, anticipated the pushback with a phased option, and the outcome legitimised future investments.