Testability Review

Use when a completed technical design needs its testability judged before implementation: whether acceptance criteria can actually map to concrete tests, which failure paths need coverage, and what the validation strategy is. This is the testability_review action of the design stretch — one Agent-tool dispatch with subagent_type qa-engineer — the QA read on a design, distinct from the test_evidence_review action (review-evidence skill, which later judges actual test results).

BhangeeF16 74dfb3f 1.3 KB Updated

File contents

Testability Review

Judge whether the design can be proven. A design whose acceptance criteria cannot map to a concrete test or validation step is not ready, however elegant.

Dispatch

One synchronous Agent-tool call, subagent_type: qa-engineer.

Required inputs

  • design.md.

Required outputs (all mandatory)

  • Testability notes — per acceptance criterion, how it will be proven.
  • Failure-path coverage — the denied/invalid/duplicate/unavailable cases the validation strategy must exercise, not just happy paths.
  • Validation strategy.

Result

Report each required output produced (with its location), the result (pass / pass_with_risks / blocked / failure), and blocking questions as an explicit list (empty list stated explicitly).

BhangeeF16/kaizen/tree/main/skills/testability-review commit 74dfb3fff1

Frequently asked questions

npx skillmds@latest add bhangeef16/testability-review