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
Frequently Asked Questions
What do testers most often overlook about their own organization?
Many quality engineers understand testing in depth but have no picture of how their employer actually earns money, who the key stakeholders are, or which decisions move the budget. Marta Firlej sees that gap widen exactly when it matters most: in a crisis, testers tend to ignore the financial side of their work, at the moment when the business side decides what survives.
How much does an employee really cost a company beyond the salary?
Roughly double the gross salary is a workable mental model. In Poland the employer pays about 30 percent on top of gross in additional taxes, multiplied across twelve months. On top come healthcare, training, conference tickets, office perks, onboarding setup, and bench time between projects. Add at least 40 percent more, since managers, non-billable colleagues and profit have to be earned by billable people.
Why do testers have to justify their budget while development spending goes unquestioned?
People learned long ago why they pay for development: they see lines of code and working features. Nobody ever taught them what quality costs or what the risk of skipping it looks like. That asymmetry means testers have to build the case themselves. Work that is not framed in business terms gets treated as an optional cost.
What can a tester do when management plans to cut the QA budget?
Turn the risk into numbers. A full regression that takes a week has a price. Round-the-clock support over the holidays, needed because nobody trusts the functionality, has a price. Skipped QA processes carry a number too. Testers rarely own these figures alone, so the job is to start the conversation with product owners and project managers, not to decide.
Is automating the full regression suite always worth the investment?
No. Automation pays off only when the thing under test survives long enough to earn back the build cost plus maintenance. For a proof of concept, a fast-changing product, or a feature built for a small user group, full regression automation rarely makes sense, because requirements change before the tests return value. Smoke tests and genuinely critical paths remain worth automating.
What is the most common mistake in an automation business case?
Teams calculate the build cost and skip the maintenance. Nobody names who keeps the tests running and how often, so automation looks cheaper on paper than it turns out to be. In financial services, some functionality stays in place for years and justifies the spend. Experimental features get cut, and every test built around them is deleted with them.
Does staying on the same project for years make a tester worse?
It carries a real risk. Engineers fall in love with the frameworks and automation they build and then resist letting them go, until criticism of the code feels like criticism of themselves. One automation engineer sat in on interviews for his own replacement, heard candidates explain what they would improve, and stopped after the third. They were right, and it still stung.
How can a tester start estimating their own business value?
Take a sheet of paper and your salary. Learn how your contract and employment work in your country, add the employer’s extra costs, multiply across twelve months, then add every benefit: healthcare, training, conference tickets, small office perks. Layer in branding, marketing and charity, then at least 40 percent for profit. After that, look at bench time, non-billable headcount and who the stakeholders are.
