テストで想定と違う結果が出たら？不具合か判断できないときの確認手順

結論｜不具合と決める前に、根拠と条件を確認する

想定と違う結果が出たら、まず記録し、「どう動くはずかの根拠」と「試した条件」を確認しましょう。分からない点が残れば、不具合か未確定のまま相談して大丈夫です。

「こうなるはず」と決めた結果を、テストでは「期待結果」と呼びます。その根拠になるのが、システムの動きやルールを定めた「仕様」です。

たとえば、会員登録の画面で「名前は10文字まで入力できる」という決まりが仕様です。「10文字の名前を受け付ける」が期待結果になります。

結果の違いには、プログラムの不具合のほか、テスト手順書の誤り、操作やデータの違い、仕様の読み違いなども考えられます。違いが出たという事実と、その原因は分けて考えます。

想定と違う結果が出たときの確認手順

まずは次の順番で確認すると、相談に必要な情報を整理できます。データが消えた、想定外の送信が行われたなど、影響が広がりそうな場合は、再操作せず先に担当者へ連絡してください。

STEP1｜画面を変える前に、結果を保存する

最初に、実際に起きたことを残します。画面を閉じたり再読み込みしたりすると、表示や入力内容が変わる場合があるためです。

• 試したテストの番号と、発生した日時
• 入力した値と、ボタンを押すまでの操作
• 表示された画面やメッセージの全文
• 「どうなるはずだったか」と「実際にどうなったか」

画面の画像だけでなく、「保存ボタンを押すと、一覧画面に移らず入力画面に戻った」のように短い文章も添えます。メッセージが出なかった場合は、それも記録です。

記録を共有するときは、パスワードや個人情報などをチームのルールに従って扱ってください。

STEP2｜「こうなるはず」の根拠を確認する

テスト手順書の期待結果と、その根拠になった仕様書・設計書の該当箇所を見比べます。「前の案件ではこうだった」「自分ならこう使うはず」という予想だけで判断しないことがポイントです。

資料を見るときは、版や更新日だけでなく、今回テストしているプログラムに適用される内容かを確認します。新しい資料でも、次回の変更について書かれている可能性があります。

資料同士で内容が違う、該当する説明がない、表現が曖昧という場合は、どの資料のどこで迷ったかを残します。テスト担当の先輩や、仕様を確認できる担当者に判断を求めましょう。

現在の動きに合わせて、期待結果を自分の判断で書き換えてはいけません。「仕様どおりか」と「その仕様で利用者が困らないか」は別の確認なので、仕様どおりでも気になる点は相談できます。

STEP3｜操作・データ・環境の条件を確認する

同じ画面でも、使うアカウントやデータが違うと結果が変わることがあります。ここでいう「環境」は、テスト用サイトの接続先やプログラムの版など、テストを動かす場所や設定のことです。

• 操作：開始する画面、入力する順番、押すボタンが手順書と同じか
• データ：前のテストで登録済みになっていないか。入力値に空白などが混ざっていないか
• アカウント：一般利用者用か管理者用かなど、操作できる範囲が合っているか
• 環境：指定されたテスト用URLか。対象のプログラムの版か。指定のブラウザか

たとえば、「未登録のメールアドレスで登録する」テストで、すでに登録済みのアドレスを使うと、重複を知らせるメッセージが出ることがあります。この場合は、テスト開始前の条件が違っています。

条件に違いが見つかっても、最初の記録は残します。条件をそろえた後の結果と分けておくと、何が変わったかを説明できます。

STEP4｜安全に繰り返せる場合だけ、同じ条件で確かめる

同じ条件で同じ現象が起きることを「再現する」といいます。繰り返してよい操作なら、記録した手順と開始前の状態をそろえて、もう一度確かめます。

登録・削除・メール送信などは、繰り返すことでデータや相手先に影響する場合があります。再実行してよいか不明なら、先に担当者へ確認してください。共有データの削除や設定変更を、確認のために勝手に行わないようにします。

ブラウザを変えるなど別の条件を試す場合は、一度にいくつも変えず、何を変えたかを記録します。条件が違う結果を「同じ条件での再確認」と混ぜないことが大切です。

結果は「初回と再確認1回の両方で発生」「初回のみ発生し、再確認1回では発生せず」のように残します。再現しなかっただけでは、不具合がないとは判断できません。

STEP5｜分かった事実と、分からない点を添えて相談する

ここまでで判断できなくても、調査を止めずに抱え込む必要はありません。「何が起きたか」「何を確認したか」「何を判断してほしいか」をまとめ、チームで決められた相手に相談します。

コードの原因まで特定することは、相談の前提ではありません。「不具合だと思います」だけよりも、「この仕様では受け付けると読めますが、実際は拒否されました」と伝える方が、相手も確認しやすくなります。

具体例｜「10文字まで」の欄で10文字が入力できない

ここからは、架空の名前入力欄を使って整理してみましょう。仕様書に「半角英字で1〜10文字。10文字も受け付ける」と書かれているとします。

手順どおりに半角英字の「abcdefghij」を入力しても、「9文字以内で入力してください」と表示されました。まず、この入力値とメッセージをそのまま記録します。

図解の3つは、確認して分かった内容が異なる場合の例です。手順書の誤りが疑われる場合も、勝手に直して終わりにせず、適用される仕様と修正の必要性を担当者に確認します。

このように、画面に出た結果だけでは、修正が必要な場所までは分かりません。自分で無理に分類を確定するより、根拠と条件をそろえて相談することが次の対応につながります。

判断できないときの相談文と結果の残し方

相談文には、期待した結果と実際の結果を分けて書きます。以下は、先ほどの架空の例で使える記載例です。チームの報告書式があれば、そちらに合わせてください。

件名：名前欄で10文字が拒否される（不具合か確認したい）

対象：テスト番号 T-012／名前入力画面

発生日時・環境：［日時、テスト用URL、プログラムの版、ブラウザを記入］

開始前の条件：一般利用者用アカウントで、新規入力画面を開いた状態

操作：名前に半角英字「abcdefghij」を入力し、確認ボタンを押した

期待結果：10文字が受け付けられ、確認画面へ進む

根拠：入力仕様書［版・該当箇所を記入］の「半角英字で1〜10文字」

実際の結果：「9文字以内で入力してください」と表示され、確認画面へ進めない

確認済み：指定のテスト環境を使用。入力値に空白なし。初回と再確認1回の両方で発生

添付：入力値とメッセージが分かる画面画像

確認したいこと：今回の版では10文字を受け付ける認識でよいか。不具合として登録すべきか

まだ確認していない項目は、「未確認」と書けば大丈夫です。観察した事実と、「上限の設定が違うのかもしれない」といった推測は分けて書きましょう。

テスト結果欄はチームのルールに従います。「確認中」「保留」などが使える場合は、相談内容へのリンクや記録番号も残します。OK・NGしか選べない場合は、扱いを担当者へ確認してください。判断できない結果を、便宜上OKにして進めないことが大切です。

報告に期待結果・実際の結果・環境・操作手順などを含める考え方は、ソフトウェアテストの学習資料であるISTQBのシラバス（5.5、不具合管理）でも示されています。

よくある疑問

一度しか起きず、再現しない場合も相談してよい？

相談して大丈夫です。発生日時、初回の操作、画面画像、再確認では起きなかったことを共有します。担当者が、その時刻の処理の記録を調べる手がかりになります。再現するまで何度も操作し続ける必要はありません。

エラーメッセージが出ていなければ、正常？

正常とは限りません。たとえば、保存完了と表示されても、確認すべきデータが保存されていなければ、期待した結果と違います。エラー表示の有無だけでなく、手順書で確認するよう指定された表示や保存結果を見ます。

どこまで調べてから相談すればよい？

まずは「期待と実際の違い」「根拠」「試した条件」を整理できれば相談できます。資料が見つからない、判断に必要な権限がない、作業が止まっている場合も、その時点で共有しましょう。

調べる時間の目安は、チームの方針に合わせます。データ消失や情報の誤送信などが疑われる場合は、情報が全部そろうのを待たず、発生した事実をすぐに連絡してください。

まとめ

テストで想定と違う結果が出たときは、まず結果を保存し、期待結果の根拠、操作・データ・環境を確認します。安全に試せる場合だけ再確認し、分からない点は事実を添えて相談しましょう。

不具合かどうかを一人で言い切る必要はありません。「何を根拠に、どの条件で試し、何が起きたか」を残すことが、判断を前に進める第一歩です。

関連記事

• 初めてテストを任されたら？準備から実施・報告までの進め方：テスト作業全体の流れを確認したいときに。
• 【IT初心者向け】エラーが出たら何から確認する？慌てないための対処手順5ステップ：表示されたエラーから確認を進めたいときに。
• テストとは？意味や種類を初心者向けに具体例でやさしく解説！：テストの目的や基本を整理したいときに。
• 不具合報告の書き方｜伝わる例文とコピペ用テンプレート：確認した内容を報告にまとめるときは、例文とテンプレートを参考にしてください。
• エラーが再現しないときはどうする？記録する情報と確認ポイント：一度だけ出たエラーが再現しないときの記録・確認方法