Every client eventually asks some version of this: "Is it tested?" The expected answer is yes. The more honest answer involves a lot more nuance — because testing is one of those disciplines where you only notice the investment when it's missing.
Here's what testing and QA actually mean in a custom software project, what they cost, and why the common shortcut of "we'll test at the end" is the single most reliable way to make a project painful.
What testing actually covers
Testing isn't one activity. It's a stack of different practices, each catching a different class of problem:
- Unit tests — Small, automated checks that individual functions work as expected. Fast to run, cheap to write alongside the code, and the first line of defense against regressions. If a change in one place breaks something else, unit tests catch it before the code ships.
- Integration tests — Check that different parts of the system work together. An API that returns the right data internally can still send the wrong format to an external system.
- End-to-end tests — Simulate a real user completing a real workflow: log in, create an order, confirm it was invoiced. Slow to run, expensive to maintain, but the closest thing to catching what a user would actually notice.
- Manual testing — A human using the software to verify it works as expected. Essential for catching UI problems, confusing flows, and edge cases that automated tests don't model well.
- Regression testing — Running the full test suite after every change to make sure nothing that used to work has broken. With automation, this happens on every commit. Without it, it happens manually before each release — and often gets skipped when time is short.
The real cost of bugs in production
Research from IBM and others has put numbers on this for decades: a bug found during development costs roughly 1x to fix. The same bug found during integration testing costs 5x. Found in production: 10–15x — and that's before counting the support tickets, the lost data, the awkward conversation with a client, or the reputational damage if it was a customer-facing system.
A concrete example from my own practice: a data export function had a rounding error in a currency calculation. My test suite caught it two days before launch — two hours to fix. If it had shipped, every invoice for that client would have been wrong, and unpicking months of bad records would have cost far more than the entire test suite combined.
Why "we'll test at the end" fails
Deferring testing until the build is "done" is one of the costliest patterns in software development — and one of the reasons projects fail on their last mile. By the time end-of-project testing starts, two months of unchecked assumptions have accumulated. The bug you find on day one of testing may trace back to a design decision made in week three — and now you're undoing work that has three sprints of other code built on top of it.
Testing woven into every sprint is structurally different. Bugs surface while the relevant code is still fresh, the fix is local instead of systemic, and the test you write becomes permanent protection against the same bug returning.
This is the same underlying logic as technical debt: each deferred quality decision compounds into a larger problem later. The shortcut that saves a day in week four costs a week in week twelve.
What good testing looks like in a project
On a well-run project, testing isn't a separate phase — it's woven in from the start:
- Unit and integration tests are written alongside the feature code, not in a sprint dedicated to "testing" at the end
- A CI pipeline runs the full suite on every commit, so problems surface immediately instead of at the next demo
- A staging environment that mirrors production is ready from week two, so client review happens against real-world conditions — not a sanitised demo setup
- Manual testing happens on each sprint delivery, because a second pair of eyes on completed features catches what automated checks miss
What test coverage costs
A reasonable test suite for a mid-sized business application — enough to catch regressions and validate critical paths — typically adds 15–25% to the build time. On a €40,000 project, that's €6,000–€10,000 in testing effort. It's not a bonus line item; it's the cost of owning software that can be changed without fear.
Skipping it saves that €6,000–€10,000 upfront and tends to cost €15,000–€40,000 over the following two years in bug fixes, support time, and eventually a refactor to make the untested code modifiable again. I've seen this calculation play out often enough that I treat the testing budget as non-negotiable in every project scope.
Automated tests also directly reduce the cost of ongoing maintenance: every feature you add to a tested codebase takes less time to verify, because the suite does the regression checking automatically. The investment compounds in the right direction.
What to ask your developer about testing
You don't need to evaluate this as a technical expert. These questions are enough:
- Will there be automated tests, and do they run on every commit?
- Is there a staging environment for me to test against before go-live?
- How do we know a bug fix didn't break something else?
- What does the test coverage look like at handover?
Answers that amount to "we'll test at the end" or "the client tests it before launch" are not reassuring — they're a description of manual regression testing on a tight deadline, which is where the most expensive surprises live. It's one of those red flags worth including when you're evaluating a quote.
Planning a project?
Testing is part of the scope conversation from the first call, not a discussion you want to be having in the final sprint. If you're evaluating proposals or about to commission software, I'm happy to review what's included — and tell you honestly what's missing. Get in touch.