Software is tested before launch in layers. Automated checks verify types, code style, and behavior every time the code changes. End-to-end tests drive the application like a user would. A person then reviews it by hand. A merge gate blocks any change from going live until the automated layers pass.
"Tested" is one of the least precise words in software. It can mean a suite of automated checks that runs on every change, or it can mean someone clicked around for ten minutes on a Friday. Both get described the same way in a proposal.
We run a marketplace where attorneys find other attorneys to cover court appearances, and where money moves between them. A defect there is not a cosmetic problem. So that product has a rule: no change is merged until a fixed set of checks passes. The rule exists because careful people still ship bugs at the end of a long day.
Here is what testing consists of, in terms a business owner can use to ask better questions.
How is software tested before launch?
Software is tested before launch by combining automated checks with human review. Automated checks run every time the code changes and confirm that existing behavior still works. Human review confirms that the software makes sense to a person. Launch-ready software has passed both, on a copy of the real environment.
The two kinds catch different things. Automation is tireless and literal: it will check the same long list of behaviors on every change and never get bored. It cannot tell you that a button is confusing. A person can, but a person will not recheck that whole list every afternoon.
The final review should happen somewhere that behaves like the live system. We cover that in staging vs production.
What are the main types of software tests?
The main types of software tests are static checks, unit tests, end-to-end tests, and manual testing. Static checks read the code without running it. Unit tests run small pieces in isolation. End-to-end tests drive the whole application through a browser. Manual testing is a person using it.
| Type | What it does | What it catches | Speed | Limits |
|---|---|---|---|---|
| Type checks | Confirms data is used consistently across the code | A function given the wrong kind of value | Seconds | Says nothing about whether the logic is right |
| Lint | Flags risky or inconsistent patterns | Common mistakes, unused code | Seconds | Style and known pitfalls only |
| Unit tests | Runs one small piece with known inputs | Wrong calculations, broken rules | Fast | Does not prove the pieces work together |
| End-to-end tests | Drives a real browser through a full task | Broken sign-in, checkout, or forms | Slower | Costly to write and maintain |
| Manual testing | A person uses the software | Confusing wording, odd layouts, missing steps | Slowest | Not repeatable on every change |
A unit test is small. This one checks a single business rule:
import { test } from 'node:test';
import assert from 'node:assert/strict';
import { platformFee } from './fees.js';
test('fee is never negative', () => {
assert.equal(platformFee(0), 0);
assert.ok(platformFee(100) >= 0);
});That is an illustration, not code from one of our products. The point is the shape: a known input, an expected result, and a failure if they differ. Hundreds of these run in seconds.
What is a merge gate?
A merge gate is an automated rule that blocks a code change from joining the main version until a set of checks passes. If any check fails, the change cannot be merged, regardless of who wrote it or how urgent it is. The gate runs the same checks every time.
On CoverageCobra, the gate has four parts, in this order:
- Type checks. The code is written in TypeScript, so the compiler confirms that data is passed around consistently.
- Lint. Automated rules flag patterns that tend to cause bugs.
- Tests. The test suite runs. Playwright, a tool that drives a real browser, is part of the stack.
- Build. The application is compiled exactly as it would be for release. If it does not build, it does not ship.
A proposed change is usually packaged as a pull request, a term explained in Git and version control for business owners. A gate sits between the proposal and the main version.
Why does a gate beat good intentions?
A gate beats good intentions because it does not depend on anyone remembering, having time, or judging that this change is too small to matter. People skip checks under pressure, and pressure is highest right before a launch. A gate applies the same standard on the worst day as on the best.
Most serious bugs come from changes that looked safe. A one-line fix in one place breaks an assumption somewhere else. The person making the change is the least likely to spot it, because they are thinking about the line they changed. A test written months earlier is not thinking about anything, and it fails.
A gate also makes changes cheaper over time. With no tests, every change carries the fear of breaking something unseen, so changes get slower and more cautious. That drag is one form of technical debt.
There is a trade-off. Tests take time to write and have to be maintained as the product changes. For a five-page brochure site, a full suite is excessive, and a careful manual check is the right amount of testing. The investment should match what a failure would cost.
What should be tested by hand?
Manual testing should cover what automation cannot judge: whether wording is clear, whether the layout holds on real phones, whether the steps make sense to someone seeing them for the first time, and whether emails and messages read correctly when they arrive.
A short manual pass before any launch:
- Complete the main task from start to finish as a new customer would.
- Repeat it on a phone, on mobile data.
- Enter wrong information on purpose and read the error messages.
- Check every email or text message the system sends.
- Have someone who did not build it try, without instructions.
That last item is the most valuable and the most skipped. The people who built a thing know where to click.
What should you ask a developer about testing?
Ask a developer what runs automatically when code changes, whether a failing check blocks release, and where you can review changes before they go live. The answers show whether testing is a system or a habit. A system keeps working when people are busy.
Also ask what happens after launch. Testing reduces defects and does not eliminate them, so there should be a plan for hearing about problems quickly. See error monitoring for web apps.
Frequently asked questions
Does testing mean the software will have no bugs?
No. Testing lowers the number of defects and catches the expensive ones early. Real users will still find things. The realistic goal is that important paths are verified on every change and problems are found fast.
What is test coverage?
Test coverage is a measure of how much of the code is exercised by automated tests. It is a useful hint and a poor target. High coverage of trivial code can hide the fact that the important rules are untested.
What is user acceptance testing?
User acceptance testing is the stage where the client, or real users, try the finished software against what was agreed and confirm it does the job. It is the last check before launch.
What is a regression?
A regression is something that used to work and stopped working after a change. Automated tests exist largely to catch regressions, by rechecking old behavior every time new code is added.
Do small websites need automated tests?
Usually not a full suite. A link checker and a manual review often suffice.
If you want software where the checks are enforced by the tooling, tell us what you need built.