agentic-qe 1.9.4 → 2.1.0

package/.claude/skills/shift-left-testing/SKILL.md

@@ -1,529 +1,225 @@
 ---
 name: shift-left-testing
-description: Move testing activities earlier (left) in software development lifecycle - unit tests, TDD, BDD, design for testability, and CI/CD integration. Use when reducing bug costs, implementing DevOps practices, or enabling continuous deployment.
+description: "Move testing activities earlier in the development lifecycle to catch defects when they're cheapest to fix. Use when implementing TDD, CI/CD, or early quality practices."
+category: testing-methodologies
+priority: high
+tokenEstimate: 900
+agents: [qe-test-generator, qe-requirements-validator, qe-regression-risk-analyzer]
+implementation_status: optimized
+optimization_version: 1.0
+last_optimized: 2025-12-02
+dependencies: []
+quick_reference_card: true
+tags: [shift-left, early-testing, tdd, bdd, ci-cd, prevention]
 ---
 
 # Shift-Left Testing
 
-## Core Principle
-
-**Finding bugs earlier reduces cost by 10x-100x.**
-
-Shift-left testing moves testing activities earlier (left on timeline) in software development lifecycle. The earlier you test, the cheaper bugs are to fix and the faster you can deploy.
-
-## What is Shift-Left Testing?
-
-**Shift-Left:** Moving testing activities earlier (left on timeline) in software development lifecycle.
-
-**Traditional (Shift-Right):**
-```
-Requirements → Design → Code → Test → Deploy
-                                  ↑
-                         Testing happens here (late, expensive)
-```
-
-**Shift-Left:**
-```
-Requirements → Design → Code → Deploy
-     ↓          ↓        ↓
-   Test      Test     Test  (continuous, cheap)
-```
-
-**Benefits:**
-- 10x-100x cost reduction (bugs found early)
-- Faster feedback (minutes vs days)
-- Better quality (built-in vs bolted-on)
-- Confident deployments (continuous validation)
-
-## Shift-Left Strategies
-
-### Level 1: Traditional Testing
-
-- Testing after development complete
-- Separate QA phase
-- Manual testing dominant
-- Waterfall approach
-
-**Cost of Bug:** $1,000-10,000
+<default_to_action>
+When implementing early testing practices:
+1. VALIDATE requirements before coding (testability, BDD scenarios)
+2. WRITE tests before implementation (TDD red-green-refactor)
+3. AUTOMATE in CI pipeline (every commit triggers tests)
+4. FOLLOW test pyramid: Many unit (70%), some integration (20%), few E2E (10%)
+5. FIX defects immediately - never let them accumulate
+
+**Quick Shift-Left Levels:**
+- Level 1: Unit tests with each PR (developer responsibility)
+- Level 2: TDD practice (tests before code)
+- Level 3: BDD/Example mapping in refinement (requirements testing)
+- Level 4: Risk analysis in design (architecture testing)
+
+**Critical Success Factors:**
+- Defects found in requirements cost 1x; in production cost 100x
+- Every commit must run automated tests
+- Quality is built in, not tested in
+</default_to_action>
+
+## Quick Reference Card
+
+### When to Use
+- Reducing cost of defects
+- Implementing CI/CD pipelines
+- Starting TDD practice
+- Improving requirements quality
+
+### Cost of Defects by Phase
+| Phase | Relative Cost | Example |
+|-------|--------------|---------|
+| Requirements | 1x | Fix doc: 30 min |
+| Design | 5x | Redesign: few hours |
+| Development | 10x | Code fix: 1 day |
+| Testing | 20x | Fix + retest: 2 days |
+| Production | 100x | Hotfix + rollback + investigation |
+
+### Test Pyramid
+```
+       /\        E2E (10%) - Critical user journeys
+      /  \
+     /    \      Integration (20%) - Component interactions
+    /      \
+   /________\    Unit (70%) - Fast, isolated, comprehensive
+```
+
+### Shift-Left Levels
+| Level | Practice | When |
+|-------|----------|------|
+| 1 | Unit tests in PR | Before merge |
+| 2 | TDD | Before implementation |
+| 3 | BDD/Example Mapping | During refinement |
+| 4 | Risk Analysis | During design |
 
 ---
 
-### Level 2: Shift-Left (Unit Tests)
-
-- Developers write unit tests
-- TDD practices
-- Automated unit tests in CI
-- Test coverage metrics
-
-**Cost of Bug:** $100-1,000 (10x cheaper)
-
-```javascript
-// Developer writes test BEFORE code (TDD)
-test('calculateTotal sums line items', () => {
-  const items = [{ price: 10 }, { price: 20 }];
-  expect(calculateTotal(items)).toBe(30);
-});
-
-// Then implements code
-function calculateTotal(items) {
-  return items.reduce((sum, item) => sum + item.price, 0);
-}
-```
-
-**TDD Cycle (Red-Green-Refactor):**
-1. **Red**: Write failing test
-2. **Green**: Write minimal code to pass
-3. **Refactor**: Improve code quality
-
----
-
-### Level 3: Shift-Further-Left (Requirements)
-
-- Testable acceptance criteria
-- BDD with Gherkin scenarios
-- Executable specifications
-- Test cases from requirements
-
-**Cost of Bug:** $10-100 (100x cheaper)
-
-```gherkin
-# Specification IS test
-Feature: Shopping Cart
-
-Scenario: Calculate total with tax
-  Given I have items worth $100
-  When I apply 10% tax
-  Then the total should be $110
-```
-
-**BDD Benefits:**
-- Business stakeholders write tests
-- Living documentation
-- Automated acceptance testing
-- Shared understanding
-
-**Tools:** Cucumber, SpecFlow, Behave
-
----
-
-### Level 4: Shift-All-The-Way-Left (Design)
-
-- Testability in architecture
-- Design for testability
-- API design reviewed for testing
-- Security/performance considered early
-
-**Cost of Bug:** $1-10 (1000x cheaper)
-
-```typescript
-// Design decision: Dependency injection for testability
-class OrderService {
-  constructor(
-    private paymentGateway: PaymentGateway,  // Injectable
-    private emailService: EmailService       // Mockable
-  ) {}
-
-  // Easy to test with mocks
-  async placeOrder(order: Order) {
-    await this.paymentGateway.charge(order.total);
-    await this.emailService.sendConfirmation(order);
-  }
-}
-
-// Test with mocks (no real payment gateway needed)
-test('places order successfully', async () => {
-  const mockPayment = { charge: jest.fn() };
-  const mockEmail = { sendConfirmation: jest.fn() };
-
-  const service = new OrderService(mockPayment, mockEmail);
-  await service.placeOrder({ total: 100 });
-
-  expect(mockPayment.charge).toHaveBeenCalledWith(100);
-  expect(mockEmail.sendConfirmation).toHaveBeenCalled();
-});
-```
-
-**Design Patterns for Testability:**
-- Dependency Injection
-- Interface-based design
-- Single Responsibility Principle
-- Avoid global state
-- Pure functions (no side effects)
-
----
-
-## Continuous Testing in CI/CD
-
-### CI/CD Pipeline with Shift-Left Testing
-
-**Goal:** Test at every stage, fail fast, high confidence
+## Level 1: Tests in Every PR
 
 ```yaml
-# .github/workflows/ci.yml
-name: Shift-Left Testing Pipeline
-
+# CI pipeline - tests run on every commit
+name: CI
 on: [push, pull_request]
-
 jobs:
-  # Stage 1: Fast Feedback (< 5 minutes)
-  fast-feedback:
-    runs-on: ubuntu-latest
-    timeout-minutes: 5
-    steps:
-      - uses: actions/checkout@v3
-
-      # Static Analysis (30 seconds)
-      - name: Lint
-        run: npm run lint
-
-      - name: Type Check
-        run: npm run type-check
-
-      # Unit Tests (2 minutes)
-      - name: Unit Tests
-        run: npm run test:unit
-
-      - name: Coverage Check
-        run: npm run coverage -- --threshold 80
-
-  # Stage 2: Integration Tests (< 10 minutes)
-  integration-tests:
-    needs: fast-feedback
+  test:
     runs-on: ubuntu-latest
-    timeout-minutes: 10
     steps:
-      - uses: actions/checkout@v3
-
-      # Integration Tests (5 minutes)
-      - name: Integration Tests
-        run: npm run test:integration
-
-      # Security Scanning (3 minutes)
-      - name: Security Scan
-        run: npm audit && npm run security:scan
-
-  # Stage 3: E2E Tests (< 15 minutes)
-  e2e-tests:
-    needs: integration-tests
-    runs-on: ubuntu-latest
-    timeout-minutes: 15
-    steps:
-      - uses: actions/checkout@v3
-
-      # E2E Tests (10 minutes)
-      - name: E2E Tests with Playwright
-        run: npm run test:e2e
-
-      # Performance Tests (5 minutes)
-      - name: Performance Tests
-        run: npm run test:performance
-
-  # Stage 4: Deploy to Staging
-  deploy-staging:
-    needs: e2e-tests
-    if: github.ref == 'refs/heads/main'
+      - uses: actions/checkout@v4
+      - run: npm ci
+      - run: npm run test:unit
+      - run: npm run test:integration
+      - run: npm run lint
+
+  quality-gate:
+    needs: test
     steps:
-      - name: Deploy to Staging
-        run: ./deploy.sh staging
-
-      # Smoke Tests on Staging
-      - name: Smoke Tests
-        run: npm run test:smoke -- --env=staging
+      - name: Coverage Check
+        run: npx coverage-check --min 80
+      - name: No New Warnings
+        run: npm run lint -- --max-warnings 0
 ```
 
-**Pipeline Best Practices:**
-1. **Fail Fast**: Run fastest tests first (lint, unit)
-2. **Parallel Execution**: Run independent tests concurrently
-3. **Clear Feedback**: Immediate notification on failures
-4. **Incremental Testing**: Only run affected tests when possible
-5. **Quality Gates**: Block merges on test failures
-
 ---
 
-## Test Pyramid (Shift-Left Strategy)
-
-```
-        /\
-       /E2E\         Few (slow, expensive, brittle)
-      /------\
-     /  Int.  \      Some (moderate speed/cost)
-    /----------\
-   /    Unit    \    Many (fast, cheap, reliable)
-  /--------------\
-```
-
-**Unit Tests (Base):**
-- 70-80% of tests
-- Milliseconds execution
-- Test individual functions/classes
-- High coverage, low cost
-
-**Integration Tests (Middle):**
-- 15-20% of tests
-- Seconds execution
-- Test component interactions
-- Database, API, services
-
-**E2E Tests (Top):**
-- 5-10% of tests
-- Minutes execution
-- Test critical user journeys
-- Full stack, realistic scenarios
-
-**Shift-Left Impact:**
-Most testing happens at UNIT level (early, cheap, fast).
+## Level 2: TDD Practice
 
----
-
-## Shift-Left Practices
-
-### 1. Test-Driven Development (TDD)
-
-**Process:**
 ```javascript
-// 1. RED: Write failing test
-test('validates email format', () => {
-  expect(isValidEmail('invalid')).toBe(false);
-  expect(isValidEmail('user@example.com')).toBe(true);
+// Red: Write failing test first
+test('calculates discount for orders over $100', () => {
+  const order = new Order([{ price: 150 }]);
+  expect(order.discount).toBe(15); // 10% off
 });
 
-// 2. GREEN: Minimal implementation
-function isValidEmail(email) {
-  return email.includes('@');  // Simple, passes test
+// Green: Minimal implementation
+class Order {
+  get discount() {
+    return this.total > 100 ? this.total * 0.1 : 0;
+  }
 }
 
-// 3. REFACTOR: Improve implementation
-function isValidEmail(email) {
-  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
-  return regex.test(email);
-}
+// Refactor: Improve while keeping green
 ```
 
-**Benefits:**
-- Better design (testable by default)
-- Complete test coverage
-- Confident refactoring
-- Living documentation
-
 ---
 
-### 2. Behavior-Driven Development (BDD)
+## Level 3: BDD in Refinement
 
-**Process:**
 ```gherkin
-# Business writes this (executable spec)
-Feature: User Registration
-
-Scenario: New user signs up successfully
-  Given I am on the registration page
-  When I enter valid email "user@example.com"
-  And I enter password "SecurePass123"
-  And I click "Sign Up"
-  Then I should see "Welcome"
-  And I should receive a confirmation email
-```
+# Example mapping before coding
+Feature: Loyalty Discount
+  Scenario: Gold member gets 15% discount
+    Given a customer with "gold" membership
+    When they checkout with $200 in cart
+    Then discount applied is $30
+    And order total is $170
 
-**Implementation:**
-```typescript
-// Developer implements step definitions
-Given('I am on the registration page', async () => {
-  await page.goto('/register');
-});
-
-When('I enter valid email {string}', async (email: string) => {
-  await page.fill('[data-test=email]', email);
-});
-
-// ... more step definitions
+  Scenario: New customer gets no discount
+    Given a customer with no membership
+    When they checkout with $200 in cart
+    Then no discount is applied
 ```
 
-**Benefits:**
-- Shared language (business + dev)
-- Testable requirements
-- Automated acceptance tests
-- Reduced misunderstandings
-
 ---
 
-### 3. Design for Testability
+## Level 4: Risk Analysis in Design
 
-**Principles:**
-
-**a) Dependency Injection**
 ```typescript
-// ❌ Hard to test (tight coupling)
-class UserService {
-  async createUser(data) {
-    const db = new Database(); // Hard-coded dependency
-    return db.insert('users', data);
-  }
-}
-
-// ✅ Easy to test (loose coupling)
-class UserService {
-  constructor(private db: Database) {}
+// During architecture review
+await Task("Risk Analysis", {
+  phase: 'design',
+  component: 'payment-service',
+  questions: [
+    'What happens when payment gateway times out?',
+    'How do we handle duplicate submissions?',
+    'What if inventory changed during checkout?'
+  ]
+}, "qe-requirements-validator");
 
-  async createUser(data) {
-    return this.db.insert('users', data);
-  }
-}
-
-// Test with mock
-const mockDb = { insert: jest.fn() };
-const service = new UserService(mockDb);
+// Output: Testability requirements, failure mode tests
 ```
 
-**b) Pure Functions**
-```typescript
-// ❌ Hard to test (side effects, global state)
-let total = 0;
-function addToTotal(amount) {
-  total += amount;  // Modifies global state
-  return total;
-}
+---
 
-// ✅ Easy to test (pure, no side effects)
-function calculateTotal(current, amount) {
-  return current + amount;
-}
+## Agent-Assisted Shift-Left
 
-test('adds amounts correctly', () => {
-  expect(calculateTotal(100, 50)).toBe(150);
-  expect(calculateTotal(0, 10)).toBe(10);
-});
-```
-
-**c) Single Responsibility**
 ```typescript
-// ❌ Hard to test (multiple responsibilities)
-class OrderProcessor {
-  processOrder(order) {
-    this.validateOrder(order);
-    this.chargePayment(order);
-    this.sendEmail(order);
-    this.updateInventory(order);
-    // Too many responsibilities!
-  }
-}
-
-// ✅ Easy to test (single responsibility)
-class OrderValidator {
-  validate(order) { /* ... */ }
-}
-
-class PaymentService {
-  charge(order) { /* ... */ }
-}
-
-class EmailService {
-  sendConfirmation(order) { /* ... */ }
-}
-
-// Each class has one reason to change, one thing to test
+// Validate requirements testability
+await Task("Requirements Validation", {
+  requirements: userStories,
+  check: ['INVEST-criteria', 'testability', 'ambiguity'],
+  generateBDD: true
+}, "qe-requirements-validator");
+
+// Generate tests from requirements
+await Task("Generate Tests", {
+  source: 'requirements',
+  types: ['unit', 'integration', 'e2e'],
+  coverage: 'comprehensive'
+}, "qe-test-generator");
+
+// Smart test selection for changes
+await Task("Select Regression Tests", {
+  changedFiles: prFiles,
+  algorithm: 'risk-based',
+  targetReduction: 0.7  // 70% time savings
+}, "qe-regression-risk-analyzer");
 ```
 
 ---
 
-## Shift-Left Metrics
-
-**Track Effectiveness:**
-
-**1. Defect Detection Percentage (DDP)**
-```
-DDP = (Defects found in phase / Total defects) × 100
-
-Target: 80%+ defects found before production
-```
-
-**2. Test Coverage**
-```
-Coverage = (Lines covered / Total lines) × 100
-
-Target: 80%+ for unit tests
-```
+## Agent Coordination Hints
 
-**3. Time to Feedback**
+### Memory Namespace
 ```
-Feedback Time = Time from commit to test results
-
-Target: < 10 minutes for unit tests
-        < 30 minutes for integration tests
-        < 60 minutes for E2E tests
+aqe/shift-left/
+├── requirements/*       - Validated requirements
+├── generated-tests/*    - Auto-generated tests
+├── coverage-targets/*   - Coverage goals by component
+└── pipeline-results/*   - CI/CD test history
 ```
 
-**4. Cost of Defects**
-```
-Track cost by phase discovered:
-- Requirements: $1-10
-- Development: $100-1,000
-- QA: $1,000-10,000
-- Production: $10,000-100,000+
+### Fleet Coordination
+```typescript
+const shiftLeftFleet = await FleetManager.coordinate({
+  strategy: 'shift-left',
+  agents: [
+    'qe-requirements-validator',     // Level 3-4
+    'qe-test-generator',             // Level 2
+    'qe-regression-risk-analyzer'    // Smart selection
+  ],
+  topology: 'sequential'
+});
 ```
 
 ---
 
-## Tools for Shift-Left Testing
-
-**Unit Testing:**
-- Jest, Mocha, Vitest (JavaScript)
-- JUnit, TestNG (Java)
-- pytest (Python)
-- RSpec (Ruby)
-
-**BDD Frameworks:**
-- Cucumber, SpecFlow (Gherkin)
-- Behave (Python)
-- Jasmine (JavaScript)
-
-**CI/CD Platforms:**
-- GitHub Actions
-- GitLab CI
-- Jenkins
-- CircleCI
-- Travis CI
-
-**Code Quality:**
-- ESLint, SonarQube
-- Code coverage (Jest, Istanbul, c8)
-- Static analysis (TypeScript, Flow)
-
----
-
 ## Related Skills
-
-**Core Testing:**
-- [test-automation-strategy](../test-automation-strategy/)
-- [tdd-london-chicago](../tdd-london-chicago/)
-- [regression-testing](../regression-testing/)
-
-**DevOps:**
-- [shift-right-testing](../shift-right-testing/) - Testing IN production
-- [test-design-techniques](../test-design-techniques/)
-- [mutation-testing](../mutation-testing/)
-
-**Complementary:**
-- [shift-right-testing](../shift-right-testing/) - Production validation (the other half)
+- [tdd-london-chicago](../tdd-london-chicago/) - TDD practices
+- [holistic-testing-pact](../holistic-testing-pact/) - Proactive testing
+- [cicd-pipeline-qe-orchestrator](../cicd-pipeline-qe-orchestrator/) - Pipeline integration
+- [shift-right-testing](../shift-right-testing/) - Production feedback
 
 ---
 
 ## Remember
 
-**The earlier you find bugs, the cheaper they are to fix.**
-
-**Cost by Phase:**
-- Design/Requirements: $1-10
-- Development (unit tests): $100-1,000
-- QA/Integration: $1,000-10,000
-- Production: $10,000-100,000+
-
-**Shift-Left = 10x-100x cost reduction**
-
-**Best Practices:**
-1. Write tests BEFORE code (TDD)
-2. Make requirements testable (BDD)
-3. Design for testability (DI, pure functions)
-4. Automate everything (CI/CD)
-5. Fail fast (run fastest tests first)
-6. Test pyramid (many unit, few E2E)
+**Earlier = Cheaper.** Requirements defects cost 1x; production defects cost 100x. Test pyramid: 70% unit, 20% integration, 10% E2E. Every commit runs tests. TDD builds quality in.
 
-**With Agents:** `qe-test-generator` automatically generates shift-left tests (unit, integration) during development. `qe-regression-risk-analyzer` selects which tests to run based on code changes. Together, they enable true shift-left automation with minimal developer effort.
+**With Agents:** Agents validate requirements testability, generate tests from specs, and select optimal regression suites. Use agents to implement shift-left practices consistently.