不具合を切り分けるテスト表｜変えた条件と結果を対にする

不具合を調べるときは、基準となる条件を残し、何を変えて結果がどうなったかを対で記録します。一度に複数の条件を変えると、違いの理由を特定する材料が不足します。

私はアプリの改善や修正後の確認を依頼してきました。ここでは特定の障害の原因を示さず、確認の条件をそろえるためのテスト表を紹介します。以下の表は記入用で、実際の実行結果ではありません。

基準となる状態を記録する

確認した版：
開始画面：
入力する値：
選択している条件：
操作の順序：
実際の結果：
期待する結果：

版や入力が変わったことに気づかないと、違う結果を同じ現象として比べることになります。まず同じ条件を指しているかを確認します。

比較したい条件を一つ選ぶ

たとえば、入力値を変える、選択肢を変える、特定の操作を省くといった比較を考えます。ただし、どの変更が安全に試せるかを先に確認します。

複数の条件が同時に変わった場合は、そのことを記録します。結果に差があっただけで、単一の原因が分かったと断定しません。

実施していない確認を区別する

「問題なし」「未実施」「結果を確認できない」は別の状態です。実施できなかった条件を成功として扱わず、理由を残します。

• 必要な資料やアカウントがない
• 本番へ影響するため試していない
• 対象の環境を用意できない
• 同じ現象を再確認できない
• 記録が足りず比較できない

再確認できない場合も、最初の現象がなかったことにはなりません。確認した範囲と残った不確実性を記載します。

修正前後で同じ表を使う

修正後に別の入力だけを試すと、元の問題が直ったか分かりません。元の条件での結果と、影響しそうな関連操作の結果を分けて記録します。

ただし、実際の登録や送信が発生する操作は、何度でも試してよいとは限りません。試す範囲と実行後の状態を確認し、重複処理を避ける条件を用意します。

AIへの確認依頼

基準の条件を固定し、比較で何を変えたかを一覧にしてください。各条件の実際の結果、期待する結果、未実施の理由を記録してください。結果の差だけで原因を断定せず、根拠と残る確認を示してください。

現象そのものの報告は、再現手順と期待を分ける書式へまとめます。業務画面の操作を伴う場合は、少量テストの確認事項も参照してください。

まとめ

切り分けのテストでは、基準、変更した条件、実際の結果をそろえます。差が出たことと、原因が確定したことを分けて記録します。

修正後も元の条件で再確認し、未実施の範囲を明示します。試したことだけでなく、どの条件で確かめたかを残すことが大切です。