"We tested it" is not a QA strategy — it's a hope. A real testing process needs to be repeatable, layered, and built into the development workflow from day one, not bolted on right before launch.
The layers we test
- Unit tests — the smallest pieces of logic (a function, a component) verified in isolation, run on every commit.
- Integration tests — checking that pieces work together correctly: API endpoints, database interactions, third-party services.
- End-to-end tests — simulating real user flows through the actual application, catching issues that only show up when everything runs together.
- Manual exploratory testing — a human deliberately trying to break things in ways automated tests don't anticipate, especially around edge cases and usability.
Why automation alone isn't enough
Automated tests are excellent at catching regressions — making sure something that used to work still works after a change. What they're bad at is catching problems nobody thought to test for in the first place. That's where manual QA earns its keep: real people, using the product the way real users will, before your users do.
Building QA into the workflow, not after it
The teams that ship the fewest production bugs aren't the ones with the most tests — they're the ones where testing happens continuously:
- Tests are written alongside the feature, not after.
- CI runs the full suite on every pull request, not just before release.
- QA has visibility into the product early enough to flag design issues, not just implementation bugs.
Good QA is invisible when it's working — nothing breaks, nothing surprises your users. That's the goal we build toward on every project.