risk-based-verification

Build a risk map covering data integrity, security, boundaries, concurrency, compatibility, availability, and user behavior, then classify each applicable risk as low, medium, or high. Every medium or high risk must map to at least one executable test, such as unit, integration, contract, or end-to-end tests.

Risk-based testing allocates verification effort according to the risk a change introduces rather than file count or coverage metrics. It identifies risks per category, selects matching test types, runs them progressively, and reports concrete evidence including commands, exit codes, and residual risks.

No, it complements test-driven development and existing verification practices rather than replacing them. TDD owns red-green-refactor and implementation, while this approach owns risk identification, test-strategy selection, coverage decisions, and evidence reporting.

Apply it to any change that modifies observable behavior, crosses a boundary, changes stored data, affects authorization, introduces concurrency, or alters a public contract. Use it after design approval, before implementation, and again before claiming completion.

A bug fix without a regression test has no executable proof that the defect is resolved or that it will stay fixed. Risk-based verification requires creating a test that fails for the reported defect before fixing it, and treats missing regression tests as a stop condition.

Testing only mocked behavior for an external boundary is an explicit stop condition because mocks cannot reveal real API, queue, database, or filesystem behavior. Boundary changes require integration or contract tests against the actual external system or a faithful test environment.