Resources
QA Process
A practical QA process for product teams: intake, risk, cases, execution, defects, and release evidence — without a maturity-model poster or a fake certification.
A QA process is the repeatable path from “this change might break something” to “here is what we tested, what we found, and what we skipped.” It is not a wall of ISTQB terms, not a maturity score, and not a certificate you can buy.
If you cannot point to a dated build and say what was covered, you do not have a process. You have testers improvising. Start with a QA audit if that is the situation.
The loop that actually runs
- Intake. What is changing, what must not break, when it ships. If this is missing, later work is archaeology. A test plan is the written version for one release.
- Risk. Which journeys lose money, data, or trust. Those go first. Everything else is optional when the date does not move.
- Design. Cases and, when requirements exist, an RTM. Exploratory charters for the paths scripts will miss.
- Execute. On an environment that matches what you intend to ship. Log the build.
- Defects. One issue, enough to fix — see the bug report template and severity vs priority.
- Evidence. What passed, what failed, what was not tested. Then stop or re-test. Do not rewrite the test strategy every sprint.
Shift-left moves steps 1–3 earlier. The test pyramid says how much automation sits in step 4. Neither replaces the loop.
Who owns which step
| Step | Typical owner |
|---|---|
| Intake / “done” | Product + engineering |
| Risk cut | QA + product |
| Cases and RTM | QA |
| Unit / contract checks | Engineering |
| Execution and exploratory | QA |
| Fix | Engineering |
| Release evidence | Named person — not “the team” |
If a step has no owner, it will not happen. QA outsourcing or a dedicated QA team can own execution. They cannot invent a counterpart who answers “is this a bug?”
What we will not put in a process doc
- Invented cycle-time percentages
- A “level 4 of 5” maturity stamp
- A tool list pretending to be a process
- ISO or ISTQB as a substitute for evidence on this product
FAQs
What is a QA process in one sentence?
A named way to decide what to test, run it, log defects, and leave evidence — then do it again on the next change.
Do we need all the templates?
No. Cases and a bug format cover most squads. Add a plan when a release needs a written scope. Add a strategy when two squads disagree on “done.”
How do we start?
Book a QA consultation. Bring the last release that surprised you. We will say whether you need a process, testers, or an audit.
Talk to our QA team
Want this applied to your next release?
We write and maintain these artefacts on live products — then execute the cases, not only the documents.