Your client found a bug before your tester — what went wrong

A scenario every software house knows: the client calls or emails. "After clicking the invoice link I get a white screen." The team checks — sure enough, there's a bug. The PM asks QA: "Why didn't we catch this?" The tester answers: "I didn't test that scenario" or "I saw something similar but didn't have time to report it." And the blame game begins. But the guilty party isn't a person — it's the process.

How bugs get past QA to production

Capers Jones in "Applied Software Measurement" (2008) estimates that even the best QA teams achieve a defect detection effectiveness (DDE) of around 85%. That means 15% of defects pass through the testing process uncaught — even in mature organizations. In smaller shops where one tester handles multiple projects, that rate is lower.

But there's a category of bugs that doesn't get past QA because the tester missed them. They get past because the tester saw them but didn't report them. The reason is always the same: time pressure + reporting barrier. Writing a formal report takes 10-15 minutes. When you have 3 modules to test before Friday's demo — the priority is testing, not documenting.

The cost of a client-found bug

A bug found by the client costs many times more than the same bug caught during testing. NIST (National Institute of Standards and Technology) in its report "The Economic Impacts of Inadequate Infrastructure for Software Testing" (2002) showed that the cost of fixing a defect grows up to 30x when it moves from development to production.

But money is only part of the cost. There are consequences that don't show up on any invoice:

Why time pressure kills test coverage

The World Quality Report 2023-24 (Capgemini, Sogeti, Micro Focus) shows that 52% of respondents consider lack of time for proper testing the main QA challenge. This isn't a budget problem — it's a process efficiency problem.

A tester under pressure has to choose: test more scenarios or report more thoroughly. Every minute spent writing a report is a minute less for testing. At 10-15 minutes per report and 4-6 bugs per day, reporting alone eats up 1-1.5 hours — time that could be spent on exploratory testing of additional scenarios.

The outcome is predictable: the tester tests less or reports less. In both cases, bugs escape to production. The difference is that when the tester tests less — the problem shows up in coverage metrics. When they report less — the problem is invisible, because nobody measures bugs that weren't reported.

What this means for your software house

The client will find a bug in production. That's a certainty — no QA team has 100% detection rate. The question is: how many of the bugs the client finds could have been caught earlier if the reporting barrier were lower?

The solution isn't hiring another tester or extending the QA phase. The solution is reducing the time a tester needs to file a report — because then they'll report more of their findings instead of postponing them "for later."

Voice2Bug cuts reporting time from 10-15 minutes to under a minute. The tester clicks the browser extension icon, describes the problem by voice, takes a screenshot. The report lands in Jira automatically — with technical data, screenshot, and reproduction steps. The result: testers report all the bugs they find, not just the ones they "had time for." Fewer bugs escape to production. The client calls less often.