主要な受け入れ基準が明確になっているか？¶
Type: Structure
Category: テスト
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
設計内容を「満たすべき条件」＝受け入れ基準として明確化することで、レビューやテストがブレずに実施できる
抽象的な「なんとなく良さそう」は判断や品質のバラつきの原因となる
例¶
- ユーザーがタスクを「承認」できること
- 誤って承認したタスクはある条件でのみ「取消」できること
- タスク一覧の件数・表示順が新ロジックに従ってXXXからYYYに変わること
よくある失敗例¶
- どの機能が満たされればOKなのかレビュー時点で曖昧
- 実装側とテスト側で期待値がズレていて二度手間になる。正常に動くことのような曖昧な期待値で発生しがち
- 状態の異常系（例：二重承認や破棄済みの操作）への検討が漏れている
FAQ¶
Q. 受け入れ基準はどこまで細かく書くべき？
A. 業務ロジック・画面UI・副作用（メール送信など）まで1ステップずつ書くのが理想で箇条書きでも可
Q. ストーリーとテストケースの違いは？
A. ストーリーは業務視点での期待値、テストケースはシステム視点での検証方法。両方あったほうがレビューが成立しやすい