Insights · 13 min read
A realistic look at what software testing costs, what drives the price, and how to budget QA so it catches bugs before your customers do.
By GGP Editorial
Testing is the line item that keeps surprising founders. You plan the design, the development, the launch date. Then someone asks how much testing costs, and the answer comes back as "it depends," which is true and also useless when you are trying to set a budget.
I write this from the vendor side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects, serving clients across Brazil, South Africa, Singapore and the US. We build custom software, mobile apps and SaaS platforms, and we run QA on everything we ship. This guide explains what testing actually costs, why the number moves around so much, and how to budget for it without overpaying or cutting the thing that protects your launch.
It is written for the founder, CTO or product owner who has to put a number next to "testing" in a budget. Not for QA engineers debating automation frameworks.
A developer's estimate is usually predictable because the scope is visible. You can count the screens, the integrations, the features. Testing is different. Its cost is driven by risk, and risk is the part of the project nobody wrote down.
Three things move the testing number more than anything else.
The first is what the software does. A content site has a small testing surface. An app that moves money, stores health records or handles identity has a large one, because the cost of a bug is not a lost session, it is a fraud case, a compliance breach or a person's data on the wrong screen. FinTech and regulated products need their own layer of security and compliance testing. Our guide to security requirements for FinTech platforms walks through what that layer involves.
The second is how much already exists. Testing a fresh MVP is a different job from testing a three-year-old codebase with 200 screens and a dozen integrations. Every release of a mature product means regression testing across everything that already works, and that surface grows every sprint.
The third is what "done" means. If done means "it works on my machine and the happy path passes," testing is cheap. If done means "it holds up under load, passes a security review, and works on the device and browser set your customers actually use," the cost is a real line item, not a rounding error.
That is why a serious vendor will not quote testing before it sees the scope, the risk profile and the state of the code.
"Testing" is not one activity. It is a set of them, and they cost different amounts and find different bugs.
| Type of testing | What it checks | Relative cost |
|---|---|---|
| Functional / manual | Does each feature do what it was meant to do | Moderate, repeats every release |
| Automated regression | Do the old features still work after a change | Higher to set up, cheaper to repeat |
| Performance / load | Does it stay fast and stable under real traffic | High, usually run before launch or major releases |
| Security / penetration | Can someone break in, leak data or abuse the system | High, often run by a specialist |
| Compatibility | Does it work across the browsers, devices and OS versions your users have | Moderate, scales with the matrix you commit to |
| Usability / acceptance | Can a real user complete the core tasks without help | Low to moderate, easy to skip and easy to regret |
The pattern worth noticing: functional and regression testing recur every release, while performance and security testing are point-in-time events. Your budget needs both kinds, and they are priced differently.
In practice you will see testing priced one of three ways, and it helps to know which one you are looking at.
A dedicated QA engineer or team, billed like developers. This is the most common model in custom software work. QA sits inside the delivery team, tests each sprint as it is built, and the cost rolls into the same monthly or time-and-materials rate as the developers. It is the cleanest model because testing happens as you go instead of at the end.
A percentage of the project budget. Many firms set aside a share of the total build for QA. As a planning range we tell clients to hold roughly 20 to 40 percent of the total project cost for testing, depending on risk. A low-risk MVP sits at the bottom of that range, a payment or healthcare product at the top. The exact number depends on scope and risk, not on a formula.
A fixed per-release or per-cycle price. This shows up when you hire a testing specialist to validate a specific release or to run a security review. It is a clean number for a defined job, but it does not replace the continuous QA that belongs inside the build.
If you are weighing pricing models more broadly, our guide to fixed price vs time and materials explains where each one fits.
Put a number on the table, then adjust it. For a typical custom software build, holding 20 to 40 percent of the budget for testing is a sensible default. That is not a premium on top of development. It is the share of the total you should expect testing to consume once you include test case writing, automation, regression and the pre-launch security and performance pass.
A few things push you toward the higher end. Money and identity in the product. Regulated industries. A large existing codebase. A launch where a bad day one is unrecoverable. A few things pull you toward the lower end. A simple internal tool. A small user base. A product where the worst case of a bug is an inconvenience rather than a loss.
The cheaper-looking option is not always cheaper. Skipping testing and shipping a buggy product usually means paying for it twice: once to fix the bug after launch, when it is more expensive and more visible, and once in the customers and reputation you lose in the meantime. Our guide to reducing custom software development costs makes the same point from the other side: cut scope and uncertainty, not quality.
Testing budgets surprise people because the work is invisible from the outside. Here is what the money buys.
Test planning and test cases. Someone has to decide what "correct" means for every feature and write it down so it can be checked consistently. This is real work and it is the part people skip first.
Automation scripts. Writing a regression suite that runs on every release is an upfront investment that pays off over many releases. It does not pay off on a product that changes weekly and will be thrown away.
Environments and test data. You need a stable place to test and data that looks like real data without being real customer data. Both take setup and maintenance.
Regression execution. Every release re-runs the tests that prove nothing broke. The cost of this step is proportional to how much product already exists.
Defect triage and reporting. A bug is not fixed when it is found. It is fixed when it is documented, prioritized, assigned, fixed and verified. That loop has cost, and sloppy reporting makes it more expensive.
Device and browser coverage. Mobile and web products have to work across a real matrix of devices, operating systems and browsers. You either buy that coverage or you accept that some customers will be your testers.
Security and performance testing. These are specialist passes, often bought separately, and they matter most the closer you get to launch.
This decision drives more of the testing budget than anything else, and the answer is usually both.
Manual testing is for the new and the uncertain. Exploratory testing of a new feature, checking that the UI actually reads well, finding the bug nobody predicted.
Automated testing is for the stable and the repeated. Once a feature is settled, you write a script so every future release checks it without a person clicking through by hand. Automation costs more to build but close to nothing to run, so it pays off on the third or fourth time you would have tested the same thing manually.
The mistake we see most often is automating too early. A startup pays to automate a feature that gets redesigned three times before launch, and the scripts get thrown away with it. The rule that survives: automate the parts that have stopped changing, not the parts you are still figuring out.
For a founder deciding how much product to build in the first place, how much MVP development costs explains where testing fits into an MVP budget.
There are three realistic ways to staff testing, and they answer different situations.
QA inside the development team. Testing happens as features are built, the tester knows the product deeply, and there is no handoff. This is the default for custom software and it is what we recommend. The cost is part of the team.
A separate QA vendor for a specific pass. For a security review, a load test or a one-off validation before launch, a specialist brings tools and objectivity the build team does not have. You pay a fixed price for a defined job.
A dedicated offshore QA team. When you need continuous testing at a lower rate than local engineers, an offshore team works. The economics mirror offshore development: the same test discipline at a fraction of the cost, with the trade-off of working across time zones and needing good communication. Our guide to choosing an offshore development partner covers the vetting questions, and how a dedicated development team works explains the engagement model.
For most founders the answer is not one of these but a mix: QA inside the team for the day-to-day, and a specialist bought in for the pre-launch security and performance pass.
The single most expensive way to do testing is to bolt it on at the end. Bugs found in the final week are fixed in a panic by people who have already moved on to the next project, and every fix risks breaking something else that nobody has time to re-test.
The cheaper version is to move testing into the build. A QA engineer works in the same sprint as the developers, writes acceptance criteria before a feature is built, and tests it the day it is finished. A bug found in that sprint is cheap to fix because the developer is still in the code. The same bug found a month later costs far more, and found by a customer after launch it costs more than money.
This is one reason the overall project timeline matters. Testing is not a phase you append; it is a thread that runs through the whole build. Our guide to how long custom software development takes shows where QA fits into the sequence, and how to estimate a custom software project shows how to turn scope into a number that includes it.
Reducing what you spend on testing is a real skill. It is not done by skipping tests. It is done by testing the right things.
Prioritize by risk. The money path, the login, the places where data is created or deleted. Those get the deep coverage. The low-traffic settings screen does not need the same treatment.
Automate only the regression suite. Write scripts for the stable core, keep manual testing for the new and uncertain parts. That is where automation actually returns its cost.
Keep QA inside the sprint. The shortest distance between a bug and its fix is a tester and a developer in the same room, virtual or otherwise. Handoffs and re-explanations are where testing budgets leak.
Reuse test data and environments. Building test data and keeping environments stable is a quiet cost. Standardize it once instead of rebuilding it every release.
Buy device and security coverage instead of owning it. Maintaining your own device lab or building a security practice in-house is rarely worth it for one product. Rent the coverage for the passes you need.
Do not test what you are about to throw away. A prototype or a feature you already know will change does not need a full regression suite. Spend that effort on the parts that will survive to launch.
What percentage of a software project budget should go to testing?
A sensible planning default is 20 to 40 percent of the total build, depending on risk. Low-risk MVPs and internal tools sit at the bottom. Products that move money, store personal data or operate in regulated industries sit at the top.
Is manual testing cheaper than automated testing?
Per pass, manual testing is cheaper to start and more expensive to repeat. Automation costs more up front and close to nothing to run. The right answer is manual for the new and changing, automated for the stable regression core.
Can I skip testing on an MVP?
You can skip the heavy layers, not the basics. An MVP needs functional testing on the core path, because the whole point is to learn from real users and a broken first impression poisons that data. Skip the automation and the load testing until you know the product is staying.
Should QA be a separate team or part of the development team?
For custom software, QA works best inside the delivery team, testing each sprint as it is built. A separate team makes sense for specialist passes like security or performance testing, where outside objectivity and tools add value.
How much does it cost to outsource QA offshore?
Offshore QA follows the same economics as offshore development: the same test discipline at a lower rate than a local engineer, traded against time zones and communication. The precise rate depends on region and seniority, and it is worth reading our breakdown of software development cost in China to understand the range.
---
Testing is the cheapest insurance a software project has, and the most painful one to skip. If you are planning a build and want a QA budget that matches the real risk in your product, tell us what you are building and where the danger sits. We can put a testing scope and a realistic number against it before you commit.
Tell us what you are building and where you are today. We typically reply within 24 hours.
