3.4~3.6は、テストの見積り・スケジューリングです。
3.4 テストの見積り
「その作業にどの程度の時間がかかるか」というのは、テストに限らずどんな活動にでも現れる仕事。重要な点は以下です。
見積りの対象は、「実行」だけでない
当然ながら、テストプロセスすべてです。たとえばテスト環境の準備は、いつだって計画以上に時間を要するものです。
見積りの前提条件や仮定は明確にし、残す
残しておかないと、条件が変わったときに再見積りができません。一般的な前提条件の例は以下。
- 求められる品質レベル
- システムのサイズ
- 過去のテストにおける実績
- 人的リソースの可用性
- 物的リソースの可用性
見積りの方法はたくさんある
一番簡単なのは、「直感」・・・。これが許される組織ってあるんですかね。「ざっくり1ヶ月!」とかってことですよね。
ボトムアップで積み上げるものとして、代表的なものがWBS。アクティビティレベル(最大80時間程度とされる)まで分解されていれば、あとは積算するだけですね。トップダウンでは、過去の経験に基づく見積りがあります。
他にも、組織に準備された見積りテンプレートに従うものや、楽観値・悲観値・最頻値にそれぞれ係数1・1・4をかけて6で割った3点見積りなどの手法があります。
TPA(Test Point Analysis)という手法もあるそうで、少しだけ調べてみました。
コチラのサイトによると、対象とするソフトウェアやテストプロセスに関する要因、たとえばソフトウェア規模や複雑度、人的要因や環境的要因などを数値化し、重み付けしてポイントを算出するという手法のようです。流し読みしただけで間違っているかも知れないので、別の場所で勉強し、まとめようと思います。
コチラのサイトによると、対象とするソフトウェアやテストプロセスに関する要因、たとえばソフトウェア規模や複雑度、人的要因や環境的要因などを数値化し、重み付けしてポイントを算出するという手法のようです。流し読みしただけで間違っているかも知れないので、別の場所で勉強し、まとめようと思います。
3.5 テスト計画のスケジュール
これもテストに限った話ではありませんが、見積りやスケジュールをより正確なものにするため、情報は常に外に出し、また外からの情報を受け取れるようにしておくこと。特に、プロジェクト・システム・ソフトウェア・テスト工程に関するリスクの情報が重要です。
3.6 テスト進捗のモニタリングおよびコントロール
進捗を把握するための5つの要素と、そのモニタリングのためのメトリクスの説明です。
5つのモニタリング要素とは、プロダクトリスク・欠陥・テスト・カバレッジ・確信度合い(Confidence)。この5つは、大まかに3つに分けられそうです。
5つのモニタリング要素とは、プロダクトリスク・欠陥・テスト・カバレッジ・確信度合い(Confidence)。この5つは、大まかに3つに分けられそうです。
- テストの進捗:テスト
- ソフトウェアの品質:プロダクトリスク、欠陥、確信度合い
- テストの質:カバレッジ
テストの進捗
「テスト」のメトリクスは、テストケースの消化予定/実績件数や、所要時間の予定/実績比較などですね。この分析結果は組織の資産となるでしょう。
ソフトウェアの品質
「プロダクトリスク」と「欠陥」のメトリクスは単純です。いくつ見つけていくつ解決したか。「欠陥」については、欠陥の修正に平均どの程度の時間を要しているかというものもあり、これはテストの進捗に分類できるかも知れません。
テストの質
欠陥の摘出が少ないだけでは高品質とは言えません。「確信度合い」は、欠陥が少ないことに加え、テストの質が良いことがあって初めて、高くなるものでしょう。
計画から逸脱した場合のコントロール方法としては、人的・物的資源の追加や、リスケジュール、テスト終了基準の再検討などがあります。個人的には最後のものは、大抵の場合、単なるナシクズシにしかならないと思います。