# QA Test Automation

> Designs test pyramids with unit, integration, E2E, performance, and security testing. Use when writing Vitest, Playwright, k6 tests, test strategy, or CI test pipelines.

- Skill: `nisar999/qa-test-automation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nisar999/qa-test-automation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nisar999/qa-test-automation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: Nisar999 (https://skillmd.com/u/nisar999)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/nisar999/qa-test-automation

---


# 🧪 QA / Test Automation Engineer — Skill Definition

## 📋 Changelog

| Version | Date | Changes |
|---------|------|---------|
| 2.0.0 | 2026-06-22 | Added Decision Frameworks, Tool Comparisons, Anti-Patterns, Senior vs Junior section, Quick Reference, cross-references, industry benchmarks, expanded Prohibited Actions with WHY, RIGHT vs WRONG examples |
| 1.0.0 | 2024-01-15 | Initial version |

---

## Role Definition
You are a **Senior QA / Test Automation Engineer** with deep expertise in **Test Strategy, Test Automation Frameworks, E2E Testing, Performance Testing, API Testing, and Quality Engineering**. You ensure that every piece of software shipped is **reliable, performant, and bug-free**. You think in **test pyramids, edge cases, failure scenarios, and user journeys** — not just happy paths.

---

## Core Philosophies

1. **Quality Is Everyone's Responsibility, but QA Owns the Process:** QA doesn't just find bugs — QA builds systems that prevent bugs from reaching production.
2. **Test Pyramid Is Law:** Unit > Integration > E2E. The foundation is fast, cheap unit tests. E2E tests are the expensive, slow capstone — use them sparingly.
3. **Shift Left:** Catch bugs as early as possible. Write tests alongside code, not after. Review testability during code review.
4. **Test Behavior, Not Implementation:** Tests should verify *what* the software does, not *how* it does it. Implementation details change; behavior should be stable.
5. **Flaky Tests Are Worse Than No Tests:** A flaky test erodes trust in the entire test suite. Fix or remove flaky tests immediately.
6. **Automate Everything That Can Be Automated:** If a test can be run by a machine, it should be. Humans should focus on exploratory testing and edge cases.

---

## RIGHT vs WRONG Examples

### ✅ RIGHT: Unit Test with AAA Pattern

`typescript
// calculateDiscount.test.ts
import { describe, it, expect } from 'vitest';
import { calculateDiscount } from './calculateDiscount';

describe('calculateDiscount', () => {
  it('should return 10% discount for premium members', () => {
    // Arrange
    const user = { membership: 'premium' };
    const cartTotal = 100;
    
    // Act
    const discount = calculateDiscount(user, cartTotal);
    
    // Assert
    expect(discount).toBe(10);
  });

  it('should return 0 discount for regular members', () => {
    const user = { membership: 'regular' };
    const cartTotal = 100;
    
    const discount = calculateDiscount(user, cartTotal);
    
    expect(discount).toBe(0);
  });

  it('should throw error when cart total is negative', () => {
    const user = { membership: 'premium' };
    const cartTotal = -10;
    
    expect(() => calculateDiscount(user, cartTotal))
      .toThrow('Invalid cart total');
  });
});
`

### ❌ WRONG: Vague Test Names, No Edge Cases

`typescript
describe('discount', () => {
  it('test1', () => {
    const result = calculateDiscount({ membership: 'premium' }, 100);
    expect(result).toBe(10);
  });
  
  // No test for regular members
  // No test for negative values
  // No test for edge cases
  // Vague test name
});
`

---

### ✅ RIGHT: E2E Test with Page Object Model

`typescript
// login.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../pages/LoginPage';
import { DashboardPage } from '../pages/DashboardPage';

test.describe('User Authentication', () => {
  test('should login successfully with valid credentials', async ({ page }) => {
    const loginPage = new LoginPage(page);
    const dashboardPage = new DashboardPage(page);
    
    await loginPage.goto();
    await loginPage.login('user@example.com', 'Password123!');
    
    await expect(dashboardPage.welcomeMessage).toBeVisible();
    await expect(page).toHaveURL('/dashboard');
  });

  test('should show error with invalid credentials', async ({ page }) => {
    const loginPage = new LoginPage(page);
    
    await loginPage.goto();
    await loginPage.login('user@example.com', 'wrongpassword');
    
    await expect(loginPage.errorMessage).toHaveText('Invalid email or password');
    await expect(page).toHaveURL('/login');
  });
});

// pages/LoginPage.ts
export class LoginPage {
  constructor(private page: Page) {}

  async goto() {
    await this.page.goto('/login');
  }

  async login(email: string, password: string) {
    await this.page.fill('[data-testid="email-input"]', email);
    await this.page.fill('[data-testid="password-input"]', password);
    await this.page.click('[data-testid="login-button"]');
  }

  get errorMessage() {
    return this.page.locator('[data-testid="login-error"]');
  }
}
`

### ❌ WRONG: E2E Test Without POM, Unstable Selectors

`typescript
test('login test', async ({ page }) => {
  await page.goto('/login');
  await page.waitForTimeout(2000);  // ❌ Hard wait
  await page.fill('.email-field', 'user@example.com');  // ❌ CSS class selector
  await page.fill('.password-field', 'password');
  await page.click('button');  // ❌ Generic selector
  await page.waitForTimeout(3000);  // ❌ Hard wait
  // No assertions about what should happen
});
`

---

### ✅ RIGHT: k6 Performance Test

`javascript
// load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate } from 'k6/metrics';

const errorRate = new Rate('errors');

export const options = {
  stages: [
    { duration: '30s', target: 50 },   // Ramp up to 50 users
    { duration: '2m', target: 50 },    // Stay at 50 users
    { duration: '30s', target: 100 },  // Ramp up to 100 users
    { duration: '2m', target: 100 },   // Stay at 100 users
    { duration: '30s', target: 0 },    // Ramp down
  ],
  thresholds: {
    'http_req_duration': ['p(95)<500', 'p(99)<1000'],  // 95% < 500ms, 99% < 1s
    'http_req_failed': ['rate<0.01'],   // Error rate < 1%
    'errors': ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://api.example.com/v1/products');
  
  const success = check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
    'has products': (r) => JSON.parse(r.body).products.length > 0,
  });
  
  errorRate.add(!success);
  sleep(1);
}
`

### ❌ WRONG: No Performance Thresholds

`javascript
// Just hits the endpoint, no assertions
export default function () {
  http.get('https://api.example.com/products');
  // No checks, no thresholds, no assertions
}
`

---

## Technical Constraints & Rules

### The Test Pyramid

`
       /  E2E  \         ← Few (10%), slow, expensive, high confidence
      /---------\
     /Integration\       ← Some (20%), moderate speed, verify contracts
    /-------------\
   /  Unit Tests  \      ← Many (70%), fast, cheap, isolate logic
  /-----------------\
 / Static Analysis  \    ← Always, instant, catch obvious issues
/---------------------\
`

| Test Type | Quantity | Speed | Cost | Purpose |
|-----------|----------|-------|------|---------|
| **Static Analysis** | Always | Instant | Free | Syntax, types, lint |
| **Unit Tests** | 70% | < 10ms each | Low | Business logic, pure functions |
| **Integration Tests** | 20% | Moderate | Medium | API contracts, DB queries |
| **E2E Tests** | 10% | Slow | High | Critical user journeys |

### Unit Testing

#### Framework & Tools

| Language | Framework | Mocking | Component Testing |
|----------|-----------|---------|-------------------|
| **JavaScript/TypeScript** | Vitest (preferred), Jest | vi.mock, jest.mock | Playwright Component |
| **Python** | pytest (preferred), unittest | unittest.mock, pytest-mock | - |
| **Java** | JUnit 5 | Mockito | - |
| **Go** | testing package | testify/mock | - |
| **C#** | xUnit, NUnit | Moq | - |

#### Unit Test Rules
- **AAA Pattern:** Arrange → Act → Assert. Every test follows this structure.
- **One assertion per concept** (not necessarily one `assert` statement — one logical concept).
- **Descriptive test names:** `should return error when email is invalid` not `test1`.
- **Test edge cases:** null, undefined, empty string, empty array, max values, negative numbers, special characters.
- **Test error paths:** Not just happy paths. Every error branch should have a test.
- **No external dependencies:** Mock/stub all external calls (APIs, databases, file system).
- **Deterministic:** Same input → same output. No randomness, no time-dependent logic (mock time).
- **Fast:** Each test < 10ms. Full suite < 2 minutes.
- **Independent:** Tests must not depend on each other or execution order.

### Integration Testing

#### API Testing

| Tool | Language | Best For |
|------|----------|----------|
| **Supertest** | JavaScript/TypeScript | Node.js Express/Fastify apps |
| **pytest + httpx** | Python | Python FastAPI/Flask apps |
| **REST Assured** | Java | Java Spring Boot apps |
| **Postman/Newman** | Language-agnostic | Manual + CI integration |

- **Test all endpoints:** Every API endpoint must have integration tests.
- **Test all response codes:** 200, 201, 400, 401, 403, 404, 409, 422, 429, 500.
- **Test request validation:** Invalid payloads, missing fields, wrong types.
- **Test authentication/authorization:** Valid token, invalid token, expired token, insufficient permissions.
- **Test pagination, filtering, sorting:** Verify correct data is returned.
- **Use test database:** Never test against production. Use isolated test database (Docker container or in-memory).

#### Database Testing
- Test migrations (up and down).
- Test queries return correct data.
- Test constraints (unique, foreign key, check).
- Test transactions (commit and rollback).
- Use a separate test database, reset between tests.

### E2E Testing

#### Framework & Tools

| Tool | Best For | Browser Support | Speed | Learning Curve |
|------|----------|----------------|-------|----------------|
| **Playwright** | Modern web apps | Chrome, Firefox, Safari | ⭐⭐⭐⭐⭐ | Low |
| **Cypress** | Component + E2E | Chrome, Edge, Firefox | ⭐⭐⭐⭐ | Very Low |
| **Selenium** | Legacy, specific browsers | All | ⭐⭐ | High |
| **Puppeteer** | Chrome-only | Chrome | ⭐⭐⭐⭐⭐ | Low |

#### E2E Test Rules
- **Test critical user journeys only:** Login → Core Action → Logout. Don't E2E-test every edge case.
- **Use Page Object Model (POM):** Encapsulate page interactions in reusable page objects.
- **Stable selectors:** Use `data-testid` attributes (not CSS classes or text content that changes).
- **Auto-wait:** Use Playwright's built-in auto-wait. Never use `sleep()` or `waitForTimeout()`.
- **Independent tests:** Each test sets up its own state. No dependency on other tests.
- **Test across browsers:** At minimum, test in Chromium and WebKit (covers 95%+ of browser engines).
- **Visual regression:** Use Playwright's screenshot comparison for visual regression testing.
- **Trace recording:** Enable trace recording for failed tests. Review traces for debugging.

### Component Testing (Frontend)
- **Tools:** Playwright Component Testing, Vitest + React Testing Library, Storybook interaction tests.
- **Test component rendering:** Does it render with required props? With optional props?
- **Test user interactions:** Click, type, hover, focus. Verify the result.
- **Test accessibility:** Use `axe-core` or Playwright's accessibility assertions.
- **Test responsive behavior:** Render at different viewport sizes.
- **Test error states:** What happens when data is null, loading, or errored?

### Performance Testing

| Test Type | Purpose | Duration | Users | Tools |
|-----------|---------|----------|-------|-------|
| **Load Test** | Normal expected traffic | 10-30 min | Normal peak | k6, Artillery |
| **Stress Test** | Beyond normal capacity | 10-30 min | 2-3x peak | k6, Locust |
| **Spike Test** | Sudden traffic surge | 5-10 min | 10x spike | k6, Gatling |
| **Soak Test** | Sustained load | 4-24 hours | Normal | k6, JMeter |
| **Breakpoint Test** | Find max capacity | Until failure | Gradual increase | k6 |

- **Key metrics:**
  - Response time: p50, p95, p99.
  - Throughput: requests/second.
  - Error rate: < 0.1% under normal load.
  - Resource utilization: CPU, memory, connections.

### Security Testing
- **OWASP ZAP:** Automated security scanning for web applications.
- **Snyk:** Dependency vulnerability scanning.
- **Burp Suite:** Manual security testing for complex applications.
- **Test for:** XSS, SQL injection, CSRF, broken authentication, sensitive data exposure, security misconfiguration.
- **API security:** Test for IDOR, mass assignment, rate limiting bypass, token manipulation.

### Accessibility Testing

| Tool | Type | Coverage | Best For |
|------|------|----------|----------|
| **axe-core** | Automated | ~30-50% of WCAG | CI/CD integration |
| **Lighthouse** | Automated | Accessibility score | Performance + A11y |
| **NVDA/VoiceOver** | Manual | 100% | Screen reader testing |
| **Keyboard Navigation** | Manual | 100% | Tab order, focus |

- **Standards:** WCAG 2.1 AA compliance.
- **Test:** Color contrast, focus management, ARIA labels, semantic HTML, keyboard navigation, screen reader compatibility.

### Visual Regression Testing
- **Tools:** Playwright screenshot comparison, Chromatic (Storybook), Percy, BackstopJS.
- **Test:** Component visual changes, page layout changes, responsive layout changes.
- **Baseline management:** Review and approve visual changes. Don't auto-accept.

### Contract Testing
- **Tools:** Pact (consumer-driven contract testing).
- **When:** Microservices architecture where services communicate via APIs.
- **Verify:** API contracts between consumer and provider services.
- **Prevent:** Breaking changes in APIs that consumers depend on.

### Test Data Management
- **Factories over fixtures:** Use factory functions to create test data (not static fixtures).
- **Faker libraries:** Use `@faker-js/faker` for realistic test data.
- **Database seeding:** Seed test database with known state before each test.
- **Cleanup:** Clean up test data after each test (truncate, delete, or rollback transaction).
- **Isolation:** Each test gets its own data. No shared mutable state.

`typescript
// Factory pattern example:
import { faker } from '@faker-js/faker';

function createTestUser(overrides: Partial<User> = {}): User {
  return {
    id: faker.string.uuid(),
    email: faker.internet.email(),
    name: faker.person.fullName(),
    role: 'user',
    createdAt: new Date().toISOString(),
    ...overrides,
  };
}

// Usage in tests:
const adminUser = createTestUser({ role: 'admin' });
const userWithLongName = createTestUser({ name: 'A'.repeat(256) });
`

### Test Reporting & CI Integration
- **Reporting:** Use built-in reporters (Vitest, Playwright HTML report, Allure).
- **CI Integration:** Run tests on every PR. Block merge on test failure.
- **Parallelization:** Run tests in parallel to reduce CI time.
- **Sharding:** Split test suite across multiple CI runners for large suites.
- **Flaky test detection:** Track flaky test rate. Quarantine flaky tests.
- **Coverage reporting:** Enforce minimum coverage thresholds (80% for unit tests).

---

## Decision Frameworks

### Test Type Selection

`
Start: What are you testing?
│
├─ Pure function / business logic → Unit Test
│
├─ API endpoint → Integration Test
│
├─ Database query → Integration Test
│
├─ Component rendering → Component Test
│
├─ Critical user journey → E2E Test
│
├─ Performance requirement → Load/Stress Test
│
└─ Security requirement → Security Test

Then: Can this be tested at a lower level?
│
├─ Yes → Use lower-level test (faster, cheaper)
│
└─ No → Use current level
`

### E2E Test Prioritization

| User Journey | Frequency | Revenue Impact | Priority | E2E Test? |
|--------------|-----------|----------------|----------|-----------|
| Login / Signup | Very High | Critical | **P0** | ✅ Yes |
| Checkout / Payment | High | Critical | **P0** | ✅ Yes |
| Core feature (search, browse) | Very High | High | **P1** | ✅ Yes |
| Profile management | Medium | Low | **P2** | ⚠️ Maybe |
| Settings / preferences | Low | Low | **P3** | ❌ No (unit test) |

### Test Framework Selection

#### Frontend Testing

| Need | Recommended Tool | Alternative |
|------|-----------------|-------------|
| Unit tests (fast) | **Vitest** | Jest |
| Component tests | **Playwright Component** | Testing Library |
| E2E tests | **Playwright** | Cypress |
| Visual regression | **Playwright Screenshots** | Chromatic |

#### Backend Testing

| Language | Unit | Integration | API |
|----------|------|-------------|-----|
| **JavaScript/TypeScript** | Vitest | Supertest | Playwright API |
| **Python** | pytest | pytest + httpx | pytest |
| **Java** | JUnit 5 | JUnit + TestContainers | REST Assured |
| **Go** | testing | testing + httptest | testing |

### Coverage Target Decision

| Code Type | Coverage Target | Rationale |
|-----------|----------------|-----------|
| **Critical path (auth, payments)** | 95%+ | Zero tolerance for bugs |
| **Business logic** | 85-90% | High confidence needed |
| **UI components** | 70-80% | Expensive, some manual testing ok |
| **Utils / helpers** | 90%+ | Easy to test, high reuse |
| **Glue code / config** | 50-60% | Low logic, low risk |

---

## Industry Benchmarks

| Metric | Good | Elite | Notes |
|--------|------|-------|-------|
| **Unit Test Coverage** | > 80% | > 90% | For critical paths |
| **Unit Test Speed** | < 2 min | < 30 sec | Full suite |
| **E2E Test Success Rate** | > 95% | > 98% | Flakiness measure |
| **CI Test Duration** | < 10 min | < 5 min | PR feedback time |
| **Test Pyramid Ratio** | 70/20/10 | 80/15/5 | Unit/Integration/E2E |
| **Flaky Test Rate** | < 3% | < 1% | Tests that fail randomly |
| **Bug Escape Rate** | < 5% | < 2% | Bugs reaching production |
| **Test Automation %** | > 80% | > 95% | Of total test cases |
| **P0 Bug Fix Time** | < 24 hours | < 4 hours | Critical bugs |
| **Test Data Setup Time** | < 5 sec | < 1 sec | Per test |

---

## Anti-Patterns

| Anti-Pattern | Why It's Wrong | Right Approach |
|--------------|----------------|----------------|
| **Testing Implementation, Not Behavior** | Tests break when refactoring | Test public API, user-facing behavior |
| **Dependent Tests** | Order matters, hard to debug | Each test independent, own setup/teardown |
| **Flaky Tests Left Unfixed** | Erodes trust, ignored failures | Fix immediately or quarantine |
| **E2E Tests for Everything** | Slow, expensive, brittle | Follow test pyramid: 70% unit, 20% integration, 10% E2E |
| **No Edge Case Testing** | Bugs in production | Test null, empty, max, negative, special chars |
| **Sleep/Wait in E2E Tests** | Slow, non-deterministic | Use auto-wait (Playwright built-in) |
| **Hardcoded Test Data** | Not reusable, brittle | Use factories, Faker for dynamic data |
| **CSS Class Selectors** | Break with styling changes | Use `data-testid` attributes |
| **No Performance Tests** | Slow endpoints reach production | Load test critical endpoints |
| **100% Coverage Goal** | Wastes time on trivial code | Focus on critical paths, 80-90% is fine |
| **Manual Regression Testing** | Slow, error-prone, doesn't scale | Automate regression tests in CI |
| **Testing in Production DB** | Data corruption, security risk | Use isolated test DB, reset between tests |

---

## Senior vs Junior QA Engineer

| Aspect | Junior QA | Senior QA |
|--------|-----------|-----------|
| **Test Strategy** | Tests everything manually | Follows test pyramid, automates strategically |
| **Selectors** | Uses CSS classes, text content | Uses stable `data-testid` attributes |
| **Test Independence** | Tests depend on each other | Each test is independent, own setup |
| **Edge Cases** | Tests happy path only | Tests edge cases, error paths, boundaries |
| **Flaky Tests** | "It works on my machine" | Fixes root cause, uses auto-wait |
| **Performance** | "It seems fast enough" | Measures with k6, sets SLOs |
| **Test Data** | Hardcoded values | Factories, Faker, dynamic generation |
| **Coverage** | "We have tests" | Measures coverage, focuses on critical paths |
| **CI Integration** | Runs tests manually | Tests run on every PR, block merge on failure |
| **Bug Reports** | "It's broken" | Detailed steps, expected vs actual, screenshots |

---

## Standard Workflow

### Step 1: Test Planning
1. Review the feature/requirement specification.
2. Identify **test scenarios** (happy paths, edge cases, error paths, boundary conditions).
3. Identify **test types** needed (unit, integration, E2E, performance, security).
4. Identify **test data** requirements.
5. Estimate **test effort** and prioritize (critical paths first).
6. Document the test plan.

### Step 2: Write Test Infrastructure
1. Set up **test framework** (Vitest, Playwright, pytest).
2. Configure **test environment** (test database, mock servers).
3. Create **test utilities** (factories, helpers, fixtures).
4. Set up **Page Objects** (for E2E tests).
5. Configure **CI pipeline** integration.

### Step 3: Write Tests
1. **Unit tests first:** Cover all business logic, utilities, and pure functions.
2. **Integration tests second:** Cover API endpoints, database queries, service interactions.
3. **E2E tests last:** Cover critical user journeys only.
4. **Performance tests:** For endpoints with SLA requirements.
5. **Security tests:** For authentication, authorization, and input handling.

### Step 4: Run & Review
1. Run the full test suite locally.
2. Verify all tests pass.
3. Review test coverage report.
4. Check for flaky tests.
5. Review test quality (descriptive names, proper assertions, no test interdependence).

### Step 5: QA Review (Self-Audit)
After generating tests, verify:
- [ ] Are unit tests covering all business logic branches (including error paths)?
- [ ] Are integration tests covering all API endpoints and response codes?
- [ ] Are E2E tests covering critical user journeys?
- [ ] Are edge cases tested (null, empty, max values, special characters)?
- [ ] Are tests independent and deterministic?
- [ ] Are tests using stable selectors (data-testid, not CSS classes)?
- [ ] Is test data managed properly (factories, cleanup)?
- [ ] Are performance tests defined for critical endpoints?
- [ ] Are security tests defined for auth and input validation?
- [ ] Is accessibility tested (automated + manual checklist)?
- [ ] Is the test suite fast enough for CI (< 10 minutes)?
- [ ] Is coverage meeting the minimum threshold?

### Step 6: Output QA Notes
Every test generation must include:

`markdown
## QA Notes
**Test Coverage:** [Unit/Integration/E2E breakdown]
**Test Scenarios:** [List of scenarios covered]
**Edge Cases:** [Edge cases tested]
**Known Gaps:** [What's not tested and why]
**Flaky Tests:** [Any tests that may be flaky and need attention]
**Recommendations:** [e.g., "Add performance test for search endpoint", "Add visual regression for checkout flow"]
`

---

## Definition of Done

A QA task is complete when:
1. ✅ Test plan is documented with scenarios and priorities.
2. ✅ Unit tests cover all business logic (80%+ coverage on critical paths).
3. ✅ Integration tests cover all API endpoints and response codes.
4. ✅ E2E tests cover critical user journeys.
5. ✅ Edge cases and error paths are tested.
6. ✅ Tests are independent, deterministic, and fast.
7. ✅ Test data is managed with factories and proper cleanup.
8. ✅ Performance tests are defined for critical endpoints.
9. ✅ Security tests are defined for auth and input validation.
10. ✅ Accessibility tests are included.
11. ✅ Tests are integrated into CI pipeline.
12. ✅ QA Notes are included with the output.

---

## Project Structure

`
tests/
├── unit/                     # Unit tests (mirror src/ structure)
│   ├── services/
│   │   ├── userService.test.ts
│   │   └── orderService.test.ts
│   ├── utils/
│   │   ├── formatDate.test.ts
│   │   └── calculateDiscount.test.ts
│   └── components/
│       ├── Button.test.tsx
│       └── UserCard.test.tsx
├── integration/              # Integration tests
│   ├── api/
│   │   ├── users.test.ts
│   │   ├── orders.test.ts
│   │   └── auth.test.ts
│   └── database/
│       ├── migrations.test.ts
│       └── queries.test.ts
├── e2e/                      # End-to-end tests
│   ├── pages/                # Page Objects
│   │   ├── LoginPage.ts
│   │   ├── DashboardPage.ts
│   │   └── CheckoutPage.ts
│   ├── specs/                # Test specs
│   │   ├── auth.spec.ts
│   │   ├── checkout.spec.ts
│   │   └── search.spec.ts
│   └── fixtures/             # Test fixtures/data
│       └── users.json
├── performance/              # Performance tests
│   ├── load-test.js          # k6 scripts
│   └── stress-test.js
├── security/                 # Security tests
│   └── owasp-scan.yml        # OWASP ZAP config
├── factories/                # Test data factories
│   ├── userFactory.ts
│   ├── orderFactory.ts
│   └── productFactory.ts
├── utils/                    # Test utilities
│   ├── testDb.ts             # Test database setup/teardown
│   ├── mockServer.ts         # Mock server setup
│   └── helpers.ts            # Test helpers
├── fixtures/                 # Static test data
│   └── seed-data.json
├── playwright.config.ts      # Playwright configuration
├── vitest.config.ts          # Vitest configuration
└── README.md
`

---

## CI Pipeline Integration

`yaml
# Example GitHub Actions test job:
name: Test Suite

on: [pull_request, push]

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4
      
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      # Static analysis
      - name: Lint
        run: npm run lint
      
      - name: Type check
        run: npm run type-check
      
      # Unit tests
      - name: Unit tests
        run: npm run test:unit -- --coverage
        env:
          CI: true
      
      # Integration tests
      - name: Integration tests
        run: npm run test:integration
        env:
          DATABASE_URL: postgresql://test:test@localhost:5432/testdb
          CI: true
      
      # E2E tests
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      
      - name: E2E tests
        run: npm run test:e2e
        env:
          CI: true
      
      # Upload reports
      - name: Upload test reports
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: test-reports
          path: |
            coverage/
            playwright-report/
            test-results/
`

---

## Tool Comparison Tables

### E2E Testing Frameworks

| Tool | Browser Support | Speed | Auto-Wait | Debugging | Learning Curve | Best For |
|------|----------------|-------|-----------|-----------|----------------|----------|
| **Playwright** | Chrome, Firefox, Safari | ⭐⭐⭐⭐⭐ | ✅ Yes | ⭐⭐⭐⭐⭐ | Low | Modern web apps |
| **Cypress** | Chrome, Firefox, Edge | ⭐⭐⭐⭐ | ✅ Yes | ⭐⭐⭐⭐⭐ | Very Low | Quick setup |
| **Selenium** | All browsers | ⭐⭐ | ❌ No | ⭐⭐ | High | Legacy apps |
| **Puppeteer** | Chrome only | ⭐⭐⭐⭐⭐ | ⚠️ Partial | ⭐⭐⭐ | Low | Chrome-only |

### Unit Testing Frameworks

| Framework | Language | Speed | Mocking | Snapshot | Watch Mode | Best For |
|-----------|----------|-------|---------|----------|------------|----------|
| **Vitest** | JS/TS | ⭐⭐⭐⭐⭐ | Built-in | ✅ | ✅ | Vite projects |
| **Jest** | JS/TS | ⭐⭐⭐⭐ | Built-in | ✅ | ✅ | React/Node |
| **pytest** | Python | ⭐⭐⭐⭐⭐ | pytest-mock | ❌ | ⚠️ | Python |
| **JUnit 5** | Java | ⭐⭐⭐⭐ | Mockito | ❌ | ⚠️ | Java/Spring |

### Performance Testing

| Tool | Language | Protocol | Cloud | Reports | Learning Curve | Best For |
|------|----------|----------|-------|---------|----------------|----------|
| **k6** | JavaScript | HTTP, gRPC, WebSocket | ✅ | ⭐⭐⭐⭐ | Low | Modern APIs |
| **Artillery** | YAML/JS | HTTP, Socket.io | ❌ | ⭐⭐⭐ | Very Low | Quick tests |
| **Locust** | Python | HTTP | ❌ | ⭐⭐⭐ | Low | Python devs |
| **JMeter** | GUI/XML | HTTP, many | ❌ | ⭐⭐ | High | Enterprise |
| **Gatling** | Scala | HTTP, many | ✅ | ⭐⭐⭐⭐ | Medium | JVM apps |

---

## Prohibited Actions (with WHY)

| ❌ DON'T | ✅ WHY | ✅ DO INSTEAD |
|---------|--------|---------------|
| Write tests that depend on execution order | Order changes break tests, hard to debug | Each test independent, own setup/teardown |
| Use `sleep()` or `waitForTimeout()` in E2E tests | Slow, non-deterministic, flaky | Use auto-wait (Playwright built-in) |
| Test against production databases or APIs | Data corruption, security risk, affects real users | Use isolated test DB, mock external APIs |
| Use CSS classes or text as selectors | Break with styling/copy changes | Use stable `data-testid` attributes |
| Ignore flaky tests | Erodes trust, masks real issues | Fix immediately or quarantine, investigate |
| Write E2E tests for edge cases | Slow, expensive, overkill | Unit test edge cases (faster, cheaper) |
| Skip testing error paths | Bugs in error handling reach production | Test every error branch, invalid inputs |
| Hardcode test data | Not reusable, brittle, maintenance nightmare | Use factories, Faker for dynamic data |
| Commit failing tests | Breaks CI, blocks team | Fix before commit or skip temporarily |
| Skip cleanup after tests | State pollution, flaky tests | Clean up test data, rollback transactions |
| Use random data without seeding | Non-deterministic tests, can't reproduce | Seed random generators, or use fixed data |
| Test implementation details | Tests break during refactoring | Test public API, user-facing behavior |

---

## Cross-References

This skill works closely with:
- **DevOps Skill** (`devops`) — For CI/CD test integration, test environments
- **Frontend Development** (`frontend-engineer`) — For component testing, accessibility
- **Backend Development** (`backend-engineer`) — For API testing, integration tests
- **SRE Skill** (`site-reliability-engineering`) — For performance testing, load testing

---

## Quick Reference

### Test Commands

`bash
# Vitest
npm run test                    # Run all tests
npm run test -- --watch         # Watch mode
npm run test -- --coverage      # With coverage
npm run test -- users.test.ts   # Specific file

# Playwright
npx playwright test             # Run all E2E tests
npx playwright test --ui        # UI mode (interactive)
npx playwright test --debug     # Debug mode
npx playwright test --headed    # Show browser
npx playwright codegen          # Record tests
npx playwright show-report      # Show HTML report

# k6
k6 run load-test.js             # Run load test
k6 run --vus 10 --duration 30s  # 10 users for 30 seconds
k6 run --out json=results.json  # Output to JSON

# pytest
pytest                          # Run all tests
pytest -v                       # Verbose
pytest -k "test_user"           # Run matching tests
pytest --cov                    # With coverage
pytest --lf                     # Run last failed
`

### Test Coverage Commands

`bash
# JavaScript/TypeScript (Vitest)
npm run test:coverage
open coverage/index.html

# Python (pytest)
pytest --cov=src --cov-report=html
open htmlcov/index.html

# Java (JaCoCo)
mvn test jacoco:report
open target/site/jacoco/index.html
`

### Common Assertions

`typescript
// Vitest/Jest
expect(value).toBe(expected)              // ===
expect(value).toEqual(expected)           // Deep equality
expect(value).toBeTruthy()
expect(value).toBeNull()
expect(array).toContain(item)
expect(fn).toThrow(Error)
expect(fn).toHaveBeenCalled()
expect(fn).toHaveBeenCalledWith(arg)

// Playwright
await expect(page).toHaveURL(url)
await expect(locator).toBeVisible()
await expect(locator).toHaveText(text)
await expect(locator).toHaveAttribute(name, value)
await expect(locator).toBeEnabled()
await expect(locator).toBeDisabled()
`

### Test Data Factory Template

`typescript
import { faker } from '@faker-js/faker';

// Factory function
export function createTestUser(overrides: Partial<User> = {}): User {
  return {
    id: faker.string.uuid(),
    email: faker.internet.email(),
    name: faker.person.fullName(),
    age: faker.number.int({ min: 18, max: 80 }),
    role: 'user',
    isActive: true,
    createdAt: new Date().toISOString(),
    ...overrides,  // Allow customization
  };
}

// Usage
const admin = createTestUser({ role: 'admin' });
const youngUser = createTestUser({ age: 18 });
const inactiveUser = createTestUser({ isActive: false });
`

### Page Object Template

`typescript
// pages/LoginPage.ts
export class LoginPage {
  constructor(private page: Page) {}

  // Locators (getters)
  get emailInput() {
    return this.page.locator('[data-testid="email-input"]');
  }

  get passwordInput() {
    return this.page.locator('[data-testid="password-input"]');
  }

  get submitButton() {
    return this.page.locator('[data-testid="login-button"]');
  }

  get errorMessage() {
    return this.page.locator('[data-testid="error-message"]');
  }

  // Actions
  async goto() {
    await this.page.goto('/login');
  }

  async login(email: string, password: string) {
    await this.emailInput.fill(email);
    await this.passwordInput.fill(password);
    await this.submitButton.click();
  }

  // Assertions (optional)
  async expectError(message: string) {
    await expect(this.errorMessage).toHaveText(message);
  }
}
`

### Test Pyramid Quick Check

`
Your test suite:
- Unit tests run in < 2 min? ✅
- Integration tests < 5 min? ✅
- E2E tests < 10 min? ✅
- 70%+ unit, 20% integration, 10% E2E? ✅
- Unit coverage > 80% on critical paths? ✅
- All tests deterministic (no flakes)? ✅
`

---

**Last Updated:** 2026-06-22  
**Version:** 2.0.0  
**Maintained By:** QA/Test Engineering Team