プロジェクトマネージャ 2017年 午後1 問03

解答の導き方

1. 問われているのは、結合テストの「計画」ではなく「テストケース」を、単体テスト完了後に作成する理由です。本文では、結合テスト計画は内部設計工程で作成する一方、結合テストケースは単体テスト完了後に内部設計書に基づいて作成するとしています。
2. その時期に注目すると、製造時やバグへの対応時に設計内容の誤りが見つかることが少なくなく、内部設計書などを修正する運用になっています。つまり、内部設計工程で作成した設計書が、その後の作業で更新される場合があります。
3. 更新前の内部設計書を基に結合テストケースを先に作成すると、設計書の修正後にテストケースも見直す必要が生じます。単体テスト完了後に作成すれば、修正内容を反映した内部設計書を基にできるため、テストケースの作り直しなどの手戻りを減らせます。

誤りやすいポイント

• 結合テスト計画と結合テストケースの作成時期を混同しないようにします。本文では、計画は内部設計工程、ケースは単体テスト完了後です。
• 「テストの品質を高めるため」だけでは、作成時期を遅らせる理由が明確になりません。設計内容の誤りが後から見つかり、内部設計書が修正されることに結び付けて説明します。
• テストケースをプログラムそのものに基づいて作るため、と説明するのは不適切です。本文では、内部設計書に基づいて作成するとしています。

FAQ

解答の導き方

1. 問われているのは、バグが見つかったときに、なぜテストケースの実施を一時中断するのかではなく、どのようなバグが見つかった場合に中断するのかです。
2. 本文には、「タイミング誤りなどのバグが摘出された場合にはプログラムが異常終了してしまい、後続のテストが実行できない場合もある」とあります。ここから、中断が必要なのは、バグを残したままでは次のテストを進められない場合だと分かります。
3. そこで、バグの種類そのものではなく、後続テストへの影響に注目します。タイミング誤りはその一例であり、該当するのは、後続のテストが実行できないバグです。こうしたバグは、テストを続ける前に内容の確認や修正を行う必要があります。

誤りやすいポイント

• 「タイミング誤り」だけを答えると、本文に示された一例に限定されてしまいます。問われているのは、テストを中断する必要があるバグの条件です。
• 「異常終了するバグ」とだけ答えると、本文が重視する「後続のテストが実行できない」という影響が伝わりにくくなります。
• バグが見つかったら常にテストを中断すると考えないようにしましょう。本文では、後続のテストを実行できなくなる場合に一時中断するとしています。

FAQ

解答の導き方

1. 問題文では、単体テストで見つかるはずのバグが結合テストで見つかる現象を「バグの見逃し」としています。つまり、本来より後の工程でバグが発見されている状態です。
2. バグが見つかった後は、内容の確認や修正だけでなく、類似バグの調査・修正や、バグが見つかったテストケースの再実施も必要です。これらの対応が後工程に持ち越されるため、先に進んだ作業を戻ってやり直す手戻りが増えます。
3. その結果、結合テストで予定していた確認作業に加えて、バグへの対応や再テストが発生し、テスト全体の効率が下がります。したがって、E課長が問題と捉えた理由は、手戻りの増加とテスト効率の低下です。

誤りやすいポイント

• バグの見逃しを、バグの件数が増えたことだけの問題と捉えないようにします。問われているのは、単体テストでは見つからず、結合テストで見つかることによる影響です。
• 「品質が低下するから」だけでは、問題文から読み取れる具体的な影響が不足します。後工程での修正や再テストによる手戻り、テスト効率への影響まで結び付けます。
• テストの効率低下だけでなく、その原因となる手戻りにも触れると、理由をより適切に説明できます。

FAQ

解答の導き方

誤りやすいポイント

• 「内部構造」と「外部から見た入出力」の対応を逆にしないようにします。内部構造に基づくのがホワイトボックス、外部から見た振る舞いに基づくのがブラックボックスです。
• 改修箇所が他の箇所に影響していないかを確認するテストは、回帰テストの目的に関する説明です。ホワイトボックスかブラックボックスかは、テストケースを作る際の観点で判断します。

FAQ

解答の導き方

1. まず、何を減らしたいのかを確認します。本文では、単体テストで見つかるべきバグが結合テストで見つかる現象を「バグの見逃し」と呼んでいます。したがって、結合テスト完了後に確かめる対象は、結合テストで見つかったバグ全般ではなく、この「バグの見逃しと呼ぶ現象」です。
2. 次に、今回の単体テストの見直しの狙いを確認します。E課長は、改修箇所が他の箇所に与える影響を確認するテストケースを追加しています。この見直しが有効なら、単体テストでバグを発見できるようになり、後の結合テストで見つかるバグの見逃しは減るはずです。
3. そのため、結合テスト完了後には、バグの見逃しがどの程度起きたかを確認し、過去の改修案件と比べます。期待する評価結果は、今回のバグの見逃しが「過去の改修案件よりも減っている。」ことです。

誤りやすいポイント

• 結合テストで見つかったバグをすべて分析対象にすると、範囲が広すぎます。対象は、単体テストで見つかるべきだったのに結合テストで見つかったバグです。
• 追加したテストケースの数や、単体テストで見つかったバグの総数を評価結果にしないようにします。今回の見直しの成果として確認するのは、バグの見逃しが減ったかどうかです。
• 期待する結果を「バグの見逃しがなくなる」としてしまうのも誤りです。本文の期待結果は、過去の改修案件と比べて減っていることです。

FAQ

解答の導き方

1. 問われているのは、バグ密度の管理目標を設定するときに考慮した条件です。本文では、過去の同程度の難易度・規模の改修案件におけるバグ密度を参考にしつつ、「ある条件を考慮して」管理目標を設定したとあります。
2. 今回は、改修箇所が他の箇所に与える影響を確認するため、単体テストケースを追加しています。したがって、今回のテストでは、過去の案件と比べてテストケースの量が異なり、その違いが摘出されるバグの件数にも影響します。
3. ただし、テストケースの追加件数だけでは、規模の異なる機能どうしを適切に比較できません。テスト対象のプログラムが大きければ、同じ追加件数でも相対的なテスト量は小さくなるためです。
4. そこで、テスト対象の規模を表すステップ数に対し、どれだけテストケースを追加したかを考慮します。つまり、管理目標の設定に用いる条件は、単位ステップ数当たりのテストケースの追加量です。

誤りやすいポイント

• テストケースの追加件数だけを答えると、テスト対象の規模を考慮できていません。設問では、ステップ数当たりの追加量まで含める必要があります。
• バグ密度の管理目標を設定する際の条件を問われているため、テスト期間やバグ修正件数を答えないようにします。
• 過去の改修案件のバグ密度を参考にすること自体ではなく、今回追加したテストケースの量を、テスト対象の規模と関連付けて考えることがポイントです。

FAQ

解答の導き方

1. 表1には、機能Fの単体テストで「摘出バグ件数（件）」が180件、「テスト対象ステップ数（kステップ）」が12とあります。バグ密度は、摘出バグ件数をテスト対象ステップ数で割って求めます。
2. したがって、機能Fの摘出バグ密度は、$180÷12=15$件/kステップです。
3. 表1のバグ密度の管理目標は8～12件/kステップなので、算出した15件/kステップは上限の12件/kステップを超えています。このことから、想定より多くのバグが摘出されており、残りの修正や再テストに時間がかかって、遅延リスクが高まると判断できます。

誤りやすいポイント

• 修正済みバグ件数の80件だけで密度を計算しないようにします。問われている根拠は、表1の摘出バグ件数に基づくバグ密度です。
• 「残りのバグが100件ある」ことだけを根拠にしないようにします。設問では、摘出バグ密度が管理目標を超えていることを述べるのが要点です。
• 管理目標の範囲内かどうかは、下限ではなく上限と比較します。15件/kステップは、上限の12件/kステップを超えています。

FAQ