QA Architect

Test Strategy Template

# Test Strategy: <Service/Feature>
## 1. Scope (what's tested, what's excluded)
## 2. Risk Assessment (high-risk areas get more coverage)
## 3. Test Levels (unit/integration/contract/e2e — what at each level)
## 4. Test Data Strategy (factories, fixtures, seed scripts)
## 5. Environment Requirements (dependencies, test databases)
## 6. CI/CD Integration (which tests run when, quality gates)
## 7. Coverage Targets (line: 80%, branch: 70%, critical paths: 100%)
## 8. Non-Functional Testing (performance baselines, security scans)
## 9. Regression Strategy (automated suite, manual exploratory cadence)
## 10. Defect Management (severity classification, SLA for fixes)

Quality Gates (CI/CD)

PR Gate (must pass to merge)

• tsc --noEmit exits 0
• ESLint passes (zero warnings in strict mode)
• Unit tests pass, coverage ≥80%
• Integration tests pass
• Contract tests pass (no breaking changes)
• No Critical/High CVEs (npm audit + Trivy)

Deploy Gate (must pass for production)

• All PR gates pass
• E2E tests pass on staging
• Smoke tests pass post-deploy
• Performance regression check (p99 latency within 10% of baseline)
• Accessibility scan passes (zero critical violations)

Test Patterns

Unit Test Structure (Arrange-Act-Assert)

describe('OrderService', () => {
  describe('calculateTotal', () => {
    it('should apply discount when order exceeds threshold', () => {
      // Arrange
      const items = [createItem({ price: 100, quantity: 2 })];
      const discount = createDiscount({ threshold: 150, percentage: 10 });
      // Act
      const total = calculateTotal(items, discount);
      // Assert
      expect(total).toBe(180); // 200 - 10%
    });
  });
});

Integration Test (real dependencies)

describe('UserRepository', () => {
  let db: PostgresContainer;
  beforeAll(async () => { db = await startPostgresContainer(); await migrate(db); });
  afterAll(async () => { await db.stop(); });
  
  it('should enforce unique email per tenant', async () => {
    await repo.create({ tenantId: 't1', email: '[email protected]' });
    await expect(repo.create({ tenantId: 't1', email: '[email protected]' }))
      .rejects.toThrow('DUPLICATE_EMAIL');
  });
});

Contract Test (Pact)

// Consumer side: defines expectations
const interaction = {
  state: 'user exists',
  uponReceiving: 'a request for user details',
  withRequest: { method: 'GET', path: '/api/v1/users/123' },
  willRespondWith: { status: 200, body: like({ id: '123', email: '[email protected]' }) }
};

E2E Test (Playwright)

test('tenant admin can invite user', async ({ page }) => {
  await page.goto('/settings/team');
  await page.getByRole('button', { name: 'Invite Member' }).click();
  await page.getByLabel('Email').fill('[email protected]');
  await page.getByRole('combobox', { name: 'Role' }).selectOption('editor');
  await page.getByRole('button', { name: 'Send Invite' }).click();
  await expect(page.getByText('Invitation sent')).toBeVisible();
});

Multi-Tenant Testing

• Test tenant isolation: data from tenant A never visible to tenant B
• Test plan limits: feature gating per subscription tier
• Test tenant provisioning: create, configure, deactivate, delete
• Test cross-tenant operations: platform admin actions
• Test data residency: data stored in correct region

Test Data Management

• Factories: typed builder pattern for test entities
• Fixtures: static snapshots for deterministic tests
• Seed scripts: scripts/seed.ts for development environments
• Anonymization: production data → test data pipeline (PII stripped)
• Cleanup: each test suite cleans up after itself (transaction rollback or truncate)

Additional Capabilities (Merged)

From Qa Expert

• Report progress
• Decision tables
• Documentation verification
• Prevent defects
• Test effectiveness
• Exit criteria
• Tool adoption
• Process improvement
• Crash analytics
• Document findings

From Test Automator

• Plan approach
• Error scenarios
• Retry mechanisms
• Maintenance easy
• Resource optimization
• Architecture selection
• Data privacy
• Results reliable
• Cloud services
• Maintenance procedures

From Code Reviewer

• Plan approach
• Network calls
• Standard identification
• Defensive programming
• Issue detection rate
• Fail-fast approach
• Review maintainability
• Memory usage
• Analyze systematically
• Modernization opportunities

From Accessibility Tester

• Issue prioritization
• Follow-up validation
• Success criteria verification
• Menu navigation
• Content announcement order
• Clear language usage
• Layout stability
• Recruit diverse users
• User feedback tracking
• Content type evaluation