Bugs in production cost more than bugs caught before deployment. Most QA processes are designed to catch them after.

End-to-end test suites for your web application using Playwright (preferred for new projects: multi-browser support including Chromium, Firefox, and WebKit in a single test run; built-in network interception; reliable async/await API) or Cypress (strong developer tooling, component testing support, time-travel debugging). Test scenarios covering critical user journeys: authentication flows (login, MFA, password reset, OAuth 2.0 callback), core business workflows (order creation, approval chains, form submission with validation), payment flows (Stripe test mode with simulated card numbers covering success, decline, and 3DS scenarios), and data entry workflows with edge case inputs (Unicode characters, very long strings, empty fields, boundary values).

Tests structured for maintainability from day one: Page Object Model (POM) with one page class per page/route section, so a selector change in one class propagates to all tests using that page rather than requiring a grep-and-replace across dozens of test files. data-testid attributes added to interactive elements during development so tests survive CSS refactors and visual redesigns, data-testid selectors are stable; CSS class selectors are not. Reusable helper functions for repeated sequences (login, navigate to section, seed test data via API rather than via UI). Clear test naming following the Given-When-Then convention so failure output is readable without opening the test file: "given a logged-in user, when they submit the order form with a missing address, then an error message displays."

CI/CD integration: Playwright tests run in parallel using sharding (--shard=1/4, --shard=2/4, etc.) across multiple CI runners, reducing a 20-minute sequential test run to 5 minutes. Tests run on every pull request; failures block merge until resolved. Failure reporting: HTML report with screenshots and video of failing tests and the last 3 successful test runs for comparison; trace viewer showing the full DOM state at each assertion step so developers debug from the CI artifact without local reproduction. Flaky test detection: Playwright's built-in flaky detection retries on failure and flags tests that pass on retry as flaky rather than failed, flaky tests are tracked in a separate queue and addressed systematically rather than silently tolerated.

Automated API contract testing that validates endpoint behaviour across every scenario that a manual test wouldn't reliably cover: correct HTTP response codes (200, 201, 400, 401, 403, 404, 409, 422, 500), response schema validation against a JSON Schema or OpenAPI 3.0 spec (ensuring field names, data types, and required fields match the contract), error response structure consistency (all errors return the same {error: string, code: string} shape, not ad-hoc messages), authentication enforcement (requests without a valid token return 401, not 200 or 500), and edge case inputs (empty strings, null values, extremely long strings, special characters, integers at boundary values, duplicate submissions).

Tooling: Postman collections with Newman for CI/CD integration (Newman runs the collection on every deploy, reports pass/fail to GitHub Actions, and produces a JSON/HTML report). For code-based teams, Supertest (Node.js, Express/Fastify APIs) or RestAssured (Java/Spring) enables API tests to live alongside application code with shared type definitions, when an endpoint changes its response shape, the TypeScript type and the API test are updated in the same commit. Pact for consumer-driven contract testing between microservices: the API consumer defines the contract (the minimum response structure it expects), the provider runs the Pact verification against that contract, and the Pact Broker stores and versions contracts. A provider service cannot be deployed if it would break a contract its consumers depend on, catching breaking API changes before they reach integration environments where they cause cascading failures.

API documentation generated from OpenAPI 3.0 spec files as the source of truth: test collections are generated from the spec, Swagger UI serves the documentation from the spec, and a CI check validates that the spec matches the actual endpoint behaviour. This eliminates documentation drift, the API spec and the live behaviour stay synchronised because the tests enforce it.

Performance testing using k6 (JavaScript scripting, TypeScript support, built-in CI/CD integration, both open-source local execution and k6 Cloud for distributed load generation). Load tests simulate realistic concurrent user behaviour based on your actual traffic patterns: virtual users (VUs) ramp from 0 to peak concurrency following your observed traffic curve rather than an unrealistic sudden spike. Test scenarios are weighted: if 60% of your traffic is unauthenticated browse and 40% is authenticated with API calls, the load test reflects that ratio.

Test types delivered: baseline measurement (10-50 VUs, steady state for 5-10 minutes, establishing p50/p95/p99 response time and throughput for each critical endpoint); load test (simulating expected peak traffic, your 95th percentile traffic day, not average); stress test (gradually increasing load until response times degrade or the application returns errors, identifying the breaking point and the failure mode); spike test (sudden 10x traffic increase held for 3 minutes, simulating a flash sale or media mention, testing whether the application recovers gracefully or cascades into failures); soak test (sustained moderate load over 4-8 hours, detecting memory leaks and connection pool exhaustion that only manifest over time).

Performance thresholds configured as pass/fail criteria in the k6 test script: p(95) < 500 (95th percentile response time under 500ms), rate(errors) < 0.01 (error rate under 1%), http_req_duration{ status: "200" } p(99) < 2000 (99th percentile successful request under 2 seconds). If a deployment degrades p95 response time by more than 20% compared to the baseline measurement, the performance test fails and the deployment is blocked. Database query performance profiled under load: slow query log thresholds set at 100ms during load tests identify N+1 query patterns and missing indexes that only become apparent under concurrent load. Results output to InfluxDB + Grafana for time-series visualisation of response time distribution, error rate, and throughput during the test run.

Mobile testing on real iOS and Android devices using BrowserStack App Automate or AWS Device Farm, not just emulators. Device coverage matrix configured based on your user analytics: if 40% of your mobile users are on iOS 16+ and 35% are on Android 12+, those are the primary test targets; older OS versions are included in the matrix where your analytics show meaningful usage. Device-specific issues that emulators systematically miss: rendering differences on specific screen densities (1x/2x/3x DPI), touch event handling differences across manufacturer custom UI layers (Samsung One UI, Xiaomi MIUI), memory pressure behaviour on lower-spec Android devices (app pauses, background service kills), and camera/microphone permission flows that differ across iOS versions.

Automated UI tests for React Native applications using Detox (React Native-specific, runs on the actual simulator/device build, not a webview); for native iOS/Android applications, Appium with the UIAutomator2 driver (Android) and XCUITest driver (iOS). Test scenarios: app launch and splash screen completion time, authentication flows, critical user journey completion, push notification receipt and deeplink navigation, offline mode behaviour (cached data display, appropriate error messaging when a network request fails), and background/foreground state transitions (returning to the app after a phone call, after switching apps). Network condition simulation: BrowserStack's network condition profiles (3G, 4G, offline) applied during specific test scenarios to validate that the application fails gracefully on poor connections rather than hanging indefinitely or showing cryptic errors.

Accessibility on mobile: touch target sizes meeting Apple HIG (44x44pt minimum) and Google Material guidelines (48x48dp minimum) verified programmatically; VoiceOver (iOS) and TalkBack (Android) screen reader compatibility checked for critical flows; colour contrast ratios verified on mobile viewports where system dark mode may change the effective background colour. Test results include device name, OS version, and a video recording of the test run, making device-specific failures reproducible without requiring the specific device.

Structured exploratory testing using session-based test management (SBTM): each exploratory session is chartered (a specific area of the application and a defined mission, "explore the checkout flow with unusual shipping addresses and promotional codes"), time-boxed (60-90 minutes), and documented (what was tested, what was found, what was not tested, and why). This produces a coverage record that shows stakeholders what was tested before a release, not just a list of passing test cases. Charters are derived from risk analysis: features recently changed, features with a history of defects, and features involving integration with external services are chartered first.

Defect documentation format: every defect report includes a one-line summary, severity rating (Critical/High/Medium/Low using a consistent rubric, Critical means production is broken for all users, High means a significant workflow is blocked for some users, Medium means a workaround exists but requires effort, Low means cosmetic or minor inconvenience), reproduction steps (numbered, starting from a specific known state with specific test data), expected vs. actual result, the environment and version where it was found, and a screenshot or screen recording attached. This level of documentation means developers can reproduce the defect on the first attempt, not after 3 rounds of clarification questions. Defect priority is set by the product owner, not the QA engineer, severity is a factual assessment (how bad is this?), priority is a business decision (when should this be fixed?).

Release readiness report produced before each significant release: test coverage summary (which scenarios were tested and by what method), open defects by severity with a risk assessment for each unresolved defect, known risks (features that received limited test coverage due to time constraints), test environment vs. production differences that could introduce post-release issues, and a go/no-go recommendation. The report is written for a non-technical product owner or release manager, not just for the engineering team, quality information should be accessible to the people making release decisions.

Test plan design for teams without a structured testing process: a written test strategy document covering test objectives, scope (what is in scope, what is explicitly out of scope), test types to be used (automated regression, API contract, performance, exploratory), environments (staging, pre-production), data management (test data sources, data masking for production data, seed data scripts), defect management workflow (how defects are captured, triaged, prioritised, tracked, and verified), and entry/exit criteria for each testing phase. This document prevents the implicit "we'll test when we have time" pattern that causes quality problems at scale.

Test case library in TestRail, Zephyr Scale (Jira-native), or Notion depending on your team's existing tools and release cadence. Test cases structured as: preconditions (specific starting state), steps (numbered, action + expected result per step), and pass/fail status tracked per test run per release. Test suites grouped by feature and risk area so a regression suite for the payment module can be run independently of the entire suite when only payment-related code changed. Cross-referencing between test cases and requirements (Jira stories or Linear issues) so coverage gaps are visible, which stories have no test cases written, and defects can be traced to the specific requirement they violate.

Quality metrics reported weekly: test automation coverage (total test cases, percentage automated, percentage currently passing), defect density per feature (defects per user story point delivered, identifies which areas generate the most defects), defect escape rate (defects found in production as a percentage of all defects found, the primary quality KPI; a rising escape rate indicates the pre-production testing is not catching what production is encountering), defect age (days from report to resolution by severity, identifies whether high-severity defects are being resolved quickly enough). These metrics are reviewed in a weekly quality sync with the engineering lead, not saved for the quarterly retrospective after the quality degradation has compounded.