Quality assurance: how we test before you see it
What happens between a feature being built and you being asked to look at it, and why you should rarely find bugs.
The short answer
Between a feature being written and you being asked to look at it, several things happen that you never see. Automated tests run at three levels. A second developer reviews every line of the change. The result is checked against the acceptance criteria written with your team before the work started. Accessibility, performance and security checks run on a preview. And someone who did not build it walks through the flow on a phone. Your review comes after all of that, and it is for one purpose: judging whether the feature is right for the business. If you are finding broken buttons and errors, the process upstream is not working. Quality is a property of the process, not a phase at the end.
What happens before you see it
| Step | Who | What it catches |
|---|---|---|
| Automated tests | The pipeline, on every change | Logic errors, regressions, broken wiring |
| Code review | A second developer | Security gaps, unclear code, missing error handling, weak tests |
| Acceptance check | The builder, against the story’s criteria | The feature doing something other than what was agreed |
| Accessibility and performance checks | Automated tools on the preview | Contrast, keyboard access, labels, slow pages, heavy bundles |
| Security checks | Automated scanning plus review | Known vulnerable dependencies, exposed secrets, permission gaps |
| Walk-through | Someone who did not build it, on a phone and a desktop | What a real user would trip over |
| Your review | You, on the preview | Whether it is right for the business |
What your review is for
- Does it fit how the business actually works? The edge cases from real life that nobody wrote down.
- Are the words right? Labels, messages, tone, terminology your customers use.
- Is anything missing that the story implied but did not state?
- Would you be comfortable with a customer or colleague using this tomorrow?
- Not: does the button work, does the page load, is there an error. Those were checked.
What happens to defects
Every defect found, at any stage, becomes a test so that the same kind cannot return. Every review comment that reveals a misunderstanding becomes a clarification in the story or the documentation. Over time the process gets tighter, and the proportion of your review spent on judgement rather than defects goes up. That trend is the measure of a quality process.
What this means for you
Expect a process, not a phase: automated tests, code review, acceptance checks, accessibility and security checks, a walk-through, and only then your review, which should be about whether the feature is right rather than whether it works. If you are finding bugs, say so and ask which steps are missing. Quality assurance done properly is mostly invisible, which is exactly how it should feel.
Frequently asked questions
Should we do our own testing before launch?
Yes, for what only you can judge: whether it fits how the business works, whether the words are right, whether the edge cases from real life are handled. Not for finding broken buttons and errors; those should have been caught before you were asked to look. Your time is best spent on judgement, and a process that hands you defects is wasting it.
What does a code review actually check?
A second developer reads every change before it is merged: does it do what the story says, is it secure, is it clear enough for the next person, does it handle errors, are the tests meaningful, does it follow the project's conventions. It catches what the author cannot see in their own work and spreads knowledge of the system across the team.
How do you test on real devices?
Automated checks run at several screen sizes on every change. Before release, the critical flows are walked through on actual phones and browsers, including older and cheaper devices, because that is where problems that emulators miss appear. A preview link makes that possible for you too.