test-design

Risk-based test design prioritizes test scenarios by impact and likelihood, then maps them across unit, integration, and end-to-end test levels with P0/P1/P2 priorities. This approach ensures critical paths receive adequate coverage before implementation begins, reducing defect escape and rework downstream.

Mock strategies isolate external APIs, databases, and services by replacing them with controlled test doubles, enabling fast, deterministic test execution. Define mocks per test level—unit tests mock all externals, integration tests mock downstream systems, end-to-end tests use staging environments—then integrate mock configuration into CI/CD pipeline stages.

Convert acceptance criteria into Given-When-Then test cases, then distribute across test levels: unit tests validate business logic in isolation, integration tests verify component interactions, end-to-end tests confirm user workflows. Assign P0/P1/P2 priorities by risk, define data specifications per level, and document coverage targets to guide implementation.

A test design document specifies test levels, acceptance criteria coverage, mock strategies for each external dependency, P0/P1/P2 priorities, test data requirements, and CI/CD integration thresholds. This artifact ensures developers, QA, and CI systems align on test scope and execution order before coding begins.

Risk-based testing prioritizes resources on high-impact, high-likelihood failure modes—essential for complex features with external dependencies, strict SLAs, or limited test budget. Use it when uniform coverage is infeasible; focus testing effort on scenarios with greatest business impact and technical complexity.

Yes. Map test levels to CI/CD stages (unit in pre-commit, integration in merge gate, E2E in staging), configure mock endpoints and test data in pipeline environment variables, and set pass/fail thresholds aligned with P0/P1/P2 priorities. Document this mapping in your test design to enable repeatable execution.