What Automated Testing Is: The Types Explained in Plain English, and How to Check It at Acceptance
When “testing” appears as a line on a quote, the first thought many clients have is whether it can be cut. The features are built and they work when you click them, so why spend more time?
The problem is that “it works when I click it today” and “it still works three months from now after we add something new” are completely different propositions. Testing does not buy correctness today. It buys safety for every change after today.
This guide explains, in terms a non-engineer can use, what testing actually does, what is worth automating, and how to confirm it at acceptance.
Start with an analogy
Think of software as the wiring and plumbing in a house.
Unit tests are checking each switch and each outlet individually to see whether it carries current. The scope is smallest and they run fastest, so when something breaks you know immediately which component it was.
Integration tests check what happens when several parts are connected: the switch wired to the light, the meter wired to the circuit. Plenty of problems are not a single broken component but unexpected behavior once things are joined together.
End-to-end tests (often abbreviated E2E) simulate a real person walking the whole route: come through the door, turn on the light, take a shower, confirm the water is hot. They check the complete flow and come closest to real use, but they are also the slowest and the most prone to false alarms triggered by unrelated small changes.
| Type | What it checks | Speed | Difficulty of locating the fault |
|---|---|---|---|
| Unit test | The logic of a single piece of functionality | Fastest | Easiest, points straight at the logic |
| Integration test | How several parts behave once connected | Moderate | Moderate |
| End-to-end test | A complete user flow | Slowest | Harder, requires tracing down |
The three do not replace one another; each covers a different level. A healthy project usually has the most unit tests, with end-to-end tests covering only the few most critical flows — E2E is expensive to maintain, and a suite written entirely in E2E takes so long to run that eventually nobody runs it.
What automation actually saves
Manual testing is not the wrong approach. When a feature is built for the first time, somebody should click through it. Automation solves a different problem: repetition.
Once a system is live, every change can affect something that looks unrelated. You adjust how membership tiers are calculated and discounts come out wrong; you change order statuses and the report figures stop reconciling. This category of “new thing breaks old thing” is called regression, and it is the most common and most trust-damaging problem of the maintenance period.
Without automated tests, there are only two ways to guard against regression: have someone retest all the old functionality at every release, or skip the check and wait for customers to report it. The first is labor paid over and over, by people who get tired and miss things. The second transfers the cost to production incidents and complaints.
The point of automated testing is to turn that repeated checking into something that can be run at any time, in volume, at low cost. It also has an often-overlooked side effect: testing forces developers to write logic that can be verified, which usually means a clearer structure that is easier to maintain, and that is directly connected to how fast technical debt accumulates.
What to automate, and what to skip
Not everything deserves a test. Two questions make the call: how expensive is an error here, and will the check need repeating?
Automate first:
- Anything involving money. Pricing, discounts, revenue sharing, refunds, balance adjustments. Errors here turn directly into financial loss or a crisis of trust.
- Permission checks. Who can see what, and who can change what. A permissions failure is a security incident, not a cosmetic flaw.
- Core transaction flows. Ordering, payment, booking, submission for approval — guard these main paths with a small number of end-to-end tests.
- Complex, rule-heavy calculations. Shipping tiers, tax handling, state transition rules. Manual testing misses edge cases in these very easily.
- Bugs you have already fixed. Add a test each time you fix something so it cannot come back. This is the highest-return category of all.
Skip it, or leave it for later:
- Pure visual presentation. Colors, spacing, and type sizes are judged by eye, and automating that judgment returns little.
- One-off or soon-to-be-retired features. Campaign pages and short-lived projects will not live long enough to repay the effort.
- The behavior of external services themselves. What you need to test is whether your own integration is correct, not another company’s system on their behalf.
- Early features still changing frequently. While requirements shift weekly, the tests get rewritten alongside them; it is reasonable to wait until things settle.
Developer testing versus client acceptance
These two get conflated constantly, which is how expectations diverge at acceptance.
Developer testing answers the question: does the program behave according to the rules that were written down? The development team runs it, it is mostly automated, and it runs after every change.
Client acceptance answers a different question: does this system meet my business needs? It has to be done by someone who genuinely understands the business, because only you know that “this discount scenario does not actually exist at our company” or “the sales team will never fill in that field.”
In other words, an all-green test suite does not mean acceptance can be signed off; the two verify different things. For how to design acceptance criteria, grade defects, and tie them to payment milestones, see How Software Acceptance Works. And the origin of those acceptance criteria is how specific the original requirements document was.
How to confirm at acceptance that the work was done
You can get to the truth without reading code. It comes down to how you ask.
Ask them to run it in front of you. Normally, testing is a repeatable procedure that ends by listing which items passed and which failed. If you cannot see that artifact, ask why.
Ask which critical flows are covered. Avoid asking about a coverage percentage, which is easy to deflect with a single number. Ask instead whether there is an automated test for the path from order to payment, and whether permission checks are tested. The answers are far more concrete.
Ask for a demonstrated failure. Have them deliberately break a piece of logic and watch the tests go red. This is the most honest check available — a test that can never fail is indistinguishable from no test.
Put tests in the deliverables. Test code should be handed over with the source code, and it should be runnable on your side or by a later vendor. NETVANA transfers source code, design files, and related documentation in full once project fees are settled, and tests are part of the source code.
Confirm when the tests run. The ideal is automatically on every change, rather than relying on somebody remembering. This belongs to the delivery process and can be settled while discussing the software development process — a rhythm of two-week sprints each ending in an operable demo already assumes that every cycle confirms the old functionality still works.
What to do when an existing system has no tests at all
This is the most common real-world situation, and the answer is not to stop everything and backfill complete coverage.
The pragmatic order is: first add tests where something recently went wrong, because that area has proven itself fragile; then where changes happen most often, because that is where regression risk is highest; and finally where an error is most expensive, usually money flows and permissions. Everything else can be picked up opportunistically whenever you touch it.
This is continuous repayment rather than a single settlement, which is the same logic used for other kinds of technical debt. The flip side is worth accepting too: a system with thin test coverage needs longer manual checks at every release, and those hours will appear in your maintenance contract under a different name.
One more angle that is useful in negotiations: if you might change maintenance vendors in the future, the presence of tests directly affects how hard the handover is. A new team facing an untested system can only read the code and guess whether a change will break something, so the transition takes longer and early quotes reflect that uncertainty. A system delivered with tests, by contrast, comes with an executable description of its behavior — one that describes not what somebody intended to build, but how it actually behaves now. That is worth a great deal when staff change or vendors are replaced.
Testing is not there to prove the system is correct today. It is there so the system can still be changed safely tomorrow, next month, and after the maintenance vendor has changed. When you evaluate a quote, treat testing as spending that reduces the risk of future changes rather than as an optional line to cut first, and your judgment will land closer to reality.
If you are planning a new project, or you have a system where every change feels like a risk, talk to NETVANA about your situation. Software services are quoted individually rather than sold as fixed packages, and we clarify the current state and its risks before advising. Consulting also covers architecture review and technical due diligence; for what each service includes, see the software services overview.
Further reading: for designing acceptance criteria and payment milestones, see How Software Acceptance Works. To understand why one small change can take so long, see Technical Debt Explained for Business Owners. For who carries post-launch checks and support, see What Website Maintenance Actually Covers. For the root causes of a schedule that keeps slipping, see Why Software Projects Run Late. And because the contract model shapes how testing gets scheduled, see Fixed Price or Agile. Knowing what each test catches makes it easier to write a report a vendor can act on; see How to Report Bugs to Your Vendor. For the environments these tests actually run in, see Test, Staging, and Production Environments. Load testing is one more type worth knowing alongside those covered here; see Preparing for a Campaign Traffic Spike.
