agentic-qe 1.2.0 → 1.3.1

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

@@ -0,0 +1,535 @@
+---
+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.