ITパスポート 2011年 春期 問36

ソフトウェア結合テストで仕様と異なる結果が出た場合の対応【ITパスポート 解説】

正解の理由

解法ステップ

1. 結果とテスト仕様書を比較して「期待される動作」と「実際の動作」を明確にする。
2. 同じ条件で再現できるか確認する（再現手順を確定する）。
3. ログやスクリーンショット、入力データなど証拠を集める。
4. 問題を記録（バグ報告）する。報告書には再現手順、期待値、実際の値、実行環境、発生頻度を含める。
5. 開発者へ報告して修正を依頼する。修正後にテスト担当者が再テスト（修正確認）を実施する。

選択肢別の誤答解説

• ア: それまでの正常終了分も含めて、すべてのテストデータの見直しを実施する。
  • なぜ誤りか：いきなり全データ見直しは過剰で非効率です。まずは発生事象の再現・切り分けを行い、影響範囲が明らかになってから必要に応じて見直します。
• イ: テスト担当者がテストケースを修正して、再度テストを実施する。
  • なぜ誤りか：テストケース（テストの手順と期待結果）はテスト仕様書に基づきます。仕様が正しい場合にテストケースを勝手に変更すると不具合を見逃すことになります。仕様自体に誤りがある可能性があるなら、仕様の変更は関係者と合意してから行うべきです。
• ウ: テスト担当者がプログラムを修正して、テストを継続する。
  • なぜ誤りか：テスターが直接プログラム（コード）を修正するのは責任分担の観点で不適切です。勝手な修正は履歴管理や品質保証を損ない、原因追跡ができなくなります。プログラム修正は開発者が行い、テスターは修正を検証します。
• エ: 問題を記録し、開発者に修正を依頼する。
  • なぜ正しいか：テスターは問題を再現・記録して報告する役割です。開発者が原因を解析・修正し、テスターが修正後の確認（再テスト）を行うという分業が品質管理上適切です。

よくある誤解

1. 「テスターがプログラムを直しても良い」
   • 実際には、修正は開発者が実施するべきです。テスターが直すと変更履歴や責任があいまいになり、問題の原因追跡や品質管理ができなくなります。
2. 「テストに失敗したらまずテスト仕様書を変えれば良い」
   • 仕様が間違っているケースもありますが、まずは再現確認や関係者（設計者・仕様管理者）との確認を行い、合意のうえで仕様を修正する必要があります。テスターだけの判断で変えるべきではありません。
3. 「以前に正常終了したテストは無関係」
   • 以前のテスト結果が今回の不具合と関連する場合があります。影響範囲の調査は必要ですが、すべてを最初から見直すのは非効率です。まずは原因の切り分けを行い、必要な範囲を特定します。

補足コラム

• 再現手順（できるだけ具体的に）
• 期待される結果（テスト仕様書の該当箇所の引用）
• 実際の結果（エラーメッセージやスクリーンショット）
• 実行環境（OS、ブラウザ、バージョン、テストデータ）
• 発生頻度（常に起きるか、時々か）
• ログやスタックトレース（あれば）
  これらが揃っていると開発者が原因を特定しやすく、修正も速く進みます。

• テストケース：具体的な入力や操作手順と期待結果を定めたもの。
• 結合テスト（integration test）：複数のモジュールやコンポーネントを組み合わせて動作を検証するテスト。
• バグ（bug：不具合）：ソフトウェアの欠陥や誤動作。英語の "bug" から来ています。

FAQ