Testing economics is the practice of framing software quality decisions in financial terms so testers, developers, and managers share a common language. It treats testing as insurance against costly failures, quantifies waste such as rework and customer churn, and turns quality arguments into numbers managers already use: man-hours lost, deals not won, and customers who leave because bugs go unfixed.
Key Takeaways
- Framing testing decisions in financial terms gives testers a concrete fallback: if a manager overrides a risk warning, the tester can request a written sign-off, which protects their job security.
- Reducing visible, repetitive waste first (such as features returned from testing to development because they were untestable) builds the credibility needed before proposing larger investments in quality.
- Testers have more direct exposure to real user behavior than product managers do, because regression and exploratory testing requires them to follow the full user journey from signup to cancellation.
- Customer support time spent routing user complaints into existing bug reports is a direct, measurable cost that can anchor a business case for better QA without requiring complex financial modeling.
Why testers and managers keep talking past each other
Testers and managers often speak the same language and still fail to understand each other. They can discuss the technical details. The disagreement shows up the moment a release decision is on the table: test more or test less, ship now or postpone.
Vitaly Sharovatov spent more than two decades in IT, as a contractor and as a permanent hire, and watched this gap open in company after company. Discussions about whether to release were biased or opinionated. A tester with strong standing in the company could simply say “I’m not releasing this.” A manager could just as easily force the release through.
The root cause is a missing shared frame. Managers are measured in economic terms, KPIs, OKRs, revenue. A product manager’s hypothesis is that shipping a feature now brings users, value, and money. When the tester says no, the manager starts to see the tester as a gatekeeper.
Vitaly has watched testers fight, quit, and get fired over these recurring misunderstandings. Forced releases can go the other way too, when managers ignore risks that testers and developers flagged. His conclusion: testers should at least learn to speak the language managers already use.
Treat testing as insurance, not as a cost
Good QA produces a strange paradox. When testing is done well, there are no incidents in production, or very few. You pay with effort and time for things that never happen.
That is exactly how insurance works, and every manager already understands it. With health insurance, you pay every month to cover the cost of an incident you hope never comes. Break a leg without insurance in the US, and the bill lands on you in full.
Investment follows the same logic: you pay now for a better outcome later. Testers cannot guarantee zero bugs or zero incidents. What they can do is build a model that reduces the harm, the impact, or the probability of something bad happening to users.
Framing the work this way changes the conversation. Instead of “trust me, we need more testing,” you describe the risk, the likely cost of a bad release, and let the manager decide. Put it in writing, and the decision is theirs to sign off. That protects the tester too. A risk the manager accepted in writing is not something the tester can be fired for later.
Where the numbers already live
The financial case for quality is sitting in other departments, waiting to be collected. Testers do not need to invent figures. They need to ask the right people for data that already exists.
Regulation is the cleanest starting point, especially in Europe. The first risk to name is simple: what happens if the company is shut down by government officials? In most cases, the money flow stops and the company stalls. Managers grasp this risk immediately because non-compliance can kill the business.
Marketing holds the next layer. Churn, the cost of acquiring a customer, and the reasons customers leave are all measurable. If the company lost a million dollars last year because customers stopped using the product, something could have been done better. Sometimes that something is a feature. Often it is UX, bugs, or support tickets that sat unanswered for months.
Sales can quantify the lost deals. If the team wins 30 percent of its deals, ask what stops it from winning 50 percent. Part of that 20 percent gap may come down to quality. Customer success can tell you how much time they spend processing requests that turn out to be bug reports, which is a direct cost in hours.
Your own tracking system carries the last piece. Pull the Jira stats and look at how often features bounce back from testing to development. If half of every hundred features get returned, you can calculate the time lost and the cost of redoing that work. Product managers care about this because they care about time to market, how fast an idea becomes a feature people can use.
Testers know the users better than almost anyone
Testers carry an analytical habit that fits this work. They are handed an object to examine, a feature, a pull request, and their job is to pick it apart. After enough time on a product, they often understand the users better than the product managers do.
Product managers can drift into a version of the product where every feature is loved and needed. Testers see the bug reports every day. They read direct feedback from real users, the same way customer success does.
Regression and exploratory testing force testers into the user’s shoes. They walk the full path: subscribing, purchasing, using, canceling. That makes them strong candidates to hold an overview of what is actually happening with the product.
Testers who only run test plans and tick off test cases tend to burn out. Clicking through the same checks without any view of the bigger picture turns the job into a soulless routine. People want to be proud of their work, and pride needs a connection to the outcome.
Start with waste you can already see
If your schedule is full and no one is listening, do not begin with the idealistic version. The clean approach, inviting marketing, sales, and managers into a room to quantify their fears and align on how much testing reduces those risks, works in some companies. In many, the manager will just tell you to go back to testing.
So take small steps. Begin by analyzing your own work for repetitive, wasteful effort. This almost always pays off.
When a developer keeps handing you features that are not testable or do not work, pair with that developer. Ask how you can help them build it right. Developers dislike having features bounced back, so it is in both your interests to align on how they work. Do this with two or three developers and the repeated rounds of testing and rework start to shrink.
Then gather the numbers. You do not need time to market or cost of delay for this first move. Plain man-hours are enough. Show your QA lead how many hours you and your colleagues saved, prove the figures hold, and ask to scale the effort.
“Start with the direct costs which are 100% waste, which you know are waste, which you feel are waste.” Vitaly Sharovatov
Earn credibility before you propose the risky changes
Sequence matters. Reducing obvious waste builds the authority you need before suggesting anything that looks risky to a manager.
Walk into a manager’s office and propose replacing individual work with mobbing, and the answer is predictable: “I’m not paying seven times for one feature.” Arguments about cost of delay or time to market will not land, because the manager hears a threat to the process they know and trust.
The order that works looks like this:
| Step | What you do | What you use as proof |
|---|---|---|
| 1 | Cut direct waste with one or two developers | Man-hours saved |
| 2 | Scale the effort across the team | Verified statistics, QA lead support |
| 3 | Optimize flow (queuing theory, Kanban) | Reduced time to market |
| 4 | Propose higher-cost measures like pairing or mobbing | Credibility already earned |
| 5 | Bring in other departments’ costs | Support hours, churn figures |
By the time you reach the riskier proposals, you have a track record of saving money. Only after you have proven you can save money can you credibly ask to invest money in quality.
Win-win beats authority every time
Forcing change through authority rarely improves anything, because people are attached to the work they have invested in. A developer who spent two months on a feature will not take kindly to a tester returning it with twenty defects listed in a bullet point.
That sunk-cost reflex is real and experienced developers know it. The chance a two-month feature passes testing on the first try is close to nothing, which is why seasoned developers hand work to testing far more often and in smaller pieces.
Bringing the feature back works, but sitting with the developer afterward to find a win-win works better. When the outcome satisfies both sides, your initiatives gain allies who will back you in front of management.
The same principle reaches upward. Managers report results as numbers to the people above them. Help a manager report better numbers and you become more valuable to that manager. They will say they saved the project and that you helped, and that is fine, because they know you helped.
Economics does not mean turning everything into a spreadsheet
A common objection is that thinking in economic terms reduces everything to numbers. It does not. Qualitative judgment stays in the picture; the numbers give it weight.
Every company’s situation is its own. You cannot adopt an approach because Amazon uses it, the same way a seasoned developer questions a rewrite from Angular to React by asking where the economic justification is. Testing sees the same impulse, swapping one framework for another, and it deserves the same question.
Thinking economically also means thinking about people. Does a colleague know the new framework, or will the switch require onboarding and training? Those costs belong in the calculation.
Even bad UX connects to a number. It cannot be measured to the last decimal, but marketers will tell you that bad UX drives higher churn. If you judge a feature’s UX as poor and you have a working relationship with marketing, you can borrow their expertise. Hand the manager a clear statement: this UX will likely increase churn, talk to marketing before you sign it off.
