When does QA join the project?
At discovery. Our testers read the plan before anyone writes code. Half of the bugs we prevent were scope questions nobody asked out loud.
Ship it once.
Break it never.
Quality is a habit, not a phase at the end. Our testers join at discovery and stay to the last release. We test the paths that earn money first. Then every fix earns a test, so the same bug does not ship twice.
- 05 Surfaces we test first
- 02 Kinds of testing, mixed
- 04 Release safeguards
- 06 Fields in every bug report
What we test, in this order
Test everything and you test nothing well. We rank by damage. A broken checkout costs revenue today. A misaligned icon does not. The list below is the order we work through on a normal release.
- 01
Money paths
Sign up, checkout and billing get tested first. If one of them breaks, nothing else on the roadmap matters that day.
- 02
Roles and permissions
We check what each role can see and do. Then we check what it must never reach. Access bugs are quiet and expensive.
- 03
Real devices and slow networks
Your users are not on a new laptop with fibre. We test on older phones and throttled links, because that is the honest case.
- 04
Keyboard and screen readers
Every flow gets a keyboard-only pass. Labels, focus order and error text are read aloud. Access work is testing, not a plugin.
- 05
Data and edge cases
Empty states, huge lists, odd characters, two tabs open at once. The cases a demo skips are the ones support hears about.
Machines repeat. People notice.
Automation is good at doing the same check forever. A person is good at spotting that a screen feels wrong. We use both, in the places each one earns its cost.
The mix is written into the plan before the sprint starts. You can see what is covered by a script and what is covered by a person.
| Where it fits | Automated checks | Human pass |
|---|---|---|
| Best at | Repeating the same check forever | Noticing that something feels wrong |
| Runs on | Every push, before merge | Every new feature, before release |
| Covers | Critical flows and past bugs | New screens, copy and edge cases |
| You get | A pass or fail in the pipeline | A written report with evidence |
A release you can undo
Most damage comes from breaking something that already worked. So we make releases reversible. Shipping stops being a late-night event.
- 01
Feature flags
Risky work ships switched off. We turn it on for a small group, watch, then widen it.
- 02
Staged rollouts
Mobile releases reach a slice of users first. A bad build stops there, not everywhere.
- 03
One-minute rollback
If a release misbehaves, we switch it off. Nobody writes a hotfix under pressure.
- 04
A test per fixed bug
Every fix earns a test that runs forever. That is how the same bug stays fixed.
Questions we get first
Do you test a product you did not build?
Yes. We start with a short audit of the current build. You get a ranked bug list and a plan you can hand to any team, including your own.
Is automation always worth it?
No. We automate flows that repeat and matter. A screen that changes every sprint is cheaper to check by hand until it settles.
What happens after launch?
Live products need checks too. Probes watch the critical paths and alert us when a key flow slows down. That work sits in support and evolution.
Starting a build now? Testing plugs straight into web development and mobile app builds. After launch it continues inside support and evolution, with the funnel side covered by analytics and CRO.
Send us the build you worry about
Tell us what keeps breaking and where it hurts. You get a ranked bug list, a test plan and a start date. One team, and one person to answer for it.