| name | qa-process-design |
| description | Use when designing quality assurance processes — defining quality standards, integrating QA checkpoints into SDLC, creating process documentation, onboarding teams to quality practices, and building a quality-first engineering culture. |
QA Process Design
When to Use
- Setting up QA for a new team or project from scratch
- Improving an existing process that's producing too many defects
- Integrating quality gates into CI/CD pipeline (beyond just running tests)
- Defining "Definition of Done" and quality standards
- Building a quality culture in a team that doesn't have one
Core Jobs
1. Quality Standards Definition
# Quality Standard: Code Quality
## Purpose
Ensure all code merged to main meets minimum quality standards.
## Standards
### Code Review (mandatory)
- Every PR requires at least 1 reviewer (2 for security-sensitive code)
- Reviewer checks: logic correctness, security, test coverage, style
- Author must not approve their own PR
- Review completed within 24 hours (48 hours for complex PRs)
### Test Coverage
- Unit test branch coverage: >= 80% for business logic
- New code without tests: block merge (enforced by CI)
- Flaky tests: fix within 2 business days or quarantine
### Static Analysis
- SonarQube quality gate: no new Critical/Blocker issues
- Security scan: no new HIGH/CRITICAL vulnerabilities (Snyk/Dependabot)
- Linting: must pass (no warnings allowed on new code)
### Documentation
- Public APIs: OpenAPI spec updated
- Architecture decisions: ADR written for significant changes
- README updated if behavior changes
## Enforcement
- CI pipeline enforces coverage, linting, security scan
- PR template reminds reviewers of standards
- Weekly metrics review: any team consistently below standard -> coaching
2. SDLC Quality Integration
Requirements phase:
QA activity: Requirements review for testability, ambiguity
Output: Testable requirements, acceptance criteria per story
Gate: No story moves to development without acceptance criteria
Design phase:
QA activity: Review architecture for testability, observability
Output: Test approach defined (what level, which tools)
Gate: Test approach approved before implementation starts
Development phase:
QA activity: TDD coaching, PR review participation, daily stand-up
Output: Unit tests alongside code, PR quality review
Gate: Coverage threshold enforced in CI
Testing phase:
QA activity: Test execution, defect reporting, regression
Output: Test report, defect list, go/no-go recommendation
Gate: All P1/P2 defects resolved before release
Release phase:
QA activity: Release readiness review, sign-off
Output: Release sign-off document
Gate: QA sign-off required before production deployment
Post-release:
QA activity: Production monitoring, escape rate measurement
Output: Monthly QA metrics report
Gate: Escape rate reviewed monthly
3. Definition of Done
## Definition of Done (DoD)
A user story is Done when:
### Development
- [ ] Code reviewed and approved (2 reviewers for security changes)
- [ ] Unit tests written with >= 80% branch coverage for new code
- [ ] Integration tests added for new API endpoints
- [ ] No new SonarQube Critical/Blocker issues
- [ ] No new security vulnerabilities (Snyk)
- [ ] Code merged to main branch
### Testing
- [ ] AC (acceptance criteria) tested and passing
- [ ] Regression suite passes (no new failures)
- [ ] Cross-browser tested if UI changes
- [ ] Performance acceptable (no significant regression)
### Documentation
- [ ] API docs updated (if applicable)
- [ ] User-facing changes in release notes
### Operations
- [ ] Logging added for new operations
- [ ] Alerts configured for new failure modes
- [ ] Feature flag configured (for gradual rollout)
4. Quality Culture Building
Levels of quality maturity:
Level 1 — Reactive (fire-fighting)
- Defects found in production
- QA as final gatekeeper (bottleneck)
- No test automation
Actions: Establish basic process, introduce TDD, set up CI
Level 2 — Defined (process exists)
- Test coverage exists
- QA integrated in sprint
- Some automation
Actions: Enforce standards, introduce code review, measure escape rate
Level 3 — Managed (metrics-driven)
- Escape rate tracked
- Shift-left in progress (more unit tests, fewer prod bugs)
- Developer-owned quality
Actions: Shift QA to coaching role, improve metrics, automate quality gates
Level 4 — Optimizing (quality is owned by everyone)
- Defects mostly caught in unit tests
- QA focuses on strategy and risk
- Quality metrics visible to all stakeholders
Current level assessment -> define improvement roadmap -> measure progress quarterly
Key Concepts
- QA — Quality Assurance: process-oriented, proactive, focuses on prevention
- Definition of Done (DoD) — explicit criteria a story must meet before being "done"; enforced as a team agreement
- Quality gate — automated checkpoint that blocks progress if quality criteria not met
- Shift-left — moving quality activities earlier in SDLC (finding bugs in requirements/unit test, not production)
- Quality culture — organizational mindset where every team member owns quality (not just QA team)
Checklist
Key Outputs
- Quality standards document (code review, coverage, static analysis)
- Definition of Done checklist agreed by team
- SDLC quality integration map (QA activity per phase)
- Quality maturity assessment and improvement roadmap
Output Format
- 🔴 Critical — no DoD (done means different things to different people), QA as final gatekeeper only (too late, bottleneck), no quality gates in CI
- 🟡 Warning — DoD exists but not enforced, quality standards verbal only (not documented), no SDLC integration beyond testing phase
- 🟢 Suggestion — run quality maturity assessment with team, automate DoD checklist in PR template, start shift-left initiative with TDD coaching
Anti-Patterns
- QA team as the "quality police" (developers don't own quality -> adversarial culture)
- DoD only covering functional requirements (ignoring non-functional: performance, security)
- Process designed in ivory tower without team input (teams don't follow what they didn't help design)
- Heavy process for small teams (right-size process to team size and risk)
Integration
test-strategy — process design informs the overall test strategyqa-audit — process designed here is what gets audited for complianceqa-risk-management — risk assessment informs which process controls to prioritize
