QA: Workflows
How quality work moves from requirement to release confidence, and the handoffs with Engineering, AI Engineering, Security and Support.
Markdown. No sign-up, no email.
Quality is decided long before anything is tested. By the time a build exists, most of what will go wrong has already been written into the requirement, which is why this function starts there.
What arrives#
| From | What | Becomes |
|---|---|---|
| Product and BA | Requirements | A completeness, contradiction and testability review |
| Engineering | Changes | Generated tests and a coverage read |
| Security | Threat findings | Security test cases |
| Support | Customer defects | A reproduction, a test, then a fix request |
| Production monitoring | Escaped defects | A postmortem and a new test |
What leaves#
| To | What |
|---|---|
| Product and BA | Requirements sent back, with the specific gap named |
| Engineering | Defects with reproductions, and the modules where they concentrate |
| The release decision | A confidence score and its untested list |
| Support | What is known-broken before a customer finds it |
| Knowledge Management | Defect patterns and root causes |
The path#
Handoff contracts#
From Product. A requirement arrives testable or it comes back. This is the least popular contract in the list and the one that prevents the most damage: everything downstream inherits the ambiguity of the sentence at the top.
With Engineering. They generate tests with their code; QA reviews the gap, not the output. Reviewing thousands of generated cases individually is where a QA function drowns while adding nothing.
With AI Engineering and Product. Anything measured against a distribution is theirs, not ours. A learned system is not right or wrong against a specification, and applying deterministic QA to it produces false confidence in both directions.
To Support. Known-broken things are communicated before release, never discovered by a customer describing them to someone who has not heard.
Cadence#
| Per requirement | Completeness, contradiction, testability |
| Per change | Generation, gap review, suite |
| Per release | Confidence with reasons and the untested list |
| Weekly | Flake rate, defect-to-fix time |
| Monthly | Defect patterns, calibration, escaped-defect review |
The failure this design is built against#
A pipeline reporting green while the untested path is the one the customer will use. Everything here, requirement testability first, reviewing the gap rather than the output, and a confidence score that must state what it does not cover, exists to make the untested path visible at the moment someone is deciding whether to ship.