問36
頻出度★★★
テスト担当者がソフトウェア結合テストを実施したところ, 実行結果がテスト仕様書の記述と異なっていた。テスト担当者の対応として, 適切なものはどれか。
平成23年度 特別試験 ITパスポート試験 問36
マネジメント系システム開発技術 › システム開発技術
この問題の解説と、これまでの解答の記録です。
解説
問 36
不正解ア
「それまでの正常終了分も含めて, すべてのテストデータの見直しを実施する」は誤り。今回発見されたのは特定のテストケースにおける期待結果との差異であり、まず行うべきはその事実の記録と開発者への修正依頼である。正常終了したテストケースまで含めて全テストデータを一律に見直すのは、差異の原因究明にも修正にも直結しない過剰な対応で、工数を浪費しテストのスケジュールを不必要に遅らせる。仮にテストデータ全体の妥当性に疑いが生じた場合でも、それは原因分析の結果を受けて責任者が判断し指示することであり、差異を1件見つけた時点でテスト担当者が独断で始める対応ではない。
不正解イ
「テスト担当者がテストケースを修正して, 再度テストを実施する」は誤り。テスト仕様書とテストケースは、合意された基準として不具合の有無を判定するものさしであり、実行結果が合わないからといってテスト担当者が独断でものさしの側を書き換えてしまえば、本来検出されるべきプログラムの不具合がそのまま見逃され、隠蔽されることになる。仮に原因がテストケースの記述誤りであったとしても、その事実を記録し、責任者のレビューと承認を経て正式な変更手続 (構成管理) の中でテスト仕様書を改訂すべきであって、担当者限りで修正して再実行してよいものではない。
不正解ウ
「テスト担当者がプログラムを修正して, テストを継続する」は誤り。プログラムの修正は開発者の職務であり、テスト担当者が行うとテストする人と直す人が同一になってテストの独立性・客観性が失われる。さらに、記録も承認もないまま担当者がソースコードに手を入れれば、構成管理 (バージョン管理) の統制が崩れ、どの版に何の修正が入ったのかを追跡できなくなる。修正が別の箇所に副作用を及ぼしても気付けず、不具合の原因分析や品質の統計 (障害の件数や傾向) も残らない。発見した問題は自分で直さず、記録して開発者に差し戻すのが原則である。
- エ
正解 正解はエ「問題を記録し, 開発者に修正を依頼する」。ソフトウェア結合テストは、単体テストを終えた複数のモジュール (プログラム) を組み合わせ、モジュール間のインタフェースや連携が仕様どおりに動くかを確認する工程である。ここで使われるテスト仕様書には、テストケースごとに入力データ・実行手順・期待結果があらかじめ定められており、実行結果が仕様書の記述と異なるということは、期待結果と実際の結果が食い違った、すなわち不具合 (障害) の疑いを発見したということを意味する。このときテスト担当者に求められる対応は次の2つである。第一に、事実を正確に記録すること。いつ・どのテストケースで・どんな入力データを与え・期待結果は何で・実際にはどうなったのか・再現手順はどうかを障害票 (不具合報告書、バグ票) にまとめて残す。第二に、その障害票を開発者に渡して修正を依頼すること。原因がプログラムの誤りなのか、テストケースや仕様書の側の誤りなのかを判断して直すのは開発者・責任者の役割であり、修正後に改めてテスト担当者が確認テストと回帰テストを行う。このように、発見する人 (テスト担当者) と直す人 (開発者) を分ける役割分離こそが、テストの客観性と品質記録の信頼性を支えている。エはこの流れをそのまま述べており適切である。
ここがポイント
- テスト工程では、テストを実施する人 (テスト担当者) とプログラムを修正する人 (開発者) の役割を分離するのが原則。テスト担当者は期待結果と実行結果の差異を発見したら、再現手順・入力データ・期待結果・実際の結果を障害票 (不具合報告書) に記録し、開発者に修正を依頼して、修正版に確認テストと回帰テストを行う。自分でプログラムを直したりテストケースを書き換えたりしてはならない。
- ソフトウェア結合テストは、単体テストを終えたモジュールを組み合わせ、モジュール間のインタフェースや連携を検証する工程 (単体テスト → 結合テスト → システムテスト → 運用テストの流れ)。テスト仕様書に定めた期待結果が合否の判定基準であり、これを担当者が独断で変更すると不具合の隠蔽につながる。また記録が残らなければ品質管理も構成管理も成り立たない。
用語