「テスト成功」という報告だけでは、要求どおりの変更かは判断できません。
予定外の編集、業務上の数字、画面の使いやすさは、それぞれ別の確認が必要です。
このレッスンでは、申込フォームの入力チェックを直す架空の例から、差分、テスト、実画面を組み合わせる方法を学びます。
何を確かめたかを言葉にできる確認記録を作ります。
この記事で学ぶこと
- 削られた条件も差分で読む
- 期待結果を実装から独立して決める
- 確認の範囲を正確に報告する
差分を要求と照合する
差分を見る目的は、変更された行を数えることではなく、要求との関係を確かめることです。
最初に変更ファイルの一覧を見て、今回の対象に合っているかを確認します。
次に変更箇所を読み、追加された動作と削られた条件を把握します。
知らないファイルがあれば、なぜ必要だったかを確かめます。
架空の例では、電話番号が任意なのに必須扱いされる不具合を直します。
正しい差分は任意の扱いへ整えることですが、すべての入力チェックを削ればエラーは消えても別の不具合が生まれます。
見た目のエラーがなくなったことだけでは不十分です。
必要な条件を維持しながら目的を満たしたかを見ます。
差分の比較対象も確認します。
作業開始前と現在の違いなのか、記録済みの変更同士なのかで見える内容が変わります。
新規ファイルや別の人の変更が混ざる場合もあります。
今回の作業だけと決めつけず、開始状態の記録と照合します。
予定外の差分を見つけたら、まとめて消す前に由来を調べます。
追加されたテストも差分の確認対象です。
必要な条件を検証しているか、実装の値をそのまま期待値へ写しただけかを見ます。
テストが増えたこと自体を品質の証拠にしないでください。
要件を独立して表した確認になっているかを見ると、成功表示だけでは分からない弱点を見つけられます。
テストの役割を理解する
テストは、決めた入力に対して期待した動作になるかを確かめるものです。
すべての問題を自動的に見つける保証ではありません。
何を試したかによって、確かめられる範囲が決まります。
構文の確認だけを実行して、フォームの使い方まで正しいと判断しないようにします。
電話番号の任意化なら、空欄でも先へ進めること、入力された場合は必要な形式確認が働くことを分けて試します。
また、名前など別の必須項目は引き続き検査されることを確認します。
変更箇所だけでなく、その周辺の重要な動作へ影響がないかを見る確認を、回帰の確認と呼びます。
テストを選ぶときは、既存の検証方法を確認します。
変更の小ささと影響範囲に合わせて必要なものを使い、意味のない再実行を重ねません。
実行に必要な環境が不足していれば、その事実を記録します。
動かなかったテストを省略して成功報告へまとめず、どの動作が未確認かを明らかにします。
検証の範囲を決めるときは、共有されている処理の利用先を見ます。
1画面の修正でも同じ関数を複数の画面が使うなら、影響が広がる可能性があります。
独立した文章変更なら、広い試験が不要な場合もあるでしょう。
変更ファイルの数だけでなく、動作のつながりから確認を選びます。
期待結果を先に決める
テストの前に、入力と期待結果を組にして書きます。
正常な例だけでなく、空欄、不正な形式、長い入力などを選びます。
ケースの数を増やすことより、今回の変更で判断が分かれやすい条件を押さえることが大切です。
実装者と確認者が同じ正解を持てる状態にします。
架空の確認表では、電話番号空欄なら送信可能、明らかに不正な文字列なら案内を表示、名前空欄なら送信不可とします。
実際の仕様によって条件は変わるため、この例をそのまま正解にしないでください。
受け付ける形式や必須項目は、業務の要件から決めます。
仕様が曖昧なままテストを書かせると、Codexが実装した動作をそのまま期待結果にするおそれがあります。
それでは誤りを見つけられません。
期待結果の根拠を、確定した要件や担当者の判断へ戻します。
AIにはケースの抜けを提案してもらい、人が業務上の条件を確認する分担にします。
期待結果は、利用者に見える形でも書きます。
エラーになるというだけでなく、入力を残したまま対象項目の案内が出る、という条件です。
これにより、機械的には失敗を返していても操作をやり直させる問題を発見できます。
仕様の意味をテストの値だけへ縮めないことが必要です。
実画面で利用条件を試す
コードのテストが通っても、画面で案内が読めない、ボタンが押しにくいことがあります。
利用者が行う順番で、入力、エラー確認、修正、次へ進む操作を試します。
狭い画面で案内が重なるなど、表示に関係する変更なら画面幅も確認します。
見た目と機械検証は相互に補うものです。
エラー表示は、出ることだけでなく、何を直せばよいかが分かるかを見ます。
「エラー」とだけ出るより、対象項目と必要な修正が示される方が利用できます。
入力内容が消えないか、修正したら状態が更新されるかも確認します。
利用者の手間を増やしていないかを、実際の操作で見ます。
外部送信の確認は、試験環境や試験用宛先を使うなど、許可された方法で行います。
本番の相手へデータを送ることは、単なる画面確認とは異なります。
送信を試せなかった場合は、表示と入力チェックは確認済み、実送信は未確認と分けます。
確認の範囲を明確にすると、後の判断ができます。
画面の確認では、最初から入力し直すケースと、誤りを直すケースを分けます。
初回は動いても、再入力後の状態が古いまま残る場合があります。
今回の変更に関係する利用の流れを選び、途中から再開する操作も試してください。
実際の利用者がたどる順番を確認表にする考え方です。
証拠と残課題を引き継ぐ
最終報告には、変更した動作、実施した確認、残った不確実性をまとめます。
長いログを全部貼る必要はありませんが、何を実行して何が分かったかは残します。
例えば「電話番号空欄と不正形式、名前空欄を確認。実送信は試験環境がなく未実施」と書けば、確認の境界が分かります。
失敗があった場合は、今回の変更によるものか、以前からの問題か、環境の問題かを切り分けます。
分からない場合は未解決と明記します。
成功した項目と失敗した項目を混ぜて総合的に「問題なし」としないでください。
未解決の影響が採用判断に必要な情報です。
修正後は、失敗したケースを再び確認します。
原因を直したつもりでも、別の条件を壊している可能性があります。
ただし、結果が揃った後に同じ検証を理由なく何度も繰り返す必要はありません。
要求に対応した証拠が揃い、残課題が説明できれば、次の公開判断やレビューへ渡します。
検証記録を次へ渡すときは、対象の版を明確にします。
確認後に別の修正が入ったなら、その確認結果が現在の内容にも当てはまるかを見直します。
以前の成功記録を新しい成果物へ無条件に流用しないでください。
変更した範囲へ必要な確認を追加することで、過剰な再試験も減らせます。
実践課題
実践課題：三つの証拠をまとめる
つくるものは、フォーム修正の検証記録です。
用意するのは、電話番号が任意という架空の要件と、変更前後の説明です。
コードを実行できない場合は、期待結果の確認表を完成させます。
実行した場合と設計しただけの場合を区別して記録してください。
- 差分から追加と削除された動作を説明する
- 入力3種類と期待結果を決める
- 実画面で確認する操作を並べる
- 実施済みと未実施、残る判断を分ける
架空の完成例：「電話番号の必須条件だけを外した。空欄、不正形式、名前空欄の結果を確認した。狭い画面で案内を読めた。試験用送信は未実施であり、公開前に担当者が確認する。」
自己確認
- 要求と差分の対応を説明できる
- 期待結果に業務上の根拠がある
- 未確認が成功に含まれていない
まとめ
差分で変更の意味を確かめ、テストで期待動作を調べ、実画面で利用場面を確認します。
どれか1つだけでは確認できないことがあります。
次の変更では、入力と期待結果を先に書き、結果と未確認事項を一緒に残してください。
- 削られた条件も差分で読む
- 期待結果を実装から独立して決める
- 確認の範囲を正確に報告する
