The business value of software testing refers to what testing actually costs and earns for a company, calculated in concrete numbers rather than abstract quality arguments. Testers who understand how their organization makes money can translate risks into financial terms: regression time, support costs, and release failures all convert directly to money. That calculation is what makes testing visible to decision-makers.
Key Takeaways
- Testers who cannot explain what a failed release costs in money will lose budget arguments, because managers treat testing as an abstract cost, not a risk mitigation tool.
- Automation return on investment depends on maintenance costs and longevity: automating a product that may be cut or heavily revised in the near term produces negative value.
- The real cost of an employee to a company is roughly double the gross salary, once employer taxes, benefits, bench time, and overhead are included.
- Testers own the responsibility to produce quality reports and communicate risk proactively, because clients will not ask for information they do not know they need.
- Understanding how a company earns money, who the key stakeholders are, and what decisions they make is a precondition for translating test results into business value.
Why testers should understand how their company makes money
Testers who grasp the business behind their work make better decisions, especially when budgets tighten. Marta Firlej argues that many quality engineers understand testing deeply but have no picture of how their organization earns money, who the stakeholders are, or which decisions move the budget.
That gap shows up most clearly in a crisis. When money gets tight, testers tend to ignore the financial side of their work, even though that is the moment when the business side matters most.
Companies exist to make money. Marta points out that this simple fact surprises a lot of people in the room when she states it plainly. Every company, every government, every country operates to make money, and testing sits inside that reality whether testers acknowledge it or not.
The real cost of an employee is higher than the salary
The cost of a person to a company is far larger than the salary they take home, and most testers underestimate it. Marta walks through the math by starting with the gross salary, then layering on what employers actually carry.
In Poland, the employer pays roughly 30 percent on top of the gross salary in additional taxes. Take that figure across twelve months, and you have a baseline investment in one person. Then, as a rough mental model, double it to cover everything else the company funds.
That “everything else” includes the benefits people rarely connect to a price tag: healthcare, learning and development, conference tickets, even the fruit in the office on Thursdays. None of it is free, and buying it individually would cost more than the company pays at scale.
Onboarding is part of the bill too. A new hire carries setup costs before they bill a single hour, and someone sitting on the bench between projects is still an investment the company absorbs.
There are also people whose salaries everyone else has to cover. Marta puts it directly: a manager’s pay, the pay of colleagues on the bench, the budget for training and the team party all have to be earned by the billable people. Add at least 40 percent on top of the visible costs, because the company is there to make a profit.
What value does testing bring to the stakeholder?
Testing brings business value when it tells stakeholders how much money they stand to lose, not just how good the quality is. Marta draws a sharp line between the information testers naturally produce and the framing a stakeholder actually pays attention to.
Saying “here is information about the quality” stays inside the tester’s world. Translating that into “here is how much money you lose if you release now” speaks the language of the business. Good product managers can run that calculation, and testers should help them get there.
The mechanics of selling testing differ from selling development. People learned long ago why they pay for development: they see lines of code and working features. Nobody taught them what quality costs or what the risk of skipping it looks like, so testers have to make that case themselves.
If a tester does not frame their work in terms the stakeholder needs, the effort goes unappreciated. Marta’s point is blunt: promote the work in business terms, or watch it be treated as an optional cost.
Why testing is the first thing cut in a crisis
Testing gets cut first because it reads as an abstract cost against a future risk rather than a visible deliverable. For many managers, testing is hard to picture, so it looks like an easy line to trim.
Marta has lived through this pattern repeatedly. Across about 20 years in the Polish testing market, she has seen four crises in which clients moved work from Poland to India on cost grounds, and four times testers had to prove their value with the same argument.
The counter to that is making the risk concrete in money. A full regression that takes a week can be written down as a cost. Round-the-clock support over the holidays, needed because nobody is confident in the functionality, can be priced. Skipped QA processes carry a number too.
Testers usually do not own these figures alone. Product owners, project managers, and engineering managers sit closer to the budget and understand it better. The tester’s job is to start the conversation, share the risk in numbers, and educate the rest of the team, even if someone else makes the final call.
Test automation is not always worth the money
Automation pays off only when the thing being tested will stick around long enough to earn back the investment plus its maintenance. Marta describes herself as deliberately lazy with her time: she invests it only where it returns real value.
The decision hinges on stability. For a proof of concept, a fast-changing product, or something built for a small group of users, full regression automation rarely makes sense, because the product or its requirements will likely change before the tests pay off. Basic smoke tests and the genuinely critical paths are worth automating. The rest can wait.
She contrasts two ends of her own work. In financial services, some functionality stays in place for years and justifies the investment. Other features are experiments: if users do not like them, the feature gets cut, and every test built around it gets deleted with it.
A common planning mistake makes automation look cheaper than it is. People build an automation strategy and calculate the build cost, then skip the maintenance: who keeps the tests running, and how often. Marta frames the whole decision around return on investment, and notes that it is often not worth it.
Switching projects keeps your judgment sharp
Moving between projects and companies makes you a better tester and breaks the emotional attachment to your own work. Marta sees real risk in staying too long with one codebase or one framework.
Engineers fall in love with the frameworks and automation they build, and then resist letting them go. The longer you stay, the more it feels like the work is your child, and criticism of it lands as criticism of you.
She tells the story of a test automation engineer who agreed to sit in on interviews for his own replacement. Each candidate reviewed one of his test cases and explained what they would do better. By the third interview he asked to stop. The candidates were right, he had made those mistakes and could have built it cheaper and easier to maintain, but hearing it felt like someone attacking his child.
The lesson is to treat changing context as a way to learn, not as destruction. Every new project and company adds something, and the distance keeps your judgment honest.
A practical way to start
You can begin understanding your own value with a piece of paper and your own salary. Marta lays out a sequence any tester can run alone.
- Start with your salary, and learn how your contract and employment work in your country.
- Add the employer’s extra costs. In Poland that is around 30 percent on top of gross.
- Multiply across twelve months to get the yearly investment in you.
- Add every benefit: healthcare, training, conference tickets, the small perks at the office.
- Layer in the company’s other activities: branding, marketing, investments, charity.
- Add at least 40 percent on top, because the company exists to make money.
From there, look at how your organization runs as a business. Does it carry people on the bench? How many non-billable people work there? Who are the main stakeholders, what is the company’s past, and where is it heading?
Money is a hard topic to raise, and Marta is candid that in Poland people are not raised to talk about it, which makes it close to taboo. Her encouragement is simple.
Don’t be afraid, you’re not alone. We are all in it as long as we have jobs. Marta Firlej
