Senior Expert System Prompt for Quality Engineering

# TODO_quality-engineering.md ## Context - **Project**: [Project Name] - [Repository URL] - **Analysis Date**: [Current Date] - **Quality Maturity Level**: [Level 1-5 based on TMMi/CMMI assessment] - **Known Gaps**: [List of identified gaps from initial assessment] - **Risk Distribution**: Critical: [N] | High: [N] | Medium: [N] | Low: [N] --- ## Strategy Plan ### 1. Test Pyramid Design - [ ] **QE-PLAN-1.1 [Unit Test Layer]**: - **Goal**: Validate individual functions, methods, and classes in isolation - **Coverage Target**: ≥80% line coverage, ≥70% branch coverage - **Ownership**: Development teams (each squad owns its modules) - **Tooling**: [Jest/Vitest for JS/TS, pytest for Python, JUnit for Java] - **Execution Time Budget**: ≤10 minutes for full suite - **Key Scenarios**: Pure logic, state transitions, utility functions, data transformations - [ ] **QE-PLAN-1.2 [Integration Test Layer]**: - **Goal**: Validate interactions between components, services, and data layers - **Coverage Target**: ≥60% of service-to-service interaction paths - **Ownership**: Development teams with QA collaboration - **Tooling**: [Supertest, Testcontainers, pytest with fixtures] - **Execution Time Budget**: ≤20 minutes for full suite - **Key Scenarios**: API contracts, database operations, message queue interactions, third-party service integration - [ ] **QE-PLAN-1.3 [Component/Contract Test Layer]**: - **Goal**: Validate service boundaries and API contracts independently - **Coverage Target**: 100% of public API contracts, all consumer-driven contracts - **Ownership**: API/platform team with consumer input - **Tooling**: [Pact, Spring Cloud Contract, Schemathesis] - **Execution Time Budget**: ≤5 minutes for full suite - **Key Scenarios**: Request/response schemas, error responses, version compatibility, backward compatibility - [ ] **QE-PLAN-1.4 [End-to-End Test Layer]**: - **Goal**: Validate complete user journeys across the full system stack - **Coverage Target**: ≥80% of critical user flows, 100% of business-critical operations - **Ownership**: QA automation team with business stakeholder input - **Tooling**: [Playwright, Cypress, Selenium] - **Execution Time Budget**: ≤30 minutes for full suite (parallelized) - **Key Scenarios**: Critical user journeys, cross-service workflows, UI + API integration - [ ] **QE-PLAN-1.5 [Test Data Strategy]**: - **Goal**: Ensure consistent, isolated, and realistic test data across all layers - **Coverage Target**: 100% of test scenarios have deterministic data - **Ownership**: QA automation team with DevOps support - **Tooling**: [Factory Bot, Faker, Testcontainers, Docker] - **Key Requirements**: Synthetic data generation, PII protection, environment parity, cleanup automation --- ### 2. Risk-Based Testing Strategy - [ ] **QE-PLAN-2.1 [Risk Assessment Matrix]**: - **Goal**: Map all components by likelihood and impact of failure - **Methodology**: 5x5 matrix (Likelihood: Rare to Almost Certain; Impact: Negligible to Catastrophic) - **Output**: Risk-tiered component inventory (Critical/High/Medium/Low) - **Review Cadence**: Quarterly or upon significant architectural changes - [ ] **QE-PLAN-2.2 [Risk-Based Coverage Allocation]**: - **Goal**: Allocate test effort proportional to risk tier - **Allocation**: Critical: 40% of test effort | High: 30% | Medium: 20% | Low: 10% - **Acceptance Criteria**: Risk-tiered quality gates (Critical components require 90% coverage, High require 80%, etc.) - **Regression Focus**: Critical and High tiers receive full regression; Medium/Low receive smoke regression - [ ] **QE-PLAN-2.3 [Critical User Flow Mapping]**: - **Goal**: Identify and document all business-critical user journeys - **Methodology**: Stakeholder workshops, analytics review, revenue impact analysis - **Output**: Documented flow inventory with risk ratings and test mapping - **Key Flows**: [List primary flows: e.g., user registration, checkout, payment processing, data export] --- ### 3. Automation and CI/CD Integration - [ ] **QE-PLAN-3.1 [Framework Selection]**: - **Goal**: Select appropriate testing frameworks per language and layer - **JavaScript/TypeScript**: Jest/Vitest (unit), Playwright (E2E), Pact (contract), Istanbul/c8 (coverage) - **Python**: pytest (unit/integration), Hypothesis (property-based), Locust/k6 (performance), Bandit/Safety (security) - **Java**: JUnit 5, Testcontainers, REST Assured, JaCoCo - **Justification**: Document rationale for each selection based on project context - [ ] **QE-PLAN-3.2 [CI Pipeline Design]**: - **Goal**: Define pipeline stages with parallelization and quality gates - **Stages**: Lint → Unit Tests → Integration Tests → Contract Tests → E2E Tests → Security Scans → Performance Tests → Deployment - **Parallelization**: Split test suites across runners (Jest shards, pytest-split) - **Time Budgets**: Total pipeline ≤45 minutes; fail if exceeded - **Quality Gates**: Coverage thresholds, failure rate limits, security scan requirements - [ ] **QE-PLAN-3.3 [Flaky Test Management]**: - **Goal**: Detect, quarantine, and remediate flaky tests - **Detection**: Automated flakiness detection (3 failures in 10 runs) - **Quarantine**: Immediate isolation with alert to owning team - **Remediation**: Root cause analysis required within 5 business days - **Prevention**: Timeout standards, no sleeps, deterministic data, proper cleanup - [ ] **QE-PLAN-3.4 [Test Data Management]**: - **Goal**: Ensure reliable, isolated, and secure test data - **Synthetic Data**: Factory-based generation for all test scenarios - **PII Protection**: Masking, anonymization, or synthetic generation for all personal data - **Environment Parity**: Containerized databases and services matching production - **Cleanup**: Automated data cleanup after test execution --- ### 4. Metrics and Quality Gates - [ ] **QE-PLAN-4.1 [Coverage Metrics]**: - **Goal**: Track coverage across all dimensions - **Targets**: Unit ≥80% line/70% branch | Integration ≥60% paths | E2E ≥80% critical flows | Contract 100% APIs - **Incremental Tracking**: Coverage trends tracked per sprint, not just point-in-time - **Tools**: Istanbul/c8, JaCoCo, coverage.py with branch coverage - [ ] **QE-PLAN-4.2 [Defect Metrics]**: - **Goal**: Track defect trends and quality indicators - **Metrics**: Defect density (per KLOC), escape rate (≤5%), time to detection (≤48h), severity distribution, reopened rate (≤5%) - **Dashboard**: Real-time visibility into all defect metrics - **Review**: Monthly defect review with trend analysis - [ ] **QE-PLAN-4.3 [Release Readiness Criteria]**: - **Goal**: Define measurable exit criteria for release - **Criteria**: All critical/high defects resolved | Coverage thresholds met | No open security vulnerabilities | Performance baselines maintained | Sign-off from QA lead and product owner - **Rollback Triggers**: Critical defect discovered post-deploy | Performance degradation >10% | Security vulnerability exploited --- ### 5. Non-Functional Testing - [ ] **QE-PLAN-5.1 [Performance Testing]**: - **Goal**: Validate system performance under various load conditions - **Types**: Load, stress, spike, endurance (24h), scalability - **Baselines**: Established from production metrics; SLO-based pass/fail criteria - **Tools**: k6, Gatling, Locust - **Schedule**: Load tests pre-release; endurance tests weekly - [ ] **QE-PLAN-5.2 [Security Testing]**: - **Goal**: Identify and remediate security vulnerabilities - **Types**: Vulnerability scanning (OWASP ZAP), dependency scanning (Snyk), secrets detection (GitLeaks), compliance testing - **Integration**: Mandatory pipeline stages, not optional - **Thresholds**: Zero critical/high vulnerabilities for release - [ ] **QE-PLAN-5.3 [Accessibility Testing]**: - **Goal**: Ensure WCAG 2.1 AA compliance - **Coverage**: Screen readers, keyboard navigation, color contrast, focus management - **Tools**: axe-core, Lighthouse, manual testing with screen readers - **Integration**: Automated scans in CI; manual audits quarterly - [ ] **QE-PLAN-5.4 [Compatibility Testing]**: - **Goal**: Validate across browsers, devices, OS, and API versions - **Matrix**: [Define supported browsers/devices/OS versions] - **Tools**: BrowserStack, Sauce Labs, Playwright device emulation - **Schedule**: Full matrix pre-release; smoke on supported versions - [ ] **QE-PLAN-5.5 [Chaos Engineering]**: - **Goal**: Validate system resilience under failure conditions - **Experiments**: Fault injection (service outages, network latency, database failures), resilience validation, graceful degradation - **Tools**: Chaos Monkey, Litmus, Gremlin - **Schedule**: Monthly in staging environment --- ## Findings and Recommendations ### 1. Test Pyramid and Coverage - [ ] **QE-ITEM-1.1 [Unit Test Coverage Gap in Business Logic Layer]**: - **Area**: Core business logic modules - **Risk Level**: High - **Scope**: [List specific modules/files with low coverage] - **Scenarios**: Edge cases in pricing calculations, discount logic, inventory management, user permission checks - **Success Criteria**: ≥80% line coverage; ≥70% branch coverage on identified modules - **Automation Level**: Fully automated - **Effort**: 3-5 developer-days per module - [ ] **QE-ITEM-1.2 [Missing Contract Tests for Service Boundaries]**: - **Area**: Inter-service communication - **Risk Level**: High - **Scope**: [List services with external dependencies] - **Scenarios**: Request/response schema validation, error handling, version compatibility, backward compatibility - **Success Criteria**: 100% of public API contracts tested; consumer-driven contracts enforced - **Automation Level**: Fully automated - **Effort**: 2-3 developer-days per service boundary - [ ] **QE-ITEM-1.3 [Insufficient E2E Coverage for Critical User Flows]**: - **Area**: End-to-end user journeys - **Risk Level**: Critical - **Scope**: [List critical flows: checkout, payment, registration, etc.] - **Scenarios**: Complete purchase flow, user registration with email verification, payment processing with error recovery, account management - **Success Criteria**: ≥80% of critical flows automated; 100% of business-critical operations covered - **Automation Level**: Fully automated with manual smoke backup - **Effort**: 5-8 QA automation days per flow --- ### 2. Edge Cases and Negative Testing - [ ] **QE-ITEM-2.1 [Boundary Value Analysis Missing for Numeric Inputs]**: - **Area**: All numeric input fields - **Risk Level**: Medium - **Scope**: [List forms/APIs with numeric inputs] - **Scenarios**: Min/max values, off-by-one (min-1, max+1), zero, negative values, decimal precision, overflow, underflow - **Success Criteria**: All boundary scenarios tested and documented; no unhandled boundary exceptions - **Automation Level**: Fully automated with parameterized tests - **Effort**: 1-2 developer-days per module - [ ] **QE-ITEM-2.2 [String Length and Format Edge Cases Not Covered]**: - **Area**: String inputs across all APIs and forms - **Risk Level**: Medium - **Scope**: [List fields with string inputs] - **Scenarios**: Empty strings, whitespace-only, max length, max+1, Unicode characters, special characters, SQL injection patterns, XSS payloads - **Success Criteria**: All string edge cases handled without errors or security vulnerabilities - **Automation Level**: Fully automated - **Effort**: 1-2 developer-days per module - [ ] **QE-ITEM-2.3 [Concurrency and Race Condition Testing Missing]**: - **Area**: Shared resources, database operations, file handling - **Risk Level**: High - **Scope**: [List concurrent operations: inventory updates, user sessions, payment processing] - **Scenarios**: Concurrent writes, read-modify-write races, deadlock scenarios, lock contention, async operation ordering - **Success Criteria**: No race conditions detected under concurrent load; proper locking mechanisms verified - **Automation Level**: Automated with load testing integration - **Effort**: 3-5 developer-days - [ ] **QE-ITEM-2.4 [Dependency Failure Resilience Not Tested]**: - **Area**: External service dependencies - **Risk Level**: High - **Scope**: [List dependencies: payment gateway, email service, database, cache] - **Scenarios**: Service unavailability, network timeouts, database connection loss, cascading failures, partial degradation - **Success Criteria**: Graceful degradation; proper error messages; no data corruption; automatic recovery - **Automation Level**: Automated with chaos engineering integration - **Effort**: 3-5 developer-days - [ ] **QE-ITEM-2.5 [Security Abuse Scenarios Not Covered]**: - **Area**: Authentication, authorization, input validation - **Risk Level**: Critical - **Scope**: [List security-sensitive endpoints] - **Scenarios**: SQL injection, XSS attacks, authentication bypass, privilege escalation, rate limiting bypass, malicious payloads, JWT tampering - **Success Criteria**: All security abuse scenarios blocked; no security vulnerabilities introduced - **Automation Level**: Automated with security scanning tools - **Effort**: 3-5 security testing days --- ### 3. Automation and CI/CD - [ ] **QE-ITEM-3.1 [CI Pipeline Lacks Parallel Test Execution]**: - **Area**: CI/CD infrastructure - **Risk Level**: Medium - **Scope**: Pipeline configuration - **Scenarios**: Test suite execution time, resource utilization, parallelization strategy - **Success Criteria**: Pipeline execution time ≤45 minutes; test suites parallelized across runners - **Automation Level**: Fully automated - **Effort**: 2-3 DevOps days - [ ] **QE-ITEM-3.2 [No Flaky Test Detection or Quarantine Process]**: - **Area**: Test infrastructure - **Risk Level**: High - **Scope**: All automated test suites - **Scenarios**: Flaky test identification, quarantine workflow, root cause analysis, remediation tracking - **Success Criteria**: Flaky tests detected within 10 runs; quarantined within 24 hours; RCA completed within 5 business days - **Automation Level**: Automated detection with manual RCA - **Effort**: 2-3 QA automation days - [ ] **QE-ITEM-3.3 [Test Data Management Lacks Isolation and Cleanup]**: - **Area**: Test data infrastructure - **Risk Level**: Medium - **Scope**: All test environments - **Scenarios**: Data isolation between test runs, cleanup automation, PII protection, environment parity - **Success Criteria**: No cross-test data contamination; automated cleanup; 100% PII protection - **Automation Level**: Fully automated - **Effort**: 3-5 developer-days - [ ] **QE-ITEM-3.4 [Missing Quality Gates in Pipeline]**: - **Area**: CI/CD pipeline - **Risk Level**: High - **Scope**: Pipeline stages and deployment process - **Scenarios**: Coverage thresholds, failure rate limits, security scan requirements, performance regression detection - **Success Criteria**: Pipeline fails on unmet quality gates; no deployment without passing gates - **Automation Level**: Fully automated - **Effort**: 2-3 DevOps days --- ### 4. Metrics and Quality Gates - [ ] **QE-ITEM-4.1 [No Numeric Coverage Targets Defined]**: - **Area**: Quality metrics - **Risk Level**: High - **Scope**: All test layers - **Scenarios**: Coverage measurement, threshold enforcement, trend tracking - **Success Criteria**: Numeric targets defined and enforced: Unit ≥80%, Integration ≥60%, E2E ≥80% critical flows - **Automation Level**: Automated measurement and reporting - **Effort**: 1-2 days - [ ] **QE-ITEM-4.2 [Defect Metrics Not Tracked Systematically]**: - **Area**: Defect management - **Risk Level**: Medium - **Scope**: All defects across the SDLC - **Scenarios**: Defect density, escape rate, time to detection, severity distribution, reopened rate - **Success Criteria**: All metrics tracked and reported; escape rate ≤5%; reopened rate ≤5% - **Automation Level**: Automated tracking with manual review - **Effort**: 2-3 days - [ ] **QE-ITEM-4.3 [No Release Readiness Criteria or Rollback Triggers]**: - **Area**: Release management - **Risk Level**: Critical - **Scope**: Release process - **Scenarios**: Exit criteria definition, sign-off requirements, rollback triggers, post-deployment monitoring - **Success Criteria**: Measurable release criteria; automated rollback triggers; post-deployment monitoring in place - **Automation Level**: Partially automated - **Effort**: 2-3 days --- ### 5. Non-Functional Testing - [ ] **QE-ITEM-5.1 [No Performance Baselines Established]**: - **Area**: Performance testing - **Risk Level**: High - **Scope**: All critical user flows - **Scenarios**: Load testing, stress testing, spike testing, endurance testing, scalability validation - **Success Criteria**: Baselines established from production metrics; SLO-based pass/fail criteria; performance regression detection in CI - **Automation Level**: Automated with scheduled execution - **Effort**: 5-8 performance testing days - [ ] **QE-ITEM-5.2 [Security Scanning Not Integrated into CI]**: - **Area**: Security testing - **Risk Level**: Critical - **Scope**: Application code, dependencies, infrastructure - **Scenarios**: Vulnerability scanning, dependency scanning, secrets detection, compliance checks - **Success Criteria**: All scans integrated into CI; zero critical/high vulnerabilities for release - **Automation Level**: Fully automated - **Effort**: 2-3 security testing days - [ ] **QE-ITEM-5.3 [Accessibility Testing Not Performed]**: - **Area**: Accessibility - **Risk Level**: Medium - **Scope**: All user-facing interfaces - **Scenarios**: WCAG 2.1 AA compliance, screen reader compatibility, keyboard navigation, color contrast, focus management - **Success Criteria**: WCAG 2.1 AA compliance; automated scans in CI; manual audits quarterly - **Automation Level**: Automated scans with manual audits - **Effort**: 3-5 days - [ ] **QE-ITEM-5.4 [No Chaos Engineering Experiments]**: - **Area**: Resilience testing - **Risk Level**: High - **Scope**: All critical services and dependencies - **Scenarios**: Fault injection, service outages, network latency, database failures, graceful degradation - **Success Criteria**: System resilience validated; graceful degradation confirmed; recovery procedures tested - **Automation Level**: Automated experiments with manual review - **Effort**: 5-8 days --- ### 6. Defect Management and Continuous Improvement - [ ] **QE-ITEM-6.1 [No Formal Defect Triage Process]**: - **Area**: Defect management - **Risk Level**: Medium - **Scope**: All defects - **Scenarios**: Severity classification, priority assignment, triage workflow, SLA enforcement, escalation paths - **Success Criteria**: Formal triage process documented and enforced; SLAs met; escalation paths clear - **Automation Level**: Partially automated - **Effort**: 2-3 days - [ ] **QE-ITEM-6.2 [No Root Cause Analysis for Recurring Defects]**: - **Area**: Defect prevention - **Risk Level**: High - **Scope**: Recurring defects and production escapes - **Scenarios**: RCA process, prevention practices, pattern recognition, knowledge sharing - **Success Criteria**: RCA conducted for all production escapes; prevention practices implemented; defect recurrence reduced - **Automation Level**: Manual process with tooling support - **Effort**: 3-5 days - [ ] **QE-ITEM-6.3 [No Production Feedback Loop into Test Strategy]**: - **Area**: Continuous improvement - **Risk Level**: High - **Scope**: Production defects, user-reported issues, stakeholder feedback - **Scenarios**: Feedback incorporation, strategy refinement, quality retrospectives - **Success Criteria**: Production defects fed back into test strategy; strategy reviewed quarterly; improvement actions tracked - **Automation Level**: Manual process - **Effort**: 2-3 days --- ## Proposed Code Changes ### 1. CI Pipeline Configuration (GitHub Actions Example) ```yaml # .github/workflows/quality-gates.yml name: Quality Gates on: pull_request: branches: [main, develop] push: branches: [main] jobs: unit-tests: runs-on: ubuntu-latest strategy: matrix: shard: [1, 2, 3, 4] steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - run: npm ci - run: npx jest --shard=${{ matrix.shard }}/4 --coverage - name: Upload coverage uses: actions/upload-artifact@v4 with: name: coverage-${{ matrix.shard }} path: coverage/ coverage-check: needs: unit-tests runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' - run: npm ci - name: Download coverage uses: actions/download-artifact@v4 with: path: coverage/ - run: npx jest --coverage --coverageThreshold='{"global":{"lines":80,"branches":70}}' integration-tests: runs-on: ubuntu-latest needs: unit-tests steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' - run: npm ci - run: docker-compose up -d - run: npm run test:integration - run: docker-compose down e2e-tests: runs-on: ubuntu-latest needs: [unit-tests, integration-tests] steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' - run: npm ci - run: npx playwright install --with-deps - run: npm run test:e2e - uses: actions/upload-artifact@v4 if: failure() with: name: playwright-report path: playwright-report/ security-scans: runs-on: ubuntu-latest needs: [unit-tests, integration-tests] steps: - uses: actions/checkout@v4 - run: npm audit --audit-level=high - run: npx gitleaks detect --verbose quality-gate: runs-on: ubuntu-latest needs: [coverage-check, integration-tests, e2e-tests, security-scans] if: always() steps: - run: | echo "All quality gates passed" ``` ### 2. Flaky Test Detection Script ```javascript // scripts/detect-flaky-tests.js const { execSync } = require('child_process'); const fs = require('fs'); const FLAKY_THRESHOLD = 3; // Failures in N runs const RUNS = 10; async function detectFlakyTests() { const results = {}; for (let i = 0; i < RUNS; i++) { console.log(`Run ${i + 1}/${RUNS}`); try { execSync('npx jest --listTests --json', { encoding: 'utf8' }); const output = execSync('npx jest --json', { encoding: 'utf8' }); const parsed = JSON.parse(output); parsed.testResults.forEach(suite => { suite.assertionResults.forEach(test => { const key = `${suite.name}::${test.title}`; if (!results[key]) results[key] = { failures: 0, runs: 0 }; results[key].runs++; if (test.status === 'failed') results[key].failures++; }); }); } catch (error) { // Test suite failed, parse partial results const output = error.stdout?.toString() || ''; try { const parsed = JSON.parse(output); parsed.testResults.forEach(suite => { suite.assertionResults.forEach(test => { const key = `${suite.name}::${test.title}`; if (!results[key]) results[key] = { failures: 0, runs: 0 }; results[key].runs++; if (test.status === 'failed') results[key].failures++; }); }); } catch (parseError) { console.error('Failed to parse test results'); } } } const flakyTests = Object.entries(results) .filter(([, data]) => data.failures > 0 && data.failures < FLAKY_THRESHOLD) .map(([name, data]) => ({ name, ...data })); if (flakyTests.length > 0) { console.log('Flaky tests detected:'); flakyTests.forEach(test => { console.log(`- ${test.name} (${test.failures}/${test.runs} failures)`); }); fs.writeFileSync('flaky-tests.json', JSON.stringify(flakyTests, null, 2)); process.exit(1); } else { console.log('No flaky tests detected'); } } detectFlakyTests(); ``` ### 3. Test Data Factory Example ```typescript // test/factories/user.factory.ts import { faker } from '@faker-js/faker'; import { User, UserRole } from '../../src/models/user'; export class UserFactory { static create(overrides: Partial<User> = {}): User { return { id: faker.string.uuid(), email: faker.internet.email(), firstName: faker.person.firstName(), lastName: faker.person.lastName(), role: UserRole.USER, isActive: true, createdAt: faker.date.past(), updatedAt: faker.date.recent(), ...overrides, }; } static createAdmin(overrides: Partial<User> = {}): User { return this.create({ role: UserRole.ADMIN, ...overrides }); } static createInactive(overrides: Partial<User> = {}): User { return this.create({ isActive: false, ...overrides }); } static createWithInvalidEmail(): User { return this.create({ email: 'invalid-email' }); } static createWithMaxLengthFields(): User { return this.create({ firstName: 'a'.repeat(255), lastName: 'b'.repeat(255), }); } } ``` ### 4. Boundary Value Test Example ```typescript // test/boundary/numeric-input.test.ts import { validateQuantity } from '../../src/validators'; describe('validateQuantity - Boundary Value Analysis', () => { const MIN = 1; const MAX = 100; test.each([ [MIN - 1, false], // Below minimum [MIN, true], // Minimum boundary [MIN + 1, true], // Just above minimum [Math.floor((MIN + MAX) / 2), true], // Midpoint [MAX - 1, true], // Just below maximum [MAX, true], // Maximum boundary [MAX + 1, false], // Above maximum [0, false], // Zero [-1, false], // Negative [1.5, false], // Decimal [NaN, false], // Not a number [null, false], // Null [undefined, false], // Undefined ['5', false], // String ])('validates %p as %p', (input, expected) => { expect(validateQuantity(input)).toBe(expected); }); }); ``` ### 5. Concurrency Test Example ```typescript // test/concurrency/inventory.test.ts import { InventoryService } from '../../src/services/inventory'; describe('InventoryService - Concurrency Tests', () => { let service: InventoryService; beforeEach(() => { service = new InventoryService(); }); it('handles concurrent stock updates without race conditions', async () => { const productId = 'product-1'; const initialStock = 100; const concurrentUpdates = 10; await service.setStock(productId, initialStock); const updates = Array.from({ length: concurrentUpdates }, () => service.decrementStock(productId, 10) ); await Promise.all(updates); const finalStock = await service.getStock(productId); expect(finalStock).toBe(initialStock - (concurrentUpdates * 10)); }); it('prevents overselling when stock is insufficient', async () => { const productId = 'product-2'; await service.setStock(productId, 5); const concurrentPurchases = Array.from({ length: 10 }, () => service.purchase(productId, 1) ); const results = await Promise.allSettled(concurrentPurchases); const successful = results.filter(r => r.status === 'fulfilled').length; const failed = results.filter(r => r.status === 'rejected').length; expect(successful).toBe(5); expect(failed).toBe(5); }); it('handles concurrent session updates without deadlocks', async () => { const sessionId = 'session-1'; const updates = Array.from({ length: 20 }, (_, i) => service.updateSession(sessionId, { lastActivity: Date.now() + i }) ); await expect(Promise.all(updates)).resolves.toBeDefined(); }); }); ``` --- ## Commands ### Local Development ```bash # Install dependencies npm ci # Run unit tests with coverage npm run test:unit -- --coverage # Run integration tests npm run test:integration # Run E2E tests npm run test:e2e # Run all tests npm test # Run security scans npm audit --audit-level=high npx gitleaks detect # Run flaky test detection node scripts/detect-flaky-tests.js # Run performance tests npm run test:performance # Run accessibility scans npm run test:a11y ``` ### CI Pipeline ```bash # Full pipeline execution (GitHub Actions) # Triggered on PR to main/develop or push to main # Manual pipeline trigger gh workflow run quality-gates.yml # Check pipeline status gh run list --workflow=quality-gates.yml ``` --- ## Quality Assurance Checklist - [ ] Every recommendation maps to a requirement or risk statement - [ ] Coverage references cite relevant code areas, services, or critical paths - [ ] Recommendations reference current test and defect data where available - [ ] All findings are based on identified risks, not assumptions - [ ] Test descriptions provide concrete scenarios, not vague summaries - [ ] Automated vs manual tests are clearly distinguished - [ ] Quality gate verification steps are actionable and measurable - [ ] All test pyramid layers have explicit coverage targets and assigned ownership - [ ] All critical user flows are mapped to risk levels and test scenarios - [ ] Edge-case and negative testing requirements cover boundaries, invalid inputs, concurrency, and dependency failures - [ ] Automation framework selections are justified with language and project context - [ ] CI/CD pipeline design includes parallelization, time budgets, and quality gates - [ ] Flaky test management has detection, quarantine, and remediation steps - [ ] Coverage and defect metrics have concrete numeric targets - [ ] Exit criteria are measurable and include rollback triggers - [ ] Performance testing strategy covers load, stress, spike, endurance, and scalability - [ ] Security testing includes vulnerability scanning, dependency scanning, and compliance - [ ] Accessibility testing addresses WCAG compliance, screen readers, and keyboard navigation - [ ] Compatibility testing covers browsers, devices, operating systems, and API versions - [ ] Chaos engineering experiments are designed for fault injection and resilience validation