Inside our QA process: how bugs die before clients meet them

Clients rarely ask about QA in the sales conversation. They ask about it three months in, when the first release lands and either works or does not. By then the answer was decided long ago, because quality is not something you inspect in at the end. It is a series of gates a change passes through, and the gates either exist or they do not.

This post is a straight walkthrough of our gates. Nothing here is secret or clever. The value is in running all of it, every time, on every project, including the small ones.

QA starts in the ticket, not the test

Most bugs are not coding mistakes. They are misunderstandings that got built. The developer implemented what the ticket said, the ticket did not say what the client meant, and the gap shipped. So our first gate is the ticket itself: no work starts until the ticket has acceptance criteria written as checkable statements. "The overdue invoice list shows invoices unpaid 30 or more days after due date, sorted oldest first" can be verified. "Improve the invoice screen" cannot.

Writing criteria this way costs the analyst ten extra minutes and routinely surfaces the hard questions early: what happens at exactly 30 days, what about credit notes, who may see this list at all. Ten minutes in the ticket, or three days of rework later. We covered how these tickets get shaped in how we work.

The testing pyramid, sized for real budgets

We automate tests in a deliberate ratio. Lots of fast unit tests for pure logic: pricing rules, date maths, permission checks. A solid layer of integration tests that hit a real API and a real database, because that is where most production bugs live: the query that ignores the tenant filter, the endpoint that forgets an access check. And a deliberately small set of end-to-end browser tests covering only the flows where nothing cheaper can prove correctness, such as login, payment, and file upload.

The ratio matters because teams fail at both extremes. All-unit-test suites pass while the product is broken. All-browser-test suites take 40 minutes, flake constantly, and get skipped under deadline. The pyramid keeps feedback under ten minutes, which is the threshold at which developers actually run the suite before pushing.

Code review is a quality gate, not a courtesy

Nothing merges without a second engineer reading it. Reviews check four things in order: does it meet the acceptance criteria, does it handle the unhappy paths, is the security posture right for this change, and will the next person be able to maintain it. Style debates are delegated to the formatter and linter so humans never spend review time on commas.

We keep changes small on purpose. A 300-line change gets a real review; a 3,000-line change gets a tired scroll and an approve. Small changes are the cheapest QA tool that exists.

Staging is a dress rehearsal, not a formality

Every project has a staging environment that mirrors production: same infrastructure shape, same integrations pointed at sandboxes, and realistic anonymised data volumes. That last part matters more than teams expect. A register screen that is instant with 50 test rows can crawl with 80,000 real ones, and staging with ten rows of data will never tell you.

1. 1The developer demos the change against the acceptance criteria on staging.
2. 2A tester who did not build it runs the scripted checks plus deliberate misuse: wrong file types, double submits, expired sessions.
3. 3The client walks through the flow themselves and signs off in the ticket.
4. 4The release checklist runs: migrations rehearsed, rollback path confirmed, monitoring dashboards ready.
5. 5Ship. Small releases, often, never on the eve of a client's critical business day.

Production is part of QA too

The gates reduce defects; they cannot make software perfect. So the final layer is noticing fast. Every project ships with error tracking, uptime checks on the endpoints that matter, and alerts routed to the team that can act, not to a dashboard nobody watches. Our target is that we tell the client about an incident before they tell us, and on most projects we hold it.

None of this is exotic, and that is the point. Quality is not a heroic testing sprint before launch. It is the same boring gates, run every time, until clients stop finding bugs because the process already did. If you want to see what that discipline looks like on your project, start with our custom software development service.