The short version
Quality assurance is a strategy, not a final gate before launch — here is how reliable teams structure it.
Most teams treat quality assurance as the last gate before a release — a week of clicking through screens, a spreadsheet of bugs, a nervous deploy on a Friday. That model made sense when software shipped twice a year. It falls apart when you release every week, and it quietly costs far more than it saves.
Reliability is not a phase at the end of a project. It is a property you design into a product, and it is one of the few things a user notices immediately when it is missing.
What users actually mean by “quality”
When a client tells us their last build “felt buggy”, they are rarely describing a crash. They are describing an accumulation of small betrayals: a form that loses what was typed, a total that disagrees with the line items, a page that takes six seconds on a phone, a filter that silently returns nothing. Each is individually survivable. Together they teach people not to rely on the product.
It helps to separate the qualities you are testing for, because each needs a different technique:
- Correctness — the system produces the right result for both ordinary and awkward inputs.
- Resilience — it degrades sensibly when a network call fails, a third-party API is slow, or a payment gateway times out.
- Performance — it stays responsive on the devices and connections your users actually have, not the ones in your office.
- Accessibility — it works with a keyboard, a screen reader and at larger text sizes.
- Data integrity — the numbers reconcile, and nothing is lost when two people edit at once.
Where defects really come from
In our experience, comparatively few production issues are caused by a developer misunderstanding a well-specified rule. Far more come from three other places.
Ambiguous requirements
“Show recent orders” is not a requirement. Recent by order date or dispatch date? Cancelled ones too? In whose timezone? Every unanswered question becomes a guess in code, and guesses are where defects live. Writing the acceptance criteria before the ticket is estimated removes more bugs than any test suite.
The edges of the happy path
Features get built and demoed against clean data. Production has an order with zero items, a customer whose name contains an apostrophe, a PDF that is 80 MB, and a user who double-clicks the submit button on a slow connection. These are not exotic. They are Tuesday.
Change, not creation
A surprising share of incidents are regressions — something that worked last month stopped working because of an unrelated change. This is the category automated testing is genuinely great at, and the reason a regression suite pays for itself.
A testing strategy that fits a delivery team
You do not need to test everything to the same depth. You need the cheap, fast checks to be plentiful and the slow, expensive ones to be aimed carefully.
- Unit tests for logic that is easy to get subtly wrong: pricing, tax, discounts, date handling, permissions, state machines. Fast, numerous, and the first thing to run.
- Integration tests for the seams — your code against a real database, a real queue, a stubbed third-party API. Most interesting bugs live at a boundary.
- End-to-end tests for a small number of journeys you cannot afford to break: sign up, add to cart and pay, submit an application, generate the invoice. Keep this suite short and ruthlessly stable; a flaky end-to-end suite is worse than none, because people learn to ignore it.
- Exploratory testing by a person who is deliberately trying to break the thing. Automation confirms what you predicted; a human finds what you did not.
- Regression checks before every release, run automatically rather than remembered.
The tests people skip
Functional testing gets the attention; the non-functional work is what usually causes the emergency.
Performance. Test on a mid-range Android phone on a throttled connection, not a desktop on office fibre. Watch database queries per page, not just page weight — an N+1 query that is invisible with 50 records becomes an outage at 50,000.
Security. Check authorisation on every endpoint, not just authentication. The classic failure is a correctly logged-in user who can change an ID in a URL and read someone else's record.
Recovery. Restore a backup to an empty environment before you need to. An untested backup is a hope, not a plan.
The goal of QA is not zero defects. It is that nothing important breaks silently, and that anything which does break is caught by your team before it is caught by your customer.
Make quality continuous, not a gate
The shift that changes outcomes is moving these checks into the pipeline. Every pull request runs the fast suite. Every merge deploys to a staging environment that resembles production. Every release is small enough that when something does go wrong, the list of suspects is short and rolling back is boring.
Pair that with observability — error tracking, uptime checks, and alerts on the two or three metrics that represent your business working — and you close the loop: you find out from a dashboard rather than from a customer.
What to measure
- Escaped defects — issues found in production per release. The single most honest number.
- Time to restore — how long from “something is wrong” to “it is fixed”.
- Change failure rate — the share of releases needing a hotfix.
- Suite health — how long tests take and how often they fail for no reason. Both decide whether anyone trusts them.
Watch the trend, not the absolute value. Improving numbers mean the process is working.
Where to start
If none of this is in place, do not attempt all of it at once. Pick the journey whose failure would cost you the most, write acceptance criteria for it, cover it with an end-to-end test, wire that test into your pipeline, and add error monitoring so you hear about failures first. That single thread — one critical path, tested and observed — is usually enough to change how a team feels about releasing.
Our QA and testing service exists to build exactly that, and it runs alongside the delivery work rather than after it. If reliability is holding your product back, tell us where it hurts and we will tell you what we would fix first.
