高速リリース！追いつめられています。
じゃあ何故こんな記事書いているかというと、問題を作ろうとすると、いやでもシラバスをじっくり読むからなんですね。公開するからには、できるだけ間違いを避けたいし、あまりバカがばれるのもちょっと・・・ということで、ほそぼそやってます。
3.4～3.6の過去のエントリはココにあります。 www.kzsuzuki.com
非模擬問題
3.4 テストの見積りから
見積もりはほんと、PMPとかぶってます。
今後も積極的に「直感」に基づく見積もりをがんばります。
(A)1, 2, 3
(B)1, 3
(C)2
(D)2, 3, 4
- 広帯域デルファイ法（wide-band delphi）が、アンケートベースの従来のデルファイ法と大きく違う点は、選ばれた「専門家」同士のコミュニケーションがはるかに多いことである。
- 見積もりは、結果だけでなく、前提とした各条件も提示する必要がある。
- 組織で蓄積したテストに関するデータ、たとえば規模に対する平均的なテストケース数、欠陥数は、見積もりの際の手がかりになる。
- 3点見積もりにおいては、楽観値・悲観値・最頻値の相加平均値を取る。
答えは(A)です。
1.についてはWikipediaから持ってきました（堂々）！ 4.の3点見積もりでは、楽観値・悲観値1に対し、最頻値には4の重みをつけることになります。
「楽観値」のtypoで「達観値」と出てきました。これには重みを10くらい与えてもいいかも知れません。
「3.5 テスト計画のスケジュール」から
(A)1, 2, 3
(B)2, 3
(C)1, 2, 4
(D)4
(E)正しいものはない
- モニタリングの対象として、「欠陥」「テスト」「カバレッジ」「確信度合い」は、組織で定めた特定の方法で測定・報告することが多いが、「プロダクトリスク」については主観的になりがちである。
- MTBFはハードウェアを対象としたメトリクスであり、ソフトウェアには不向きである。
- テストのレポートで重点をおくべき対象は一定ではなく、たとえば相手がビジネスマネジャーであれば、欠陥についての詳細情報が重要になる。
- モニタリングの結果に基づくテスト終了基準を緩和・強化の判断は、プロジェクトマネジャーが関与すべきでなく、テストマネジャーが独立した立場で判断すべきである。
答えは(E)です。
1.について、主観的になりがちなのは確信度合いです。何しろ「確信」ですから。プロダクトリスクのメトリクスとして、残存するリスク、軽減したリスクの数といったものがあります。
ただ、リスクの数の母数自体が、最初にリスクを洗い出した人の経験や能力に依存するところがあるので、「リスクの定量化が常に客観的」というのはちょっと語弊がありますね。
2.の平均故障間隔は、ソフトウェアに対しても適用できます。運用が始まってからは、ハードウェアと同様、経過時間tの関数として表現できるでしょうが、テスト期間中はtの代わりに、消化したテストケース数などを用いるなど工夫が必要だと思います。
3.について、ビジネスマネジャーとしては、プログラムの技術的な情報よりも、プロダクトのスケジュール的・品質的なリスクを把握しておきたいでしょう。
4.は、テストマネジャーだけでなく、プロジェクトマネジャーなど各ステークホルダーとのコンセンサスが必要になります。
