💡 このページでわかること
- テスト業務の全体的な流れ
- テストを始める前に確認すること
- テストケースの見方・準備のしかた
- テストを実施するときの進め方
- NGや不具合を見つけたときの対応
- テスト完了後の報告方
「明日からこの機能のテストお願いね」
そう言われても、テストをやったことがなければ、何から手をつければいいのか分かりませんよね。
「とりあえず画面を操作すればいいの？」
「何を見てOK・NGを判断するの？」
「不具合を見つけたらどう報告すればいい？」
初めてテストを任されたときは、分からないことがたくさんあります。
テストの基本は、仕様やテストケースと照らし合わせながら、システムが想定どおりに動くか確認することです。
この記事では、初めてテスト業務を担当する人向けに、テストを任されてから完了報告するまでの流れを6つのSTEPで解説します。
実際の仕事と照らし合わせながら、順番に見ていきましょう。
全体の流れ｜テストは「準備」「実施」「報告」の3段階
テスト業務は、大きく「準備 → 実施 → 報告」の3段階で進みます。
細かいルールはプロジェクトによって異なりますが、まずはこの全体像を押さえておきましょう。
ここからは、実際の仕事の流れに沿って6つのSTEPで詳しく見ていきます。
STEP1｜テスト対象と自分の担当範囲を確認する
〇何を・いつまでに・誰へ報告するのか確認する
テストを依頼されたら、いきなり操作を始めるのではなく、まず作業内容を確認しましょう。
最低限、次の項目を確認します。
- 何をテストするのか：機能名・画面・今回変更された箇所など
- どこまでがテスト対象なのか：対象機能だけか、関連する機能まで確認するのか
- いつまでに終わらせるのか
- 完了したら誰に報告するのか
ここが曖昧なまま作業を始めると、
「そこは今回のテスト対象ではなかった」
「関連する画面も確認してほしかった」
といった認識違いが起こることがあります。
分からないところがあれば、最初に確認しておきましょう。
〇自分がどこまで担当するのかも確認する
「テストをお願いします」と言われても、担当する範囲はプロジェクトによって異なります。
たとえば、
- テストケースの作成から担当する
- 用意されたテストケースの実施だけ担当する
- 不具合報告まで担当する
- 修正後の再テストまで担当する
などがあります。
初めて担当するときは、「自分はどこからどこまでやれば完了なのか」も確認しておくと安心です。
〇仕様書や設計書などの資料を確認する
テストでは、実際の結果が正しいかを判断するために、「本来どう動くべきなのか」を知る必要があります。
その判断材料になるのが、設計書・画面仕様書・テスト仕様書・今回の改修内容が分かる資料などです。
資料が見つからない場合や、どの資料を見ればよいか分からない場合は、担当者に確認しましょう。
口頭で説明を受けた場合も、後から確認できるようにメモを残しておくと安心です。
STEP2｜テストケースを確認・準備する
〇テストケースとは？
テストケースとは、簡単にいうと、
「何を確認するために、どんな操作をして、どうなればOKなのか」
を1件ずつ整理したものです。
たとえばログイン機能なら、次のようなテストケースが考えられます。
| No. | 操作・条件 | 期待する結果 |
|---|---|---|
| 1 | 正しいID・パスワードでログインする | ログインできる |
| 2 | 間違ったパスワードでログインする | エラーメッセージが表示される |
| 3 | IDを空欄にしてログインする | 必須項目の警告が表示される |
実際の現場では、Excelやスプレッドシート、専用のテスト管理ツールなどで管理されていることがあります。
〇すでにテストケースがある場合
テストケースが用意されている場合は、いきなり実施するのではなく、まず全体に目を通しましょう。
特に確認したいのは、
- 操作手順が理解できるか
- 必要なテストデータが分かるか
- 期待結果が理解できるか
- 自分では判断できない項目がないか
です。
分からない状態のままテストを始めると、途中で作業が止まりやすくなります。不明点は、できるだけ実施前に確認しておきましょう。
〇自分でテストケースを作成する場合
自分でテストケースを作る場合は、仕様書や設計書から「確認する必要がある動作」を1つずつ洗い出します。
たとえば、
『パスワードを入力せずにログインボタンを押した場合、「パスワードを入力してください」と表示する』
という仕様があれば、
- パスワードを空欄にする
- ログインボタンを押す
- 指定されたメッセージが表示されることを確認する
というテストケースを作ることができます。
テストでは正常な操作だけでなく、間違った入力なども確認します。これらを「正常系」「異常系」と呼ぶことがあります。
自分でテストケースを作る場合は、仕様に合わせて両方の観点を確認しましょう。
STEP3｜テスト環境・データを準備する
〇どの環境でテストするのか確認する
システム開発では、本番環境とは別にテスト環境や検証環境などが用意されていることがあります。
呼び方はプロジェクトによって異なるため、テストを始める前に「今回どの環境を使うのか」を確認しましょう。
間違った環境で操作すると、正しいテスト結果が得られないだけでなく、環境によっては他の作業へ影響する可能性もあります。
〇今回の修正内容が反映されているか確認する
環境が合っていても、今回テストするプログラムや設定がまだ反映されていないことがあります。
そのため、
- テスト対象の修正が反映済みか
- 必要なデータパッチなどが適用済みか
- テストを開始してよい状態か
も確認しておきましょう。
結果がおかしいと思ったら、システムの不具合だけでなく、そもそも修正内容が環境へ反映されているかも確認ポイントの1つです。
〇テストデータを準備する
テスト内容によっては、特定の条件を持ったデータが必要になります。
たとえば、
- ログインできるユーザー
- 権限の異なるユーザー
- 特定のステータスになっているデータ
- エラー確認用のデータ
などです。
テストデータがすでに用意されているのか、自分で作成するのかを事前に確認しましょう。
〇必要なツール・アカウントを準備する
テストに必要なアカウントやツールも、実施前に確認しておきます。
たとえば、
- テスト環境へログインするアカウント
- VPN
- ブラウザ
- DB・ログ確認用のツール
- テスト結果を記録するファイル
- エビデンスの保存場所
などです。
テスト当日になって「アカウントがない」「アクセス権限がない」とならないよう、事前に準備しておきましょう。
STEP4｜テストを実施して結果を記録する
〇テストケースに沿って1件ずつ実施する
準備ができたら、実際にテストを始めます。
基本的にはテストケースに書かれている手順に沿って、1件ずつ実施していきます。
自己判断で、
「この操作は関係なさそうだから飛ばそう」
「こっちの方法でも同じ結果になるから大丈夫だろう」
と手順を変更しないようにしましょう。
操作内容が変わると、テストケースで確認したかった条件自体が変わってしまう可能性があります。
手順に疑問がある場合は、勝手に変更せず担当者へ確認します。
〇期待結果と実際の結果を見比べる
操作したら、期待する結果と実際の結果が一致しているかを確認します。
たとえば、
『期待結果：「パスワードを入力してください」と表示される』
のであれば、単に何らかのエラーが表示されたからOKではありません。
表示されるメッセージの内容まで確認します。
「なんとなく動いているからOK」ではなく、テストケースに記載された期待結果と照らし合わせて判断することが大切です。
〇結果はその場で記録する
テスト結果は、
- 期待どおり → OK
- 期待結果と異なる → NG・要確認
- テストできなかった → 未実施
などで記録します。
表記方法はプロジェクトによって異なるため、既存のルールに従いましょう。
結果は後からまとめて書かず、1件実施するごとに記録するのが基本です。記憶違いや記録漏れを防ぐことにつながります。
〇必要に応じてエビデンスを残す
プロジェクトによっては、テストを実施した証拠として、
- 画面のスクリーンショット
- DBのデータ
- ログ
- 出力されたファイル
などを保存することがあります。
このようなテスト結果の証拠を、現場ではエビデンスと呼ぶことがあります。
エビデンスの取り方や保存場所にはプロジェクトごとのルールがあるため、テストを始める前に確認しておきましょう。
STEP5｜NGや不具合を見つけたら報告する
〇NG＝必ずシステムの不具合とは限らない
テスト結果が期待と違った場合でも、すぐに「システムの不具合」と判断するのは避けましょう。
原因はシステムの不具合だけでなく、テスト手順・データ・環境・古いテストケースなどにある可能性もあります。
まずはテスト手順やデータ、仕様を確認し、判断できない場合は自己判断でOKにしたり不具合と決めつけたりせず、担当者へ相談しましょう。
〇再現できるか確認する
再実行して問題ないテストであれば、同じ手順でもう一度操作し、同じ現象が発生するか確認します。
ただし、データを更新・削除するテストなど、何度も実施すると状態が変わるケースもあります。
再実施してよいか分からない場合は、先に担当者へ確認しましょう。
〇不具合・NG報告に書く項目
NGや不具合の可能性がある事象を報告するときは、できるだけ状況が分かるように整理します。
たとえば、
- 発生した機能・画面
- 対象のテストケース
- どんな操作をしたか
- 使用したテストデータ
- 期待していた結果
- 実際に発生した結果
- 再現するかどうか
- 必要に応じてスクリーンショットやログ
などです。
〇再現手順は具体的に書く
不具合報告では、誰が見ても同じ操作を再現できることが大切です。
悪い例
『ログインでエラーが出ました。』
これだけでは、どのような条件・操作で発生したのか分かりません。
良い例
『IDに「test123」を入力し、パスワードを空欄のままログインボタンを押したところ、「システムエラー」が表示されました。
仕様上は「パスワードを入力してください」と表示される想定です。』
「自分がやった操作を、別の人がそのまま再現できるか」を意識して書きましょう。
STEP6｜テスト結果をまとめて完了報告する
すべてのテストケースを実施したら、結果をまとめて担当者へ報告します。
たとえば、
- 実施したテストケース数
- OK件数
- NG件数
- 未実施件数
- NGだった項目の内容
- 未実施項目がある場合はその理由
などを伝えます。
たとえば、
『全20件のテストを実施しました。
OK：18件
NG：2件
NGの2件については不具合管理表へ登録済みです。』
のようにすると、状況が分かりやすくなります。
「全部終わりました」だけでなく、実施件数と結果が分かるように報告することがポイントです。
終わらない可能性があれば早めに相談する
テストを進めている途中で、
「このままだと期限までに終わらないかもしれない」
と分かった場合は、完了予定時刻になってからではなく、早めに相談しましょう。
たとえば、
『現在20件中10件まで完了しています。1件あたりの確認に想定より時間がかかっているため、このままだと本日中の完了が難しい可能性があります。』
と途中で共有できれば、担当者側も優先順位やスケジュールを調整できます。
テストに限らず、遅れそうだと分かった時点で共有することが大切です。
初心者がテストするときに注意したいポイント
初めてのテストでは、特に次の点を意識しましょう。
- テスト対象・環境を最初に確認する
- 自己判断で手順を変更しない
- 結果はその場で記録する
- 判断に迷ったら早めに確認する
- 必要なエビデンスを残す
また、テスト環境のデータだからといって、自由に変更・削除してよいとは限りません。
同じデータを他の人が使用していることもあるため、データを追加・変更・削除する場合は、プロジェクトのルールを確認しましょう。
よくある疑問
Q. テストケースがない場合、自分で作るしかないですか？
A. 職場やプロジェクトによって異なります。
自分でテストケースを作る場合もあれば、担当者や設計者が作成する場合もあります。
テストケースが見つからない場合は、まず「今回のテストケースはどこにありますか？」と確認しましょう。
自分で作成するよう依頼された場合は、仕様書や設計書から確認する動作を1つずつ洗い出していきます。
初めて作成する場合は、先輩や担当者にレビューしてもらうと安心です。
Q. 仕様書と実際の動きが違ったらどうすればいいですか？
A. どちらが正しいかを自分だけで判断せず、担当者へ確認しましょう。
システムに不具合がある場合もあれば、
- 仕様変更が資料へ反映されていない
- テストケースが古い
- 見ている仕様書が違う
といった可能性もあります。
「仕様書にはこう書かれていますが、実際にはこう動きました」と、両方の情報を整理して確認するとスムーズです。
Q. テストにはどれくらい時間をかければいいですか？
A. テストケースの件数や機能の複雑さによって異なります。
最初に期限を確認し、実際に進めてみて予定より時間がかかりそうであれば、早めに担当者へ相談しましょう。
Q. 不具合を見つけたらすぐ報告したほうがいいですか？
A. 基本的には、状況を整理したうえで早めに共有しましょう。
特に、他のテストにも影響しそうな不具合や、テストを続けられないような問題の場合は、すべてのテストが終わるまで待たずに報告したほうがよい場合があります。
報告するタイミングにルールがあるプロジェクトでは、そのルールに従いましょう。
まとめ｜テストは「準備・実施・報告」の順番で進めよう
初めてテストを任されたら、まず「準備 → 実施 → 報告」の3段階で考えてみましょう。
準備では対象・テストケース・環境を確認し、実施では期待結果と照らし合わせながら1件ずつ結果を記録します。そして、NGや判断に迷うことがあれば状況を整理して報告・相談します。
最初からすべてを完璧に判断する必要はありません。
まずは「このテストでは何を確認するのか」を理解し、目の前のテストケースを1件ずつ丁寧に進めていきましょう。