# Shift Left Testing > >- - **Type:** Skill - **Install:** `agentstack add skill-petrkindlmann-qa-skills-shift-left-testing` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [petrkindlmann](https://agentstack.voostack.com/s/petrkindlmann) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [petrkindlmann](https://github.com/petrkindlmann) - **Source:** https://github.com/petrkindlmann/qa-skills/tree/main/skills/shift-left-testing - **Website:** https://qa-skills.com ## Install ```sh agentstack add skill-petrkindlmann-qa-skills-shift-left-testing ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About Move quality validation earlier in the development lifecycle where defects are cheaper, faster, and simpler to fix. A missing validation rule caught in refinement is a five-minute conversation; the same bug in production is an incident, a hotfix, and a postmortem. This skill covers the practices, patterns, and cultural shifts that embed quality into every phase — from story refinement to PR merge — plus a maturity model to find the next concrete step. ## Quick Route | Situation | Go to | |-----------|-------| | QA only sees features after dev is "done" | Dev/QA Pairing → QA in Sprint Planning | | Need a pre-dev requirements conversation | Dev/QA Pairing → Three Amigos Sessions | | Deciding whether to TDD this work | TDD Facilitation → When TDD vs. Test-After | | Reviewing a PR for test quality | PR Review Checklist | | Reviewing an AI-generated/AI-using PR | PR Review Checklist → When the Change Is AI-Generated | | "Where is my team and what's next?" | Shift-Left Maturity Model | --- ## Discovery Questions Check `.agents/qa-project-context.md` first — if it exists, use it (team composition, dev/QA workflow, sprint structure, quality goals) and skip anything answered there. ### Current Dev/QA Workflow 1. **When does QA first see a feature?** After PR is raised? After merge to staging? Only when a bug appears? The answer reveals how far right your quality currently sits. 2. **Who writes tests, and when?** Developers only? QA only after dev is "done"? Both but on different timelines? Understanding current ownership is essential before changing it. 3. **How are requirements communicated?** Written specs? Verbal handoffs? Figma links with no acceptance criteria? Ambiguous requirements are the #1 source of defects that shift-left prevents. 4. **Is there interest in TDD?** Has the team tried it before? Did it stick or collapse? Understanding past attempts prevents repeating failed approaches. 5. **What does the PR review process look like?** Who reviews? Is testability a review criterion? Are tests required before merge? PR review is the lowest-friction place to introduce quality checks. 6. **What is the team's Definition of Done?** Written or unwritten? Does it include testing? Is it enforced or aspirational? The DoD is the contractual boundary between "in progress" and "done." 7. **How does QA participate in sprint planning?** Not at all? Consulted on estimates? Actively refining stories? Sprint planning participation determines how early QA thinking enters the cycle. --- ## Core Principles ### 1. Quality Is Everyone's Responsibility Quality is not a phase performed by the QA team after development. It is a property of the entire workflow: product managers write testable requirements, developers write tests alongside code, code reviewers check for testability, and QA engineers design the strategy and catch what automation misses. When quality belongs to everyone, defects are caught by whoever encounters them first. ### 2. Earlier Detection = Cheaper Fixes (Directionally) A missing validation rule caught during story refinement is a five-minute conversation. The same defect found in production is an incident, a hotfix, a postmortem, and eroded user trust. The cost of fixing a defect rises sharply the further right it is caught — refinement < design < development < QA < staging < production. That direction is real and well-attested; **the exact multipliers are not.** The widely cited "1x → 100x" table traces to an undated, unsourced IBM Systems Science Institute training chart with no published methodology, so treat any precise figure as illustrative, not measured. Lead with the concrete cost story above, not invented numbers. Shift-left practices aim to catch defects in the cheap left-hand columns — refinement through development — before QA, staging, or prod ever see them. ### 3. QA Is Embedded, Not a Gate Traditional QA acts as a gate at the end of development: code is "thrown over the wall" for testing. Shift-left embeds QA throughout the process. QA contributes to story refinement, pairs with developers on test design, reviews PRs for testability, and validates early through continuous testing. The gate model creates bottlenecks and adversarial dynamics. The embedded model creates collaboration and shared ownership. ### 4. Testability Is a Design Concern Code that is hard to test is usually hard to maintain, hard to debug, and likely to contain defects. Testability should be a first-class design constraint alongside performance, security, and usability. When developers ask "how will we test this?" during design -- before writing a single line of code -- the resulting architecture is cleaner, more modular, and more reliable. ### 5. Start Small, Prove Value, Then Expand Introducing every shift-left practice simultaneously overwhelms teams. Pick one practice (usually PR review checklists or Three Amigos), prove its value with data (fewer bugs escaping, faster PR cycles), then use that success to justify the next practice. Cultural change happens one demonstrated win at a time. --- ## Dev/QA Pairing Patterns ### QA in Sprint Planning **What it looks like:** QA engineers attend sprint planning and actively participate in story refinement. They ask clarifying questions about edge cases, identify missing acceptance criteria, and flag risk areas before development begins. **Concrete actions during planning:** 1. **Review each story for testable acceptance criteria.** Every acceptance criterion should be verifiable -- "user can sort the table" is testable; "table is user-friendly" is not. 2. **Identify edge cases and negative scenarios.** What happens with empty data? Max length input? Concurrent users? Network failure mid-operation? 3. **Flag integration risks.** Does this story touch a third-party API? Does it change database schema? Does it affect existing test data? 4. **Estimate QA effort.** Automation time, exploratory testing time, environment setup. Include this in sprint capacity. 5. **Define test approach per story.** Unit tests for business logic, integration tests for API changes, E2E for user-facing flows. **Template: QA questions for each story** ``` Story: [PROJ-1234] Add coupon code to checkout ─────────────────────────────────────────────── QA questions before development starts: 1. What happens if the coupon is expired? 2. What happens if the coupon is already used (single-use)? 3. Can multiple coupons be stacked? 4. What error message does the user see for invalid codes? 5. Does the discount update the total in real-time or on submit? 6. Is there a rate limit on coupon validation attempts? Test approach: - Unit: coupon validation logic, discount calculation, expiry check - Integration: coupon API endpoint, database state after redemption - E2E: apply coupon in checkout flow, verify discount on confirmation - Exploratory: edge cases with currency rounding, max discount limits ``` ### Three Amigos Sessions A structured 15-30 minute conversation between three perspectives before development begins. **The three perspectives:** - **Product/Business:** What does the user need? Why does this matter? - **Development:** How will we build it? What are the technical constraints? - **QA/Testing:** How will we verify it? What could go wrong? **Optional fourth amigo (AI participant):** A coding agent can generate edge cases and counter-scenarios from the acceptance criteria mid-session. Treat AI output as a checklist to validate, not a decision — humans still own the criteria. **Session format (30 minutes max):** 1. Product presents the story (5 min) -- user need, acceptance criteria 2. Development asks clarifying questions (5 min) -- feasibility, dependencies 3. QA asks testing questions (5 min) -- edge cases, error states, testability 4. Group identifies gaps (10 min) -- missing criteria added, assumptions made explicit 5. Agreement and next steps (5 min) -- updated story, risks documented, test approach agreed **When to use:** Stories with risk score Medium+, anything touching payments/auth/data integrity, stories with ambiguous requirements, cross-team stories. **When to skip:** Simple bug fixes with clear repro steps, copy/text-only changes, dependency updates with no behavioral change. ### QA Pairing on Test-First Design QA and developer collaborate on test cases before implementation. This is not full TDD -- it is test thinking applied collaboratively. **How it works:** 1. Developer and QA sit together (or share screen) for 20-30 minutes 2. QA describes the scenarios they plan to test 3. Developer writes the test signatures (function names, inputs, expected outputs) 4. Together they identify which tests are unit, integration, and E2E 5. Developer implements the feature with these tests as the target **Example output from a pairing session:** a set of agreed test signatures spanning unit, integration, and E2E levels, written before implementation. See `references/tdd-examples.md` for the full coupon-feature pairing output. ### QA Reviewing PRs QA engineers review pull requests with a focus on testability and test quality, complementing the code review performed by other developers. **Getting started for teams new to QA PR reviews:** 1. **Start with one QA reviewer on high-risk PRs only.** Do not try to review every PR on day one. 2. **Time-box reviews to 15 minutes.** QA is checking for test quality, not re-reviewing business logic. 3. **Use the PR Review Checklist below.** It provides concrete, objective criteria -- no subjective judgment required. 4. **Leave comments as suggestions, not demands.** Frame as "Consider adding a test for the empty state" rather than "Missing tests." 5. **Track value.** Note when QA review catches a gap. After 2-4 weeks, share the count with the team to demonstrate ROI. --- ## TDD Facilitation ### Red-Green-Refactor TDD follows a strict three-step cycle. Each step has a clear purpose and a clear exit condition. ``` ┌──────────────────────────────────────────────────────┐ │ RED: Write a failing test │ │ - Test describes the desired behavior │ │ - Test MUST fail (if it passes, it tests nothing) │ │ - Write the minimum test to specify one behavior │ │ │ │ GREEN: Make the test pass │ │ - Write the minimum code to pass the test │ │ - No extra features, no premature optimization │ │ - It is OK if the code is ugly │ │ │ │ REFACTOR: Clean up │ │ - Improve code structure without changing behavior │ │ - All tests still pass after refactoring │ │ - Remove duplication, improve naming, simplify │ └──────────────────────────────────────────────────────┘ ``` **Example: TDD for a password strength validator** — first failing test, minimum passing code, then a behavior-preserving refactor into a rules array. See `references/tdd-examples.md` for the full Red-Green-Refactor walk-through. ### When TDD vs. Test-After: Decision Guide TDD is not always the right choice. Use this guide to decide. | Scenario | Approach | Why | |----------|----------|-----| | Pure business logic (validators, calculators, transformers) | **TDD** | Clear inputs/outputs, fast feedback, tests document behavior | | Bug fix with known reproduction | **TDD** | Write failing test first = proof the fix works | | API endpoint with clear contract | **TDD** | Request/response is a natural test boundary | | Exploratory UI prototyping | **Test-after** | Design is unstable; tests would rewrite constantly | | Third-party integration | **Test-after** | Need to understand the API behavior first | | Complex data migration | **Test-after with fixtures** | Write sample data first, then test transformation | | Performance optimization | **Test-after with benchmarks** | Need baseline before testing improvement | | AI-generated implementation | **TDD (test first)** | LLMs happily produce passing-looking code; the failing test is the spec the agent must satisfy. Highest-leverage check on AI output. | ### TDD for Bugs (The Litmus Test) Every bug fix should start with a failing test that reproduces the bug. This practice provides three guarantees: 1. **You understand the bug.** If you cannot write a test that fails, you do not understand the bug. 2. **The fix actually works.** The test turns green when the fix is applied. 3. **The bug never returns.** The test stays in the suite as a regression guard. See `references/tdd-examples.md` for a worked failing-test-first example (a JPY zero-decimal rounding bug). ### Kata Exercises for Teams Learning TDD Short exercises (30-60 min) to build TDD muscle memory: | Kata | Difficulty | Key lesson | |------|-----------|------------| | FizzBuzz | Beginner | Basic Red-Green-Refactor cycle | | String Calculator | Beginner | Incremental complexity, edge cases | | Roman Numerals | Intermediate | Pattern recognition, refactoring | | Bowling Game | Intermediate | State management, complex rules | | Gilded Rose | Advanced | Refactoring legacy code under test harness | **Format:** Pair programming, 45 minutes, switch driver every 5 minutes. Debrief for 15 minutes: what was hard? What felt natural? What would you do differently? --- ## PR Review Checklist: QA Perspective Use this checklist when reviewing PRs for test quality and testability. Not every item applies to every PR -- use judgment based on the change scope. ### Tests Exist and Are Meaningful - [ ] **Tests accompany the code change.** New feature? New tests. Bug fix? Regression test. Refactor? Existing tests still pass (and ideally improve). No-test PRs for behavioral changes need explicit justification. - [ ] **Both happy path and edge cases are covered.** At minimum: valid input, invalid input, empty/null input, boundary values. For user-facing features: error states, loading states, empty states. - [ ] **Tests describe behavior, not implementation.** Test names read as specifications: `rejects expired coupon with clear error message` not `test coupon validator function line 42`. ### Code Is Testable - [ ] **Functions have clear inputs and outputs.** Pure functions are trivially testable. Functions with side effects should isolate the side effect (dependency injection, wrapper functions). - [ ] **Dependencies are injectable.** Database clients, HTTP clients, clocks, and random number generators should be parameters or injected -- not imported directly inside business logic. - [ ] **No hardcoded magic values.** Constants are named and configurable. Test can override them without modifying production code. ### Test Quality - [ ] **Selectors use stable strategies.** E2E tests use `data-testid`, `getByRole`, or `getByLabel` -- not CSS classes or XPath. See the selector stability scoring in `test-reliability`. - [ ] **Assertions are specific.** `expect(result).toEqual({ status: 'expired', code: 'COUPON_EXPIRED' })` not `expect(result).toBeTruthy()`. - [ ] **Test data is deterministic.** No dependency on current date, random values, or auto-increment IDs without explicit control. Use factories or fixtures. - [ ] **Tests clean up after themselves.** Created records are deleted. Modified state is restored. No test pollution. - [ ] **Test names describe the scenario.** A reader unfamiliar with the code should understand what is being tested from the test name alone. - [ ] **No coverage-only tests.** Tests that execute code without meaningful assertions inflate coverage without providing safety. ### When the Change Is AI-Generated or AI-Using Apply these additional checks when a PR contains code authored by an AI agent or introduces an AI-powered feature. - [ ] **AI provenance disclosed.** PR description names the agent, model, and what it generated (so reviewers calibrate scrutiny appropriately). - [ … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [petrkindlmann](https://github.com/petrkindlmann) - **Source:** [petrkindlmann/qa-skills](https://github.com/petrkindlmann/qa-skills) - **License:** MIT - **Homepage:** https://qa-skills.com Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-petrkindlmann-qa-skills-shift-left-testing - Seller: https://agentstack.voostack.com/s/petrkindlmann - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.