One of the most powerful shift-left practices is bringing QA into requirements and design discussions, not just after features are built. Early test design clarifies expectations, uncovers ambiguities and prevents whole classes of defects.
Collaborating on Requirements and Acceptance Criteria
In agile teams, QA can join refinement sessions and propose test scenarios, edge cases and acceptance criteria while stories are still being shaped. This helps product owners refine scope and developers understand how their work will be validated.
Example acceptance criteria with a testing flavour:
- Given a valid user, when they enter correct credentials, then they see the dashboard
- Given a locked account, login attempts are rejected with an appropriate message
- All password reset emails use the latest template and expire within 30 minutes
- Invalid inputs show clear validation messages without server errorsWhen QA shapes requirements, fewer surprises appear during implementation and testing becomes a confirmation step instead of discovery of basic gaps.
Common Mistakes
Mistake 1 — Treating acceptance criteria as an afterthought
This reduces clarity.
❌ Wrong: Adding vague or minimal criteria just before development starts.
✅ Correct: Co-create concrete, testable criteria during refinement.
Mistake 2 — Limiting QA input to “edge cases only”
This narrows perspective.
❌ Wrong: Assuming QA should only think about rare failures.
✅ Correct: Have QA contribute to core flows, usability considerations and negative scenarios.