agentic-qe 1.4.3 → 1.5.0

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

@@ -1,535 +1,529 @@
----
-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.
-version: 1.0.0
-category: testing-methodologies
-tags: [shift-left, tdd, bdd, cicd, devops, early-testing, design-for-testability]
-difficulty: intermediate
-estimated_time: 60 minutes
-author: agentic-qe
----
-
-# 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
-
----
-
-### 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
-
-```yaml
-# .github/workflows/ci.yml
-name: Shift-Left Testing Pipeline
-
-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
-    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'
-    steps:
-      - name: Deploy to Staging
-        run: ./deploy.sh staging
-
-      # Smoke Tests on Staging
-      - name: Smoke Tests
-        run: npm run test:smoke -- --env=staging
-```
-
-**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).
-
----
-
-## 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);
-});
-
-// 2. GREEN: Minimal implementation
-function isValidEmail(email) {
-  return email.includes('@');  // Simple, passes test
-}
-
-// 3. REFACTOR: Improve implementation
-function isValidEmail(email) {
-  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
-  return regex.test(email);
-}
-```
-
-**Benefits:**
-- Better design (testable by default)
-- Complete test coverage
-- Confident refactoring
-- Living documentation
-
----
-
-### 2. Behavior-Driven Development (BDD)
-
-**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
-```
-
-**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
-```
-
-**Benefits:**
-- Shared language (business + dev)
-- Testable requirements
-- Automated acceptance tests
-- Reduced misunderstandings
-
----
-
-### 3. Design for Testability
-
-**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) {}
-
-  async createUser(data) {
-    return this.db.insert('users', data);
-  }
-}
-
-// Test with mock
-const mockDb = { insert: jest.fn() };
-const service = new UserService(mockDb);
-```
-
-**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;
-}
-
-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
-```
-
----
-
-## 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
-```
-
-**3. Time to Feedback**
-```
-Feedback Time = Time from commit to test results
-
-Target: < 10 minutes for unit tests
-        < 30 minutes for integration tests
-        < 60 minutes for E2E tests
-```
-
-**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+
-```
-
----
-
-## 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)
-
----
-
-## 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)
-
-**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.
+---
+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.
+---
+
+# 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
+
+---
+
+### 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
+
+```yaml
+# .github/workflows/ci.yml
+name: Shift-Left Testing Pipeline
+
+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
+    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'
+    steps:
+      - name: Deploy to Staging
+        run: ./deploy.sh staging
+
+      # Smoke Tests on Staging
+      - name: Smoke Tests
+        run: npm run test:smoke -- --env=staging
+```
+
+**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).
+
+---
+
+## 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);
+});
+
+// 2. GREEN: Minimal implementation
+function isValidEmail(email) {
+  return email.includes('@');  // Simple, passes test
+}
+
+// 3. REFACTOR: Improve implementation
+function isValidEmail(email) {
+  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
+  return regex.test(email);
+}
+```
+
+**Benefits:**
+- Better design (testable by default)
+- Complete test coverage
+- Confident refactoring
+- Living documentation
+
+---
+
+### 2. Behavior-Driven Development (BDD)
+
+**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
+```
+
+**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
+```
+
+**Benefits:**
+- Shared language (business + dev)
+- Testable requirements
+- Automated acceptance tests
+- Reduced misunderstandings
+
+---
+
+### 3. Design for Testability
+
+**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) {}
+
+  async createUser(data) {
+    return this.db.insert('users', data);
+  }
+}
+
+// Test with mock
+const mockDb = { insert: jest.fn() };
+const service = new UserService(mockDb);
+```
+
+**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;
+}
+
+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
+```
+
+---
+
+## 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
+```
+
+**3. Time to Feedback**
+```
+Feedback Time = Time from commit to test results
+
+Target: < 10 minutes for unit tests
+        < 30 minutes for integration tests
+        < 60 minutes for E2E tests
+```
+
+**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+
+```
+
+---
+
+## 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)
+
+---
+
+## 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)
+
+**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.