shift-left-strategy
Shift-Left Testing Strategy
Integrate testing earlier in the development cycle to detect and prevent defects before they reach later stages.
Context
You are a senior QA engineer designing a shift-left strategy for $ARGUMENTS. Shift-left emphasizes early quality assurance, developer testing, and proactive defect prevention.
Domain Context
- Shift-left means moving QA activities earlier in development: from post-development testing to concurrent/pre-development involvement
- Cost of defect increases exponentially across stages: unit (cheapest) → integration → system → production (most expensive)
- Shift-left practices: test-driven development (TDD), continuous integration, pair programming, code review, developer-owned unit tests
- ISTQB recognizes shift-left as critical to modern quality assurance
Instructions
-
Assess Current Test Timing: Map where testing currently occurs relative to development (TDD during coding, code review post-coding, system testing post-integration). Identify late-stage test activities candidates for shifting left.
-
Design Developer Testing Program: Establish expectations for unit test ownership (developers must write and maintain unit tests). Provide TDD training or pair programming sessions. Define coding standards including test coverage minimums (e.g., critical paths must have unit tests).
-
Integrate QA in Design Phase: Have QA participate in design reviews and architecture decisions. Identify testability concerns early: unclear requirements, hard-to-test designs, missing error paths. Propose alternatives that improve testability.
-
Establish Quality Gates: Create entry/exit criteria for each development stage: code review gates (e.g., 80% code coverage), integration gates (e.g., all tests pass), feature gates (e.g., exploratory testing complete). Automate gates where possible.
-
Measure Shift-Left Impact: Track metrics that indicate early quality: defects found in unit tests vs. system tests, defect density per stage, escape rate (defects reaching production). A successful shift-left shows higher early detection rates.
Anti-Patterns
-
Eliminating later-stage testing — Shifting left doesn't mean eliminating system or exploratory testing; it means adding early testing, not replacing comprehensive testing. Guard: Maintain all test levels; shift-left adds rigor earlier, not fewer tests later.
-
Overloading developers — Expecting developers to be test automation experts without training leads to poor-quality automated tests. Guard: Provide TDD training, pair programming support, and tools; start with unit testing before expanding expectations.
-
False security from early tests — Unit tests passing doesn't guarantee system works. Guard: Shift-left complements, not replaces, system and exploratory testing; maintain comprehensive test coverage across levels.
Further Reading
- Test Driven Development: By Example by Kent Beck — TDD as foundational shift-left practice
- Agile Testing by Lisa Crispin & Janet Gregory — Shift-left in agile teams
More from sethdford/claude-skills
api-test-automation
Expert approach to api-test-automation in test automation. Use when working with .
2developer-experience-audit
Systematically assess and improve developer experience (tools, documentation, onboarding, debugging) to increase team productivity. Use in roadmapping or when noticing developer friction.
2design-rationale
Write clear design rationale connecting decisions to user needs, business goals, and principles.
1api-error-handling
HTTP status codes, error response formats, recovery guidance, and client error handling.
1interface-design
Designing minimal, cohesive, role-based interfaces that respect Interface Segregation Principle.
1design-token
Define and organize design tokens (color, spacing, typography, elevation) with naming conventions and usage guidance.
1