4.3Practical Shift-Left Activities
Requirements Review
QA reviews user stories before sprint planning, flagging ambiguities and missing edge cases.
What to look for:
- Vague acceptance criteria ("the system should be fast")
- Missing error handling ("what happens when the API is down?")
- Undefined boundary conditions ("what is the maximum file size?")
- Missing non-functional requirements (performance, accessibility, security)
- Conflicting requirements with existing features
Before QA review:
"As a user, I want to upload a profile photo."
After QA review (questions raised):
- What file formats are accepted?
- What is the maximum file size?
- What happens if the upload fails?
- Is there a minimum resolution?
- Should the photo be cropped to a square?
- What about the existing photo -- is it kept on failure?
After refinement:
"As a user, I want to upload a profile photo (JPEG, PNG, or WebP, max 5MB, min 100x100px). The system should crop to a square, show a preview before saving, and display a clear error message if the file is too large, wrong format, or too small. Existing photo should be kept if upload fails."
The refined story has testable criteria. The original did not.
Three Amigos Sessions
Developer + QA + Product Owner meet before work begins to align on acceptance criteria. (See dedicated Three Amigos section.)
Test-Driven Development (TDD)
Developers write tests before implementation. The test defines the expected behavior, and the code is written to make the test pass.
1. Write a failing test (Red)
2. Write the minimum code to pass (Green)
3. Refactor the code while keeping tests green (Refactor)
QA's role in TDD: QA does not write unit tests (developers do), but QA can:
- Review TDD tests to verify they cover the right scenarios
- Suggest edge cases that the developer's tests should cover
- Verify that TDD tests align with acceptance criteria
Static Analysis
Linters, type checkers, and security scanners catch issues before tests run. These tools provide immediate feedback in the developer's IDE and in CI pipelines.
| Tool | What It Catches | When It Runs |
|---|---|---|
| ESLint / Pylint | Code quality issues, potential bugs | IDE + CI |
| TypeScript / mypy | Type errors | IDE + CI |
| Snyk / Semgrep | Security vulnerabilities | CI |
| Prettier / Black | Formatting inconsistencies | IDE + CI (pre-commit hook) |
| axe-core | Accessibility violations | CI + browser tests |
Pair Testing
QA pairs with a developer during implementation to catch issues in real time.
How pair testing works:
- Developer implements a feature while QA observes
- QA asks questions: "What happens if I click here while loading?" "What if this field is empty?"
- Developer addresses issues immediately (before committing)
- Both agree on what automated tests should cover
When pair testing is most valuable:
- Complex features with many edge cases
- Features with significant security or financial implications
- New team members learning the codebase
- Rebuilding trust after a series of production incidents