Software Testing

Software Development Lifecycle with Testing
────────────────────────────────────────────────────────────
Requirements  →  Design  →  Development  →  Testing  →  Deployment
     │             │            │              │            │
     ▼             ▼            ▼              ▼            ▼
  Test Plan    Test Cases   Unit Tests    Integration    Monitoring
                                            System        Feedback
                                              UAT

Bug Cost by Phase (Relative Cost)
────────────────────────────────────────────────────
Requirements   █ $1
Design        ██ $5
Development  ███ $10
Testing     ████ $15
Production ██████████████████████ $100

Finding bugs early saves exponentially more money

Possible Test Combinations
────────────────────────────────────────────────
5 fields × 10 values each = 100,000 combinations
With dependencies = 500,000+ combinations
Time to test all = Impractical

Solution: Risk-based prioritization

Defect Distribution (Pareto Principle)
────────────────────────────────────────────────
20% of modules contain 80% of defects
    │
    ▼
Focus testing on high-risk areas

Standard Testing Process
────────────────────────────────────────────────────
┌─────────────────┐
│  Test Planning  │ → Define scope, resources, timeline
└────────┬────────┘
         │
┌────────▼────────┐
│  Test Analysis  │ → Review requirements, identify testable features
└────────┬────────┘
         │
┌────────▼────────┐
│  Test Design    │ → Create test cases, prepare test data
└────────┬────────┘
         │
┌────────▼────────┐
│ Test Execution  │ → Run tests, log defects, retest
└────────┬────────┘
         │
┌────────▼────────┐
│ Test Reporting  │ → Analyze results, create reports
└─────────────────┘

Functional Testing Categories
────────────────────────────────────────────────────
Input → [Application] → Output
             ↓
    Expected vs Actual

// Example: Unit test for a calculator function
describe('Calculator', () => {
  test('adds two numbers correctly', () => {
    expect(add(2, 3)).toBe(5);
  });
  
  test('handles negative numbers', () => {
    expect(add(-1, -1)).toBe(-2);
  });
  
  test('handles zero', () => {
    expect(add(0, 5)).toBe(5);
  });
});

// Example: Integration test for API + Database
describe('User API Integration', () => {
  test('creates user and stores in database', async () => {
    const response = await request(app)
      .post('/api/users')
      .send({ name: 'John', email: 'john@example.com' });
    
    expect(response.status).toBe(201);
    
    const dbUser = await db.users.findOne({ email: 'john@example.com' });
    expect(dbUser).toBeDefined();
    expect(dbUser.name).toBe('John');
  });
});

System Test Example: E-commerce Flow
────────────────────────────────────────────────────
1. User Registration → Verify account creation
2. Login → Validate authentication
3. Browse Products → Check product display
4. Add to Cart → Verify cart updates
5. Checkout → Test payment processing
6. Order Confirmation → Validate order storage

UAT Checklist
────────────────────────────────────────────────────
□ All critical user workflows function correctly
□ Business rules are properly implemented
□ UI/UX meets user expectations
□ Performance is acceptable for real-world usage
□ Documentation is complete and accurate
□ Training materials are ready

Regression Testing Strategy
────────────────────────────────────────────────────
Code Change
     │
     ▼
Run Full Test Suite? ──No──▶ Run Selective Tests
     │                            │
    Yes                           │
     │                            │
     ▼                            ▼
High-Risk Tests         Risk-Based Selection
Core Functionality      Changed Areas Only
Critical Paths          Dependent Modules
     │                            │
     └────────────┬───────────────┘
                  ▼
            Automated Execution

Smoke Test Suite (15-30 minutes)
────────────────────────────────────────────────────
✓ Application launches
✓ Login works
✓ Main navigation functional
✓ Critical APIs respond
✓ Database connection active
✓ Key workflows execute

Pass → Proceed to full testing
Fail → Return to development

Sanity vs Smoke Testing
────────────────────────────────────────────────────
Smoke Testing          Sanity Testing
   (Broad)                (Narrow)
      │                      │
      ▼                      ▼
Test entire system     Test specific feature
After major build      After minor fix
Unscripted            Focused on changed area
30 minutes             10-15 minutes

Performance Test Types
────────────────────────────────────────────────────
Load Testing     → Normal expected load
Stress Testing   → Beyond maximum capacity
Spike Testing    → Sudden traffic increases
Endurance Testing→ Sustained load over time
Volume Testing   → Large amounts of data

// Using k6 for load testing
import http from 'k6/http';
import { check, sleep } from 'k6';
 
export const options = {
  stages: [
    { duration: '2m', target: 100 },  // Ramp up to 100 users
    { duration: '5m', target: 100 },  // Stay at 100 users
    { duration: '2m', target: 0 },    // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% requests under 500ms
    http_req_failed: ['rate<0.01'],   // Less than 1% failures
  },
};
 
export default function () {
  const res = http.get('https://api.example.com/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });
  sleep(1);
}

OWASP Top 10 Security Tests
────────────────────────────────────────────────────
1. Injection Attacks (SQL, XSS, Command)
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with Known Vulnerabilities
10. Insufficient Logging & Monitoring

// SQL Injection Test
test('prevents SQL injection', async () => {
  const maliciousInput = "'; DROP TABLE users; --";
  
  const response = await request(app)
    .post('/api/login')
    .send({ username: maliciousInput, password: 'test' });
  
  expect(response.status).not.toBe(200);
  
  // Verify database still intact
  const users = await db.users.count();
  expect(users).toBeGreaterThan(0);
});

Usability Testing Checklist
────────────────────────────────────────────────────
Navigation
  □ Menu structure is intuitive
  □ Users find features in < 3 clicks
  □ Back button works as expected

Clarity
  □ Labels are clear and descriptive
  □ Error messages are helpful
  □ Visual hierarchy is obvious

Efficiency
  □ Common tasks are quick
  □ Shortcuts are available
  □ Loading times are acceptable

Accessibility
  □ WCAG 2.1 Level AA compliant
  □ Keyboard navigation works
  □ Screen reader compatible

Compatibility Test Matrix
────────────────────────────────────────────────────
Browsers:  Chrome, Firefox, Safari, Edge
OS:        Windows, macOS, Linux, iOS, Android
Devices:   Desktop, Tablet, Mobile
Networks:  WiFi, 4G, 5G, Low bandwidth

// Cross-browser testing with Playwright
const browsers = ['chromium', 'firefox', 'webkit'];
 
for (const browserType of browsers) {
  test(`works on $\{browserType\}`, async () => {
    const browser = await playwright[browserType].launch();
    const page = await browser.newPage();
    await page.goto('https://example.com');
    await expect(page.locator('h1')).toBeVisible();
    await browser.close();
  });
}

WCAG 2.1 Compliance Levels
────────────────────────────────────────────────────
Level A     → Minimum (Basic accessibility)
Level AA    → Standard (Recommended for most sites)
Level AAA   → Enhanced (Highest level)

Code Coverage Types
────────────────────────────────────────────────────
Statement Coverage  → Every line executed
Branch Coverage     → Every if/else path tested
Path Coverage       → Every possible path tested
Condition Coverage  → Every boolean condition tested

function calculateDiscount(price, userType) {
  if (price > 100) {        // Branch 1
    if (userType === 'premium') {  // Branch 2
      return price * 0.8;   // Path 1
    }
    return price * 0.9;     // Path 2
  }
  return price;             // Path 3
}
 
// Tests covering all branches
test('premium user with high price', () => {
  expect(calculateDiscount(150, 'premium')).toBe(120);
});
 
test('regular user with high price', () => {
  expect(calculateDiscount(150, 'regular')).toBe(135);
});
 
test('user with low price', () => {
  expect(calculateDiscount(50, 'premium')).toBe(50);
});

Black Box Techniques
────────────────────────────────────────────────────
Equivalence Partitioning → Group similar inputs
Boundary Value Analysis  → Test edge values
Decision Table Testing   → Test complex logic
State Transition Testing → Test state changes
Use Case Testing        → Test user scenarios

Testing Levels Pyramid
────────────────────────────────────────────────────
                    Λ
                   / \
                  /UAT\
                 /_____\
                /       \
               / System  \
              /___Testing_\
             /             \
            / Integration   \
           /____Testing______\
          /                   \
         /    Unit Testing     \
        /_______________________\

More tests at base, fewer at top
Faster execution at base, slower at top

Waterfall Testing Flow
────────────────────────────────────────────────────
Requirements → Design → Development → Testing → Deployment
                                         ↑
                                    All testing here
                                    Issues found late
                                    Expensive to fix

Agile Testing in Sprints (2 weeks)
────────────────────────────────────────────────────
Day 1-2:   Sprint planning + Test planning
Day 3-8:   Development + Unit testing
           QA prepares test cases
Day 9-10:  Integration testing + Bug fixes
Day 11-12: Regression testing
Day 13:    Sprint review
Day 14:    Retrospective

Testing happens continuously, not at the end

        Business-Facing
             │
    Q2       │       Q3
 Functional  │    Exploratory
 Testing     │    Usability
 Story Tests │    UAT
─────────────┼─────────────── Manual/Automated
    Q1       │       Q4
 Unit Tests  │    Performance
 Component   │    Security
 Tests       │    Load Tests
             │
        Technology-Facing

CI/CD Pipeline with Testing
────────────────────────────────────────────────────
Code Commit
     │
     ▼
Unit Tests (2 min) ──Pass──▶ Build
     │                         │
    Fail                       ▼
     │              Integration Tests (5 min)
     ▼                         │
  Notify Dev        ───────────┼───────────
                   Pass        │       Fail
                     │         ▼         │
                     ▼    Notify Team ◀─┘
              System Tests (15 min)
                     │
                     ▼
              Deploy to Staging
                     │
                     ▼
              Performance Tests
                     │
                     ▼
              Security Scan
                     │
                     ▼
              Deploy to Production

Traditional vs Shift-Left
────────────────────────────────────────────────────
Traditional:
Requirements → Design → Dev → [Testing] → Deploy

Shift-Left:
[Testing] Requirements → [Testing] Design → 
[Testing] Dev → [Testing] → Deploy

Testing activities start from day one

Shift-Right Deployment
────────────────────────────────────────────────────
        Production
             │
    ┌────────┴────────┐
    ▼                 ▼
 90% Users        10% Users
 (Stable)      (New Feature)
    │                 │
    └────────┬────────┘
             ▼
      Monitor Metrics
      Success → Roll out to 100%
      Failure → Rollback

Test Plan Structure
────────────────────────────────────────────────────
1. Test Strategy
   ├─ Scope (In/Out)
   ├─ Approach (Manual/Automated)
   ├─ Resources (Team, Tools)
   └─ Schedule (Timeline)

2. Test Objectives
   ├─ Quality goals
   ├─ Coverage targets
   └─ Exit criteria

3. Test Environment
   ├─ Hardware requirements
   ├─ Software dependencies
   └─ Test data needs

4. Deliverables
   ├─ Test cases
   ├─ Test reports
   └─ Defect logs

5. Risks & Mitigation
   ├─ Resource risks
   ├─ Technical risks
   └─ Contingency plans

# Test Strategy Template
 
## 1. Test Scope
**In Scope:**
- User authentication flows
- Core business features
- Payment processing
- Mobile responsiveness
 
**Out of Scope:**
- Third-party integrations (covered by vendors)
- Legacy admin module (deprecated)
 
## 2. Test Approach
| Type        | Percentage | Tool       | Responsibility |
|-------------|------------|------------|----------------|
| Unit        | 70%        | Jest       | Developers     |
| Integration | 20%        | Playwright | QA + Dev       |
| E2E         | 10%        | Cypress    | QA Team        |
 
## 3. Entry/Exit Criteria
**Entry:**
- ✓ Code complete and deployed to test environment
- ✓ Test data prepared
- ✓ Known blockers resolved
 
**Exit:**
- ✓ 90% test cases passed
- ✓ No critical/high priority bugs open
- ✓ Performance benchmarks met
- ✓ Security scan passed
 
## 4. Test Schedule
Week 1: Test case creation
Week 2-3: Test execution
Week 4: Regression + bug fixes
Week 5: Final validation

Test Case Template
────────────────────────────────────────────────────
TC-001: User Login with Valid Credentials

Preconditions:
  - User account exists in database
  - Application is accessible

Test Steps:
  1. Navigate to login page
  2. Enter valid username
  3. Enter valid password
  4. Click "Login" button

Expected Results:
  - User is redirected to dashboard
  - Welcome message displays user's name
  - Session cookie is created

Test Data:
  Username: testuser@example.com
  Password: Test@1234

Priority: High
Type: Functional

Example: Age Input Field (Valid: 18-65)
────────────────────────────────────────────────────
Partition 1: < 18 (Invalid)     → Test with: 10
Partition 2: 18-65 (Valid)      → Test with: 30
Partition 3: > 65 (Invalid)     → Test with: 70

Instead of testing 18,19,20...65 (48 tests)
Test 3 representative values (3 tests)

Example: Discount Code (5-10 characters)
────────────────────────────────────────────────────
Test Values:
  4 chars   → Invalid (boundary - 1)
  5 chars   → Valid (min boundary)
  7 chars   → Valid (middle)
  10 chars  → Valid (max boundary)
  11 chars  → Invalid (boundary + 1)

Decision Table: Loan Approval
────────────────────────────────────────────────────
Conditions         | T1 | T2 | T3 | T4 | T5 | T6 |
────────────────────────────────────────────────────
Age 18-60          | Y  | Y  | Y  | N  | N  | N  |
Income > $30k      | Y  | Y  | N  | Y  | Y  | N  |
Credit Score > 650 | Y  | N  | Y  | Y  | N  | Y  |
────────────────────────────────────────────────────
Actions            |    |    |    |    |    |    |
────────────────────────────────────────────────────
Approve Loan       | Y  | N  | N  | N  | N  | N  |
Request More Info  | N  | Y  | Y  | Y  | Y  | N  |
Reject Application | N  | N  | N  | N  | N  | Y  |

ATM State Transition
────────────────────────────────────────────────────
        Insert Card
            │
            ▼
     [Card Inserted]
            │
    Enter PIN │ Cancel
            ▼
     [PIN Entered] ────▶ [Cancel]
            │
    Correct │ Wrong (3x)
            ▼
    [Authenticated] ────▶ [Card Blocked]
            │
    Select  │ Timeout
   Service  │
            ▼
   [Transaction]
            │
            ▼
    [Complete] ──▶ Remove Card ──▶ [Idle]

Automate vs Manual Decision Tree
────────────────────────────────────────────────────
Test Needs Frequent Execution? ──No──▶ Manual
            │
           Yes
            │
            ▼
Test is Stable? ──No──▶ Manual (for now)
            │
           Yes
            │
            ▼
ROI Positive? ──No──▶ Manual
            │
           Yes
            │
            ▼
    AUTOMATE

// Page Object Model (POM)
class LoginPage {
  constructor(page) {
    this.page = page;
    this.usernameInput = page.locator('#username');
    this.passwordInput = page.locator('#password');
    this.loginButton = page.locator('button[type="submit"]');
    this.errorMessage = page.locator('.error');
  }
 
  async login(username, password) {
    await this.usernameInput.fill(username);
    await this.passwordInput.fill(password);
    await this.loginButton.click();
  }
 
  async getErrorMessage() {
    return await this.errorMessage.textContent();
  }
}
 
// Test using POM
test('login with invalid credentials', async ({ page }) => {
  const loginPage = new LoginPage(page);
  await page.goto('/login');
  await loginPage.login('invalid@test.com', 'wrong');
  
  const error = await loginPage.getErrorMessage();
  expect(error).toContain('Invalid credentials');
});

Test Automation Pyramid
────────────────────────────────────────────────────
                 Λ
                / \              Manual Exploratory
               /E2E\             Tests (5%)
              /_____\
             /       \           
            /  API    \          API/Integration
           /  Tests    \         Tests (20%)
          /___________  \
         /               \       
        /  Unit Tests     \      Unit Tests (75%)
       /___________________\

70-80% Unit Tests     → Fast, reliable, cheap
15-25% Integration    → Medium speed & cost
5-10% E2E            → Slow, expensive, brittle

# GitHub Actions - Test Automation
name: Automated Tests
 
on: [push, pull_request]
 
jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run unit tests
        run: npm run test:unit
      
      - name: Run integration tests
        run: npm run test:integration
      
      - name: Run E2E tests
        run: npm run test:e2e
      
      - name: Upload test results
        if: always()
        uses: actions/upload-artifact@v3
        with:
          name: test-results
          path: test-results/
      
      - name: Publish test report
        if: always()
        uses: dorny/test-reporter@v1
        with:
          name: Test Results
          path: test-results/*.xml
          reporter: jest-junit

Testing Tools Ecosystem
────────────────────────────────────────────────────
Unit Testing
  ├─ Jest (JavaScript)
  ├─ JUnit (Java)
  ├─ pytest (Python)
  └─ NUnit (.NET)

E2E Testing
  ├─ Selenium
  ├─ Playwright
  ├─ Cypress
  └─ TestCafe

API Testing
  ├─ Postman
  ├─ REST Assured
  ├─ Insomnia
  └─ SoapUI

Performance Testing
  ├─ JMeter
  ├─ K6
  ├─ Gatling
  └─ Locust

Mobile Testing
  ├─ Appium
  ├─ Espresso (Android)
  ├─ XCUITest (iOS)
  └─ Detox

Security Testing
  ├─ OWASP ZAP
  ├─ Burp Suite
  ├─ SonarQube
  └─ Snyk

// ❌ Bad: Unclear test
test('test1', async () => {
  await page.click('.btn');
  expect(page.locator('.msg')).toBeVisible();
});
 
// ✅ Good: Clear, descriptive test
test('displays success message after form submission', async ({ page }) => {
  await page.goto('/contact');
  await page.fill('#email', 'test@example.com');
  await page.fill('#message', 'Hello');
  await page.click('button[type="submit"]');
  
  await expect(page.locator('.success-message'))
    .toHaveText('Thank you! We will contact you soon.');
});

test('user can update profile', async ({ page }) => {
  // Arrange - Setup test data and state
  const user = await createTestUser();
  await loginAs(page, user);
  await page.goto('/profile');
  
  // Act - Perform the action being tested
  await page.fill('#name', 'New Name');
  await page.click('button:text("Save")');
  
  // Assert - Verify expected outcome
  await expect(page.locator('.profile-name'))
    .toHaveText('New Name');
});

// ❌ Bad: Tests depend on each other
test('creates user', async () => {
  userId = await createUser('test@example.com');
});
 
test('updates user', async () => {
  await updateUser(userId, { name: 'Updated' }); // Depends on previous test
});
 
// ✅ Good: Each test is independent
test('creates user', async () => {
  const userId = await createUser('test@example.com');
  expect(userId).toBeDefined();
});
 
test('updates user', async () => {
  const userId = await createUser('test2@example.com'); // Own setup
  const updated = await updateUser(userId, { name: 'Updated' });
  expect(updated.name).toBe('Updated');
});

// Test multiple scenarios with different data
const testCases = [
  { input: 'valid@email.com', expected: true },
  { input: 'invalid-email', expected: false },
  { input: '@no-user.com', expected: false },
  { input: 'no-domain@', expected: false },
  { input: '', expected: false },
];
 
testCases.forEach(({ input, expected }) => {
  test(`validates email: $\{input\}`, () => {
    expect(isValidEmail(input)).toBe(expected);
  });
});

Testing Levels Cost-Benefit
────────────────────────────────────────────────────
                     Confidence
                         ↑
                    E2E  │  High confidence
                         │  Slow, expensive
                         │
              Integration│  Medium confidence
                         │  Medium speed
                         │
                   Unit  │  Fast, cheap
                         │  Limited scope
                         │
                         └────────────────▶ Speed

// ❌ Bad: Hard-coded sleeps
await page.click('#submit');
await page.waitForTimeout(5000); // Always waits 5s
 
// ✅ Good: Smart waits
await page.click('#submit');
await page.waitForSelector('.success-message', { 
  state: 'visible',
  timeout: 10000 
});

// Setup and teardown test data
beforeEach(async () => {
  // Create fresh test data for each test
  testUser = await db.users.create({
    email: 'test@example.com',
    password: 'hashed_password'
  });
});
 
afterEach(async () => {
  // Clean up after each test
  await db.users.deleteMany({ email: /test.*/ });
});

// ❌ Bad: Generic assertion
expect(response.status).toBeTruthy();
 
// ✅ Good: Specific assertion
expect(response.status).toBe(200);
expect(response.body).toMatchObject({
  id: expect.any(String),
  email: 'test@example.com',
  createdAt: expect.any(String)
});

describe('User Authentication', () => {
  describe('Login', () => {
    test('succeeds with valid credentials', async () => {
      // ...
    });
    
    test('fails with invalid password', async () => {
      // ...
    });
    
    test('locks account after 5 failed attempts', async () => {
      // ...
    });
  });
  
  describe('Password Reset', () => {
    test('sends reset email', async () => {
      // ...
    });
  });
});

Test Suite Health Metrics
────────────────────────────────────────────────────
Flakiness Rate:    < 2%  ✓ Healthy
                   2-5%  ⚠ Needs attention
                   > 5%  ✗ Critical

Execution Time:    < 15m ✓ Fast
                   15-30m ⚠ Acceptable
                   > 30m ✗ Too slow

Pass Rate:         > 95% ✓ Stable
                   90-95% ⚠ Monitor
                   < 90% ✗ Investigate

Flaky Test Causes
────────────────────────────────────────────────────
35% → Timing issues (race conditions)
25% → Environment instability
20% → Test dependencies
15% → External service failures
5%  → Other factors

// 1. Use explicit waits
await page.waitForLoadState('networkidle');
await page.waitForSelector('.dynamic-content');
 
// 2. Add retries for external services
await retry(async () => {
  const response = await fetch('https://api.external.com');
  expect(response.ok).toBe(true);
}, { attempts: 3, delay: 1000 });
 
// 3. Mock external dependencies
beforeEach(() => {
  mockServer.onGet('/api/data').reply(200, { data: 'test' });
});
 
// 4. Clean test data between runs
afterEach(async () => {
  await db.clean();
});

Optimization Strategies
────────────────────────────────────────────────────
Strategy              Impact    Complexity
──────────────────────────────────────────────────
Parallel execution    40-60%    Low
Selective testing     30-50%    Medium
Test optimization     20-30%    Medium
Better test data      15-25%    Low

// Parallel execution
// playwright.config.js
export default {
  workers: 4, // Run 4 tests in parallel
  fullyParallel: true,
};
 
// Selective testing based on changes
const affectedTests = await getTestsForChangedFiles([
  'src/auth/login.js',
  'src/auth/signup.js'
]);

// 1. Use Page Object Model
class LoginPage {
  // Centralize selectors
  selectors = {
    username: '[data-testid="username"]',
    password: '[data-testid="password"]',
    submit: '[data-testid="login-submit"]'
  };
  
  async login(username, password) {
    await this.page.fill(this.selectors.username, username);
    await this.page.fill(this.selectors.password, password);
    await this.page.click(this.selectors.submit);
  }
}
 
// 2. Use stable selectors
// ❌ Fragile
await page.click('.btn.btn-primary.submit-form:nth-child(3)');
 
// ✅ Stable
await page.click('[data-testid="submit-button"]');
 
// 3. Create reusable utilities
const helpers = {
  async loginUser(page, email) {
    await page.goto('/login');
    await page.fill('#email', email);
    await page.fill('#password', 'Test@1234');
    await page.click('button[type="submit"]');
  },
  
  async clearDatabase() {
    await db.users.deleteMany({});
    await db.orders.deleteMany({});
  }
};

Coverage Analysis
────────────────────────────────────────────────────
Code Coverage:       Track with tools (Jest, Istanbul)
Requirement Coverage: Traceability matrix
Risk Coverage:       Focus on high-risk areas
User Flow Coverage:  Critical paths tested

Target Coverage:
  Unit Tests:        70-80%
  Integration:       60-70%
  E2E:              Critical paths (100%)

// ✅ Good: Well-documented test
/**
 * Test Suite: User Registration
 * 
 * Prerequisites:
 * - Database is empty
 * - Email service is mocked
 * 
 * Tests cover:
 * - Happy path registration
 * - Duplicate email handling
 * - Invalid input validation
 * - Email verification flow
 */
describe('User Registration', () => {
  test('registers new user with valid data', async () => {
    // Given: A new user wants to register
    const userData = {
      email: 'newuser@example.com',
      password: 'SecurePass123!',
      name: 'John Doe'
    };
    
    // When: They submit the registration form
    const response = await request(app)
      .post('/api/register')
      .send(userData);
    
    // Then: Account is created and confirmation email is sent
    expect(response.status).toBe(201);
    expect(response.body).toMatchObject({
      id: expect.any(String),
      email: userData.email,
      name: userData.name
    });
    expect(emailService.sendVerification).toHaveBeenCalledWith(
      userData.email
    );
  });
});

Essential Testing Metrics Dashboard
────────────────────────────────────────────────────
Test Coverage
  Code Coverage:        █████████░ 85%
  Requirement Coverage: ████████░░ 80%
  
Test Effectiveness
  Defect Detection Rate:    92%
  Defect Removal Efficiency: 88%
  
Test Efficiency
  Automation Rate:      ███████░░░ 70%
  Test Execution Time:  15 minutes
  
Quality Metrics
  Defect Density:       1.2 defects/KLOC
  Defect Leakage:       5% (target: <10%)

// Calculate key defect metrics
const metrics = {
  // Defect Density = Defects / Size (KLOC)
  defectDensity: totalDefects / (linesOfCode / 1000),
  
  // Defect Removal Efficiency = (Defects found in testing / Total defects) × 100
  defectRemovalEfficiency: (defectsInTesting / totalDefects) * 100,
  
  // Defect Leakage = (Production defects / Total defects) × 100
  defectLeakage: (productionDefects / totalDefects) * 100,
  
  // Test Effectiveness = (Defects found / Test cases executed) × 100
  testEffectiveness: (defectsFound / testCasesExecuted) * 100
};

Test Execution Trend (Last 30 Days)
────────────────────────────────────────────────────
Pass Rate
100% │                             ___
 90% │                    ___     /
 80% │           ___     /       /
 70% │     ___  /       /       /
 60% │____/    /       /       /
     └──────────────────────────────────▶
      Week 1  Week 2  Week 3  Week 4

Execution Time
20m  │  ___
15m  │ /   \___
10m  │/        \___        ___
 5m  │             \___   /   
     └──────────────────────────────────▶
      Week 1  Week 2  Week 3  Week 4

# Quality Gate Configuration
quality_gates:
  unit_tests:
    min_coverage: 80
    max_execution_time: 5m
    pass_rate: 100
    
  integration_tests:
    min_coverage: 70
    max_execution_time: 15m
    pass_rate: 95
    
  e2e_tests:
    critical_paths: 100
    max_execution_time: 30m
    pass_rate: 90
    
  code_quality:
    max_critical_issues: 0
    max_major_issues: 5
    technical_debt_ratio: <5%
    
  security:
    max_high_vulnerabilities: 0
    max_medium_vulnerabilities: 5

Testing ROI Analysis
────────────────────────────────────────────────────
Costs:
  QA Team Salaries:        $300,000/year
  Tools & Infrastructure:   $50,000/year
  Training:                 $20,000/year
  Total Cost:              $370,000/year

Benefits:
  Production Bugs Prevented:     150 × $5,000 = $750,000
  Customer Retention:            +15% = $200,000
  Reduced Support Costs:         -40% = $100,000
  Faster Time-to-Market:         2 weeks = $150,000
  Total Benefit:                           $1,200,000

ROI = (Benefits - Costs) / Costs × 100
    = ($1,200,000 - $370,000) / $370,000 × 100
    = 224% ROI

Final Testing Checklist
────────────────────────────────────────────────────
Functional Testing
  □ All critical user flows work
  □ Business rules implemented correctly
  □ Error handling works as expected
  □ Data validation functioning

Performance Testing
  □ Response times meet requirements
  □ System handles expected load
  □ No memory leaks detected
  □ Database queries optimized

Security Testing
  □ Authentication secure
  □ Authorization properly enforced
  □ Input validation in place
  □ No sensitive data exposed
  □ HTTPS enforced

Compatibility Testing
  □ Works on target browsers
  □ Mobile responsive
  □ OS compatibility verified
  □ Third-party integrations tested

Usability Testing
  □ UI is intuitive
  □ Error messages are helpful
  □ Navigation is clear
  □ Accessibility requirements met

Data Testing
  □ Data migration successful
  □ Backup and restore tested
  □ Data integrity verified

Documentation
  □ User documentation complete
  □ API documentation updated
  □ Release notes prepared
  □ Known issues documented

Deployment Readiness
  □ Deployment scripts tested
  □ Rollback plan documented
  □ Monitoring configured
  □ Support team trained

Monthly Testing Retrospective
────────────────────────────────────────────────────
What Went Well:
  ✓ Automated 50 new test cases
  ✓ Reduced test execution time by 30%
  ✓ Zero critical bugs in production

What Needs Improvement:
  ⚠ Flaky tests increased to 8%
  ⚠ Test data management issues
  ⚠ Limited performance test coverage

Action Items:
  → Implement test stability monitoring
  → Create test data management strategy
  → Add performance tests for new APIs
  → Schedule testing tools training

Metrics:
  Test Coverage: 82% → 85% ↑
  Automation Rate: 65% → 70% ↑
  Defect Leakage: 8% → 5% ↓

Testing Success Formula
────────────────────────────────────────────────────
Early Testing
    +
Risk-Based Approach
    +
Automation (Right Balance)
    +
Continuous Learning
    +
Team Collaboration
    =
High-Quality Software