01What "shift-left" looks like in practice
- QA joins story refinement to challenge edge cases and write acceptance criteria
- Test cases are sketched during development, not after
- Engineers run their own smoke tests before handing off
- Exploratory sessions happen on early builds, not just release candidates
- CI runs broad automated coverage every commit so regressions surface within minutes
02Why it works
The longer a defect lives, the more expensive it is to fix. A bug found in design review is a 30-second conversation. The same bug found in production is a postmortem.
03Common failure modes
- "Shift-left" used as code for "make engineers do all the testing"
- Adding QA to refinement meetings without giving them context to contribute
- Buying tools but not changing process
The point of shift-left is shorter feedback loops, not relabelling roles.
04Related
05Frequently asked questions
Does shift-left mean QA disappears?
No. It means QA contributes earlier — to acceptance criteria, edge case discussion, exploratory testing on early builds — instead of being a final gate.
Is automation required for shift-left?
Not strictly. Automation amplifies shift-left by making fast feedback possible during development, but the practice itself is about timing and collaboration, not tools.