テストの進め方
作成したプログラムが仕様通りに動作するかを確認するテスト業務の進め方を学びます。
テストとは
テストとは、作成したプログラムが仕様通りに動作するかを確認する作業です。
テストの目的
- バグを発見する
- 品質を保証する
- 仕様通りに動くことを確認する
テストの種類
| 種類 | 内容 | 実施者 |
|---|---|---|
| 単体テスト | 個々の機能をテスト | 開発者 |
| 結合テスト | 機能を組み合わせてテスト | 開発者/テスター |
| システムテスト | システム全体をテスト | テスター |
| 受け入れテスト | ユーザー視点でテスト | ユーザー/テスター |
テストの流れ
flowchart LR
A["テスト計画"] --> B["テスト設計"]
B --> C["テスト実施"]
C --> D["結果報告"]
各ステップを順番に進めることで、漏れなくテストを実施できます。
Step 1:テスト仕様書を理解する
テストを実施する前に、テスト仕様書を正確に理解することが重要です。
テスト仕様書の構成
| 項目 | 内容 |
|---|---|
| テスト目的 | 何を確認するか |
| テスト対象 | どの機能をテストするか |
| テスト条件 | 前提条件、入力データ |
| 期待結果 | 正しい結果は何か |
| 実施手順 | どのようにテストするか |
なぜテスト仕様書を理解する必要があるのか?
テスト仕様書を読まずに始めると、「何が正しい結果か」が分からないため、バグを見落とします。また、同じテストを何度も実施したり、確認すべき項目を抜かすという失敗も生じます。
確認すること
- 何をテストするのか
- どうやってテストするのか
- 何が正しい結果なのか
Step 2:テスト環境を準備する
テストを実施する前に、環境が正しく準備されていることを確認します。
確認すること
- テスト環境にアクセスできるか
- テストデータは準備されているか
- 必要なツールはあるか
注意点
- 本番環境でテストしない
- テストデータを用意する
- 環境が正常か事前に確認
本番環境でのテストは厳禁
本番環境でテストすると、テスト中のエラーやデータが実際のユーザーに影響を与えます。必ずテスト環境で実施してください。
Step 3:テストを実施する
テスト仕様書に従って、実際にテストを実行します。
テスト実施の手順
- テスト仕様書の手順に従って操作
- 実際の結果を記録
- 期待結果と比較
- 合格/不合格を判定
- 証跡(スクリーンショット等)を残す
記録すること
| 項目 | 内容 |
|---|---|
| 実施日時 | いつ実施したか |
| 実施者 | 誰が実施したか |
| 結果 | 合格/不合格 |
| 実際の結果 | 何が起きたか |
| 証跡 | スクリーンショットなど |
| 備考 | 気づいた点 |
なぜ記録が必要なのか?
記録があれば、後から同じバグが報告されたときに前回のテスト結果と比較できます。また、「どの環境でテストしたのか」が明確になり、不具合の原因特定にも役立ちます。
テスト観点
正常系
正しい入力が与えられたときのテスト
- 正しい入力で正しい結果が出るか
- 想定通りの操作で想定通りに動くか
異常系
異常な状況が起きたときのテスト
- 不正な入力でエラーになるか
- エラーメッセージは適切か
- エラー後に復帰できるか
境界値
範囲の端(最小値・最大値)でのテスト
多くのバグは、範囲の境界で発生します。例えば、「0〜150の年齢を入力」という仕様なら、-1、0、150、151という「ちょうど境目の値」をテストすることで、バグを発見しやすくなります。
例:年齢入力(0〜150まで有効)
| 入力値 | 期待結果 | 説明 |
|---|---|---|
| -1 | エラー | 範囲外(下限の1つ下) |
| 0 | 正常 | 下限値 |
| 1 | 正常 | 下限の1つ上 |
| 149 | 正常 | 上限の1つ下 |
| 150 | 正常 | 上限値 |
| 151 | エラー | 範囲外(上限の1つ上) |
境界値テストのコツ
範囲が「0〜150」なら、実際にテストする値は「-1, 0, 1, 149, 150, 151」のように「範囲外の隣・範囲内の隣・範囲の端」の値を組み合わせてテストします。これにより、プログラマーの「<」と「<=」の書き間違いといった細かいバグを発見できます。
Step 4:不具合を報告する
テスト中に不具合(バグ)を見つけたら、わかりやすく報告することが重要です。
不具合報告に含めるべき内容
| 項目 | 役割 |
|---|---|
| 不具合概要 | 何が問題か、一目で分かるように |
| 再現手順 | 他の人が同じバグを確認できるように |
| 期待結果 | 本来どうなるべきか |
| 実際の結果 | 実際に何が起きたか |
| 環境情報 | ブラウザ、OS、テスト環境など |
| 証跡 | スクリーンショットやログ |
報告の例
## 不具合概要
ユーザー登録時、メールアドレスのバリデーションが動作しない
## 再現手順
1. ユーザー登録画面を開く
2. メールアドレス欄に「test」と入力
3. 登録ボタンをクリック
## 期待結果
「メールアドレスの形式が正しくありません」エラーが表示される
## 実際の結果
エラーなしで登録処理が実行される
## 環境
- ブラウザ:Chrome 120
- 環境:開発環境
## 証跡
(スクリーンショット)
報告のポイント
- 再現手順を明確に:他の人が同じ手順で再現できるように、ステップバイステップで書く
- 期待結果と実際の結果:何が問題かを明確に区別する
- 証跡を残す:スクリーンショットやログにより、言葉だけでは伝わない情報を共有する
なぜわかりやすい報告が必要か?
曖昧な報告だと、プログラマーが「それ、再現できないんですけど…」と時間を使ってしまいます。最初から「再現手順が明確」「証跡がある」という報告をすれば、プログラマーはすぐにバグ修正に取りかかれます。
テストを成功させるコツ
仕様を理解してからテストする
何が正しい動作かを理解していないとテストできません。
- 仕様書を読み込んでからテストを始める
- 不明な点は事前に確認する
機械的にならない
テスト仕様書に書いていることだけをやるのではなく、ユーザー視点で考えましょう。
- 仕様書に書いていないことも気づいたら確認
- 「ユーザーならこう使うかも」を考える
- 違和感があれば報告
証跡をしっかり残す
証跡があれば、後から確認できます。
- 後から確認できるように
- 不具合の再現に役立つ
- 品質の証明になる
よくある失敗と対策
| 失敗パターン | 原因 | 対策 |
|---|---|---|
| 正常系しかテストしていない | 異常系を見落とす | 異常系・境界値も意識する |
| 再現手順が曖昧 | 報告が不十分 | 他の人が再現できるよう詳細に書く |
| 証跡を残していない | 後で確認できない | 必ずスクリーンショットを取る |
| 本番環境でテストした | 環境確認不足 | テスト環境を確認してから実施 |
まとめ
テストを進めるときの重要なポイント:
- テスト仕様書を理解してから実施する
- テスト環境が正しく準備されていることを確認する
- 正常系・異常系・境界値を意識してテストする
- 結果を正確に記録する
- 不具合は再現手順を明確にして報告する
- 証跡を残す
これらのポイントを押さえることで、効果的なテストが実現でき、品質の高いソフトウェアが完成します。