Testing and Quality in Software: Making "Done" Mean "It Works"
"It's done" and "it works" are different sentences: the demo goes perfectly and real life breaks it — the empty field, the double click, the shop's slow connection, two people saving at once. You don't need to be a QA engineer to demand reliable software: you need to know which testing levels exist, which one is yours, and how to report what you find.
November 5, 20255 min readIn this article
"It's done" and "it works" are different sentences, and the difference always gets discovered at the worst moment: the demo went perfectly, but on the first real day someone left a field empty, someone else double-clicked "save", the shop's connection was slow and two people edited the same order at once — and the system that "was done" handed out errors all morning.
Software quality isn't perfection — it's confidence earned through testing: the reasonable certainty that the system withstands real life and not just the demo. And although the technical tests are the developer's job, there's one level nobody can do for you, and questions you're entitled to ask. This guide gives you the full map in plain words.
Why "done" software fails
The developer naturally tests the happy path: the flow where everything is filled correctly, in order, on a good connection, one user at a time. Real life is the permanent unhappy path — incomplete data, impatient users, slow networks, simultaneous use — and every untested combination is an error waiting for its premiere in production, in front of a customer. Testing exists to premiere those errors in private, when fixing them is cheap, instead of in public, when they cost sales and reputation.
The testing levels, in plain words
| Level | What it verifies | Who does it |
|---|---|---|
| Automated tests | That each piece of code does its job — and keeps doing it after every change | The developer; you only confirm they exist |
| Functional tests | That every story in the requirements works end to end | The development team, against your requirements document |
| Acceptance testing | That the system serves YOUR real operation, with your people and your data | You and your team — nobody can do it for you |
| Load tests | That it withstands the expected volume (simultaneous users and data) | The developer — relevant if you expect peaks or high volume |
Your role: the acceptance test
The cases everyone forgets
- The bad connection: what happens with slow internet, or a cut mid-save? — a clear message and no lost data separate the professional from the fragile.
- The data extremes: the list with zero items and the list with ten thousand; the two-letter name and the eighty-letter one — extremes break what averages forgive.
- Simultaneity: two people editing the same thing at once — who wins, who finds out? In team systems, this happens on day one.
- The real device: your warehouse keeper's old phone and the kitchen's cheap tablet — software is tested on the devices where it will live, not just the developer's laptop.
Bugs: how to report them so they get fixed fast
- The exact steps: what you did, in order, from where — "I opened orders, searched 'García', opened the second result, tapped edit".
- Expected vs happened: "I expected the customer file; a blank screen appeared" — both halves, always.
- The evidence: a screenshot or short video, plus device and time — half of all "non-reproducible" bugs get solved with one good capture.
- Honest severity: distinguish "blocks operations" from "annoying" from "detail" — the provider who receives everything as urgent ends up prioritising nothing.
Quality after the launch
Launching doesn't end the topic — it changes its phase. Demand three things for life in production: error logging (the system records its own failures, so the provider fixes causes instead of guessing at symptoms), an agreed support channel and response times (what counts as urgent, who answers, how fast) and a budgeted stabilisation period — the first real weeks always reveal adjustments, and knowing that upfront keeps them from feeling like failure; the project's full timelines are in how long app development takes and the general framework in the app creation guide.
Frequently asked questions
How much of the budget should go to testing?
In serious projects, testing consumes between a quarter and a third of the total effort — split between the automated tests the developer writes and the functional rounds. If a quote doesn't mention testing at all, it isn't cheaper: it's the same testing, paid for by your customers in production. The right question when quoting isn't "how much does testing cost?" but "what does your quality process include?" — and distrust the silence.
Shouldn't the developer just deliver without bugs?
Software with zero bugs doesn't exist — what does exist and is demandable is the difference between reasonable bugs and careless work: the requirements' main flows must work completely (non-negotiable), edge cases may have documented pending adjustments, and bugs appearing under warranty get fixed at no cost. That word — warranty — deserves to be in your contract: a period (60-90 days is common) where defects in what was delivered are fixed free.
What are automated tests and should I pay for them?
They're code that tests the code: checks that run by themselves in seconds, every time something changes. Their value isn't at launch but across the entire life afterwards: without them, every future change can silently break what already worked, and nobody notices until the customer does. You don't pay for them as an extra — they come inside work done well; what you should do is ask whether they exist, because their absence turns every future maintenance into a gamble.
When is it ready to launch? Something new always shows up.
With criteria defined beforehand, not feelings at the end: all the requirements document's stories work, the realistic pass with your team ran for days without blockers, this guide's forgotten cases were tested, and the open bugs are only of the "annoying or detail" category — with a fix date. Waiting for absolute zero defects means never launching; launching with a known blocker means torching the team's trust. The healthy line sits exactly between the two.