A practical responsibility model
| Role | Typical contribution |
|---|---|
| Product Owner / PM | Business outcomes, scope, priorities, customer impact, acceptance. |
| Business Analyst | Requirements clarity, rules, scenarios, acceptance criteria, traceability. |
| Developer | Code quality, unit/component tests, design, logging, error handling. |
| QA / Quality Engineer | Risk analysis, strategy, coverage, independent validation, evidence, quality recommendation. |
| Architect | Quality attributes, integration design, scalability, reliability, security. |
| DevOps / Platform | Pipeline reliability, deployment controls, environment consistency, quality gates. |
| SRE / Operations | Observability, reliability, incident readiness, supportability. |
| Business / UAT | Business suitability, user workflows, process acceptance. |
What QA should usually lead
- Quality risk assessment
- Test strategy
- Coverage model
- Evidence expectations
- Defect quality
- Traceability
- Release quality recommendation
- Quality reporting
What QA should not own alone
- Requirement correctness
- Developer unit testing
- Production monitoring
- Security architecture
- Deployment automation
- Business acceptance
- Operational support readiness
If these responsibilities are all pushed to QA, the organization creates a late-stage gatekeeper instead of an effective quality system.
Use a responsibility matrix
For complex projects, identify who is Accountable, Responsible, Consulted, and Informed for acceptance criteria, unit testing, integration testing, performance testing, test data, environments, UAT, release recommendation, and monitoring.
Useful test: If a critical quality task failed tomorrow, could you immediately name the role accountable for ensuring it happened?