QA Collaboration
Purpose
QA does not receive a Project: QA co-authors it. Quality is shaped into the spec from day one, not bolted on at the end. This document describes how QA participates across the Project lifecycle.
QA is the author of the Test Plan and co-author of the Project from Shaping onward.
Core Rule
Every EARS requirement must produce at least one test case. If QA cannot write a test case for a requirement, the requirement is ambiguous and the Project returns to Shaping.
QA Activities by State
Shaping · QA co-authors the spec
QA reads the draft spec, reviews every EARS requirement for ambiguity, and flags anything that cannot produce a test case. QA drafts the Test Plan inside the spec, mapping test cases to EARS identifiers.
QA is not a reviewer at this stage: QA is an author. The PM and QA iterate together until the Test Plan is complete.
Refining · Test Plan complete
QA finalizes the Test Plan. A Project without a complete Test Plan cannot proceed to Spec Review. The CPO does not approve a spec whose Test Plan QA has not completed.
Prioritized · Preparation
While the Project waits in the queue, QA prepares:
- Test environments and test data.
- Automation candidates (which cases are worth automating).
- Fixtures and mock accounts where needed.
In Progress · Developer collaboration
QA is available for developer questions about expected behavior. When a developer surfaces an edge case not covered by the spec, QA and the PM decide whether to add a requirement (return to Shaping briefly) or record a no-goal.
In Review · Test execution
QA executes the Test Plan. Bugs are reported as Issues inside the same Project, linked to the failing EARS requirement. Developers fix. QA re-tests.
Exit criterion: zero Severity 1 or 2 bugs open. QA confirmation is required before the Project can reach Resolved.
Resolved · Production smoke and monitoring
After deploy, QA runs a production smoke test and records findings. QA supports Development during the 72-hour monitoring window by validating that production signals match the Quality Bar expectations.
Severity Definitions
| Severity | Definition | Blocks exit from In Review |
|---|---|---|
| Sev 1 | Blocker. Feature unusable or data loss risk | Yes |
| Sev 2 | Major. Key path broken for a significant user segment | Yes |
| Sev 3 | Minor. Workaround exists or small user impact | No |
| Sev 4 | Cosmetic. No functional impact | No |
Sev 3 and Sev 4 bugs are logged as Issues and scheduled for follow-up, not held against the exit criterion.
Handoffs and Signals
- Spec Review invite: the PM includes QA by default. If QA did not co-author, the Spec Review cannot happen.
- Test Plan completion: recorded as a comment on the Project in Linear, referencing the spec version.
- QA pass: recorded as a comment on the Project, listing the tested EARS identifiers.
Related Documentation
- Product Framework Overview
- Project Lifecycle — where transition checkpoints are evaluated.
- Spec and EARS — how EARS requirements map to test cases.