diffとテストで変更を検証する

この記事で学ぶこと

• 差分では削られた条件も読む
• 検証を変更の種類から選ぶ
• 未確認の範囲を引き継ぐ

差分で変更の全体をつかむ

diffは、変更前と変更後の違いを表示するものです。

まずは細かな行より、変更されたファイルの一覧を見ます。

問い合わせ案内だけを直したのに、設定や別ページが含まれていれば、理由を確かめる必要があります。

予定どおりのファイルだけなら、次に追加と削除の内容を読みます。

文章の差分では、追加された表現だけでなく削られた条件を確認します。

「3営業日以内に返信予定」が「すぐに返信します」へ変わると、読みやすさの改善に見えても約束が変わっています。

見出しや誤字だけを直す依頼なら、その変更は範囲を超えています。

色分けされた行数より、利用者に伝わる意味がどう変わったかを見ます。

Gitの差分表示は、比較対象によって見える範囲が変わります。

記録前の変更、記録対象に選んだ変更、履歴同士の変更を混同しないようにします。

新しく作ったファイルが通常の差分に出ていない場合も、状態一覧で確認します。

差分が空というだけで、ファイルが何も変わっていないと判断しないことが必要です。

差分を読むときは、変更した行だけでなく前後の文も見ます。

単語の修正が正しくても、前の文とのつながりが崩れる場合があるためです。

ファイル数が想定より多いなら、整形や出力ファイルの更新が混ざっていないかを調べ、必要な変更かを分けて説明します。

変更前の文章も必要な範囲で読みます。

削除された行に例外や注意事項が含まれていれば、修正文だけでは失われた条件に気づきません。

依頼の対象と、その前後の意味を合わせて確認します。

差分を読むことに慣れていない場合は、変更前後を短い表へまとめてもらう方法も使えます。

検証を要求から選ぶ

検証方法は、変更の種類に合わせて選びます。

文章の誤字修正なら、該当箇所と前後の文脈の確認が中心です。

問い合わせ先のリンク変更なら、表示文字に加え、実際の遷移先が正しいかを確かめます。

複数ページで共有する処理を直したなら、他の利用箇所への影響も対象になります。

機械的な確認には、構文の問題や表記規則への違反を見つけるものがあります。

lintは、コードなどの規則違反を検出する確認の一種です。

ただし、機械が成功を返しても、営業時間や料金が事実と一致するとは限りません。

何を調べる検証なのかを理解し、業務上の正しさは別に確認します。

例えば架空の問い合わせページでは、「案内文が指定どおり」「リンク先が問い合わせフォーム」「既存の申込リンクが維持される」を確認します。

見た目が関係する変更なら、狭い画面でも読めるかを見ます。

毎回すべてを試すのではなく、今回の変更が壊し得るものを選ぶと、確認時間と見逃しの両方を抑えられます。

要求ごとに確認方法を選べます。

文字の一致は元資料との比較、表示崩れは実際の画面、計算は既知の答えを持つ見本で確かめます。

すべてを画面の目視だけで済ませたり、すべてを自動検査だけで保証したりせず、失敗を見つけられる方法を対応させてください。

確認項目ごとに、証拠となるものを決めます。

リンク先なら実際の遷移先、事実なら元資料、構文なら検査結果です。

すべてを同じ確認済みという言葉にまとめないでください。

何で確かめたかが分かれば、別の担当者が不足する確認を選べます。

過不足のない引き継ぎに必要な区別です。

正常と例外の両方を試す

正常な入力だけでは、動作の一部しか確かめられません。

リンク先がない、項目が空、文字列が長いといった条件を選ぶと、境界での動作が見えます。

問い合わせ案内なら、連絡先が未設定の場合に空のリンクが出ないかなどが該当します。

例外を無数に増やすより、現実に起きる条件から優先します。

期待結果は実行前に書きます。

「未設定なら問い合わせ先未登録と表示する」など、結果を判定できる文章にします。

実行後に表示されたものをそのまま正解にすると、検証になりません。

仕様が決まっていない場合は、AIが勝手に例外の扱いを発明するのではなく、提案として分けて判断します。

外部への送信を伴う確認では、試験用の仕組みや送信しない確認方法を使います。

本番の顧客へ実際に送ることは、動作確認の名目でも別の影響があります。

フォームの見た目を確認する作業と、送信が届くことを確認する作業は区別します。

実施できなかった確認は、理由と残る範囲を報告へ残します。

例外の見本は、現場で困る状態から選びます。

必須欄が空、長い名前が入る、リンク先が見つからない、といった場合です。

何でも無数に試す必要はありません。

今回変えた箇所と、間違ったときの影響から優先する例を決めると、確認を絞っても理由を説明できます。

例外の見本には、実際に過去の問い合わせで困った条件を使える場合があります。

長い社名で表示が崩れたなら、似た長さの架空名を用意します。

本物の個人情報を再利用する必要はありません。

現実の失敗の構造を見本へ移すと、単に思い付いた例より実務に合う検証になります。

失敗の原因を切り分ける

検証が失敗したら、今回の変更が原因か、元からの問題か、環境の不足かを分けます。

依存する仕組みが起動していない場合と、変更で処理が壊れた場合では、直す対象が違います。

エラー文の最後だけを見て変更を重ねると、無関係な設定まで変えることになりかねません。

まず、実行した確認、対象、失敗の内容を記録します。

再現できる範囲で、変更前にも同じ問題があるかを確かめます。

ただし、他の人の作業を戻して比較しないでください。

比較用の環境や履歴を使うなど、現在の成果物を壊さない方法を選びます。

原因が分からなければ、未解決として切り分けの結果を残します。

修正後は、失敗した確認を再実行します。

エラーが消えただけで、必要な機能が丸ごと無効になっていないかも見ます。

例えばリンクを削ればリンク検査の問題は消えるかもしれませんが、問い合わせへ進めなくなります。

検証を通すことではなく、依頼の動作を保ったまま原因を直すことを目標にします。

同じ失敗が続いたら、直前の修正を重ねる前に、再現する最小の材料を作ります。

どの入力で起き、どの入力では起きないかを分けると、原因の候補を減らせます。

確認用の材料を保存しておけば、修正後だけでなく、次の変更時にも同じ問題を検出できます。

エラーを直すために検証の条件を緩める案が出た場合は、何を確認しなくなるかを見ます。

古い検証が現在の仕様に合わないこともありますが、変更を通すためだけの無効化は別です。

要求と検証のどちらが正本に合っているかを確かめ、変更理由を残してから判断します。

報告を証拠と結び付ける

最終報告は、変更したこと、確認したこと、未確認のことを分けます。

「問題ありません」という総評より、「問い合わせ文を修正し、表示とリンク先を確認。実際の送信は未実施」と書く方が判断できます。

実行していない確認を予定形のまま成功報告へ混ぜないようにします。

検証記録には、対象と結果が分かる程度の情報を残します。

長いログをそのまま貼る必要はありません。

失敗がある場合は、該当するエラーと影響を短く記述し、詳細へ戻れる場所を示します。

画面確認なら、どの画面幅や利用条件を見たかが分かると、別の人が再確認しやすくなります。

最後に、要求と結果を照らします。

依頼していた文章が直り、対象外が保たれ、必要な確認が完了していれば採用できます。

未確認事項が利用に影響するなら、公開前に対応します。

小さな問題でも隠すより、影響を説明する方が次の判断が速くなります。

検証結果は、作業者の自己評価ではなく引き継ぎの材料です。

報告には、実行した検査の結果と、実際に見た画面を区別して書けます。

「ビルド成功、携帯幅で表示確認、実送信は未確認」という形です。

検査名だけを並べず、依頼のどの条件を確かめたかを添えると、残る作業と公開可否を判断しやすくなります。

未確認事項には、次に誰が何を見れば解消するかを添えます。

「実送信は未確認」だけでなく、試験用宛先と確認する担当が分かれば後工程へ進めます。

確認できない理由が解消しないまま公開する必要がある場合は、担当者が影響を判断します。

作業者の報告で未確認を消さないことが原則です。

まとめ

差分は変更の意味、テストは決めた動作、実画面は利用場面を確認します。

それぞれが確かめる範囲は異なります。

次の修正では、完了報告を読む前に変更一覧を見て、要求に対応する確認と未確認事項を記録してください。

• 差分では削られた条件も読む
• 検証を変更の種類から選ぶ
• 未確認の範囲を引き継ぐ