Ultimate Senior QA

A production-grade skill for senior QA engineers covering test strategy design, automation frameworks, performance testing, security testing, and quality metrics. Builds comprehensive testing practices that catch bugs before users do.

When to Use This Skill

Choose this skill when:

• Designing end-to-end test strategies for complex applications
• Setting up test automation frameworks with Playwright, Cypress, or Selenium
• Implementing performance testing with load, stress, and soak tests
• Building CI/CD quality gates with coverage thresholds and mutation testing
• Establishing QA processes, test plans, and defect triage workflows

Consider alternatives when:

• Writing unit tests for a specific framework → use that framework's testing skill
• Need API testing only → use an API testing skill
• Working on security penetration testing → use a security testing skill
• Setting up monitoring and alerting → use a DevOps skill

Quick Start

Copy
// Test strategy definition
const testStrategy = {
  pyramid: {
    unit:        { ratio: '70%', speed: 'ms',  runner: 'Jest/Vitest' },
    integration: { ratio: '20%', speed: 'sec', runner: 'Supertest/Playwright' },
    e2e:         { ratio: '10%', speed: 'min', runner: 'Playwright' },
  },
  qualityGates: {
    coverage: { line: 80, branch: 75, function: 85 },
    performance: { lcp: 2500, fid: 100, cls: 0.1 },
    security: { critical: 0, high: 0, medium: 'review' },
  },
};

Copy
# Run test suite with coverage and reporting
npm test -- --coverage --reporter=junit
npx playwright test --reporter=html
npx artillery run load-test.yml --output report.json

Core Concepts

Test Strategy Matrix

Test Type	Scope	Speed	Reliability	Catches
Unit	Single function/class	ms	Very high	Logic errors, edge cases
Integration	Component interactions	sec	High	Interface mismatches, data flow
E2E	Full user workflows	min	Medium	UX bugs, broken flows
Performance	System under load	min	Medium	Bottlenecks, memory leaks
Security	Attack surface	min	High	Vulnerabilities, misconfigs
Accessibility	UI compliance	sec	High	WCAG violations

Test Data Management

Copy
// Factory pattern for test data
class UserFactory {
  static defaults = {
    name: 'Test User',
    email: '[email protected]',
    role: 'viewer',
    status: 'active',
  };

  static create(overrides: Partial<User> = {}): User {
    return {
      id: crypto.randomUUID(),
      ...this.defaults,
      ...overrides,
      email: overrides.email || `test-${Date.now()}@example.com`,
      createdAt: new Date(),
    };
  }

  static createBatch(count: number, overrides: Partial<User> = {}): User[] {
    return Array.from({ length: count }, (_, i) =>
      this.create({ ...overrides, name: `User ${i + 1}` })
    );
  }
}

// Seeded test database
async function seedTestDB(db: Database) {
  const admin = UserFactory.create({ role: 'admin', email: '[email protected]' });
  const users = UserFactory.createBatch(10);
  await db.users.insertMany([admin, ...users]);
  return { admin, users };
}

Performance Testing Configuration

Copy
# Artillery load test configuration
config:
  target: "https://api.example.com"
  phases:
    - name: "Warm up"
      duration: 60
      arrivalRate: 5
    - name: "Ramp up"
      duration: 120
      arrivalRate: 5
      rampTo: 50
    - name: "Sustained load"
      duration: 300
      arrivalRate: 50
    - name: "Spike"
      duration: 30
      arrivalRate: 200
  ensure:
    p99: 500    # p99 latency under 500ms
    maxErrorRate: 1  # less than 1% errors

scenarios:
  - name: "Browse and search"
    weight: 70
    flow:
      - get:
          url: "/api/products"
      - think: 2
      - get:
          url: "/api/products/search?q=laptop"
  - name: "Purchase flow"
    weight: 30
    flow:
      - post:
          url: "/api/cart"
          json: { productId: "{{ $randomString() }}", quantity: 1 }
      - post:
          url: "/api/checkout"

Configuration

Parameter	Type	Default	Description
coverageThreshold	number	80	Minimum code coverage percentage
e2eParallelism	number	4	Parallel browser instances for E2E tests
performanceBaseline	string	'p99<500ms'	Performance SLA threshold
flakyTestRetries	number	2	Retry count for flaky test detection
testDataStrategy	string	'factory'	Data strategy: factory, fixture, or snapshot
mutationThreshold	number	70	Minimum mutation testing score

Best Practices

1. Follow the test pyramid: most unit tests, fewer integration tests, fewest E2E tests — Unit tests are fast, reliable, and cheap to maintain. E2E tests are slow, flaky, and expensive. Invest in fast feedback loops at the bottom of the pyramid.

2. Treat test code with the same standards as production code — Refactor test helpers, maintain factories, and remove duplication. Poorly written tests become a maintenance burden that teams abandon rather than fix.

3. Quarantine flaky tests immediately — A flaky test that stays in the main suite erodes trust in the entire test suite. Move it to a quarantine suite, investigate the root cause, fix it, and return it to the main suite.

4. Measure mutation testing score, not just coverage — 100% line coverage means nothing if tests don't assert behavior. Mutation testing modifies code and checks whether tests catch the change. A high mutation score means tests actually verify correctness.

5. Shift security and performance testing left — Run lightweight security scans and performance benchmarks in CI, not just before releases. Catching a SQL injection vulnerability in a PR review is 100x cheaper than finding it in production.

Common Issues

E2E tests are flaky due to timing issues — Replace sleep() calls with explicit waits for conditions (waitForSelector, waitForResponse). Use test-specific IDs (data-testid) instead of CSS selectors. Ensure test isolation by resetting state between tests.

Test suite takes too long, developers skip it — Parallelize tests, split the suite into fast (unit) and slow (E2E) tiers, and run only affected tests on PRs. The full suite runs on merge to main. A 30-minute test suite that nobody runs provides zero value.

Test data conflicts between parallel test runs — Each test run should use isolated data. Use factories with unique IDs, transactional test databases that rollback after each test, or per-run database schemas. Shared mutable state between tests is the primary source of flakiness.