このユニットの結論
テストは、予定の日が来たから終わるものではありません。
「終わってよい条件（終了基準）」をテストの前に決め、その条件を満たしたかを、根拠をもって判断するものです。
満たしていない条件が残るなら、その残りを受け入れるかどうかを、責任を持つ人が決めます。
1. 何の話か
このユニットは、テストの終了判断の話です。
テストの工程は、次の工程（利用部門の確認、本番切替など）の前提になります。終わり方があいまいだと、問題を抱えたまま次へ進むことになります。
2. なぜ必要か
終了基準がないと、
- 日程に合わせて「終わったこと」にする
- 未解決の不具合が、どれだけ重いのか分からないまま次へ進む
- あとで問題が起きたとき、なぜ進めたのかを説明できない
ということが起きます。
3. このユニットで分かること
- 終了基準に含める観点
- 不具合の状況の見方
- 終了の判断で、AIに任せてよいことと人間が決めること
4. 終了基準に含める観点（一般的な例）
- 確かめた範囲：予定したテストを実施したか。要件ごとの確認に抜けはないか
- 未解決の不具合：重大度ごとに、未解決の件数はどうか。重大なものが残っていないか
- 不具合の傾向：新しく見つかる不具合が減ってきているか。同じ場所で繰り返し見つかっていないか
- 非機能：性能・安全などの目標を確かめたか
- 残りの扱い：直さずに進める不具合があるなら、回避策と、受け入れた人の記録があるか
具体的な件数や割合の基準は、プロジェクトで決めます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- P-010 宮田 直人 — テスト・品質管理リーダー
- M18 本番稼働
- AIへ最終委任しないことに「Go / No-Go」「重大障害判断」がある
アステリア案件のテストの終了基準と、その判断結果は、正本に記載がありません。未確定
5. THINK — 予定の日が来た
テスト工程の終了予定日になりました。予定したテストはすべて実施しましたが、重大度の高い不具合が未解決のまま残っています。
問題
予定どおりテストを終了してよいでしょうか。
判断例を開く
判断
終了基準に照らして判断します。
確認すること:
- 未解決の不具合は、業務のどこに影響するか
- 回避策はあるか。回避策で業務が回るか
- 直す見込みの時期は、次の工程に間に合うか
- 終了基準では、この状態を認めているか
- 認めていない場合、例外として受け入れるのは誰か
「予定の日だから」は、終了の理由になりません。
6. よくある失敗
- 終了基準を、テストの途中や最後に決める
- 実施したテストの件数だけで、終わったと判断する
- 未解決の不具合を、重大度で分けずに合計の件数だけで見る
- 例外で進めた判断を、記録に残さない
7. 成果物との接続
- TST-004 品質状況ダッシュボード：テストの進み具合と不具合の状況を、同じ見方で示す
- TST-003 障害管理表：不具合を重大度・状態で管理する
- TST-006 利用者受入テスト・終了判定報告書：終了の判断と、その根拠を残す
危機演習 CR05 開発が2か月遅延、CR10 重大な脆弱性が発見される も、進め方の判断を考える題材です（学習上の接続です。正式な対応関係ではありません）。
8. AI WORKFLOW — 不具合の状況をまとめさせる
AIは、不具合の一覧から状況をまとめる下書きに役立ちます。
指示例:
「次の不具合一覧を、重大度・機能・状態ごとに集計し、①未解決の重大な不具合、②長く解決していない不具合、③同じ機能で繰り返し見つかっている不具合、を挙げてください。テストを終了してよいかは判断しないでください。」
9. REVIEW — AIのまとめを確認する
- 重大度の分け方が、プロジェクトの基準どおりか
- 集計のもとの一覧が、最新の状態か
- AIが「終了してよい」と結論づけていないか
10. 人間が判断すること
- テストを終了してよいか
- 未解決の不具合を受け入れるか、直すまで待つか
- 例外で進める場合、誰がその判断に責任を持つか
11. 判断演習
あなたは、テストの終了判断の資料を作る担当です。
判断する人が、資料を見て「終了してよいか」を決められるように、資料に必ず入れる項目を4つ挙げてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
テストの終わりは、事前に決めた終了基準で判断するものです。
満たしていない条件を受け入れるなら、誰がどんな理由で受け入れたかを残します。