インスペクションで何を指摘するべきか
優先度つきインスペクションとは
今回は限られた時間内でインスペクションを実施することを前提に、どんな欠陥を優先して指摘すべきかを意識した、優先度つきインスペクションを紹介します。また、優先して発見すべき欠陥を決めるヒントの1つとして、バグ票に含まれる修正工数の傾向を抽出した事例を紹介します。
優先度つきインスペクションとして、Time Controlled ReadingとTest Size Based Readingの2つのリーディング技法を紹介します。Time Controlled Readingはユーザーの利用頻度に応じた時間をユースケースに割り当て、インスペクションを実施します。Test Size Based Readingは見逃した場合の修正工数が大きなものから順番に指摘します。
Time Controlled Readingは、Petersonらがユースケースベースドリーディングを拡張する形で提案している優先度つきリーディング技法です（詳細は文献[1]を参照）。元になっているユースケースベースドリーディングは、ユーザーの利用手順であるユースケースに沿ってインスペクション対象を読み進めながら、欠陥を指摘します。
Time Controlled Readingではユースケースの利用頻度に応じて、インスペクション時間を割り当てます。利用頻度は、ユーザー、開発メンバの投票やAnalytic Hierarchy Processで決めます。Analytic Hierarchy Processは、ユースケースすべてに対して2つ1組を作り、1組ずつ2つの利用頻度の差に答えていくと最終的にすべてのユースケースの利用頻度が割合で求まる方法です（詳細は文献[2]を参照）。得られた利用頻度の比率から、そのユースケースにかける時間を決めます。例えば、利用頻度が全体の20％を占めるユースケースがあれば、そのユースケースに沿ったインスペクションに全体の時間の20％を割り当てます。
Test Size Based Readingは、インスペクションで見逃された欠陥がテストで発見された場合に、修正確認に必要となるテストの規模を意識したリーディング技法です。テストが終盤に近づくにつれ（ウォータフォールであればフェーズが単体、結合、総合と進むにつれ）、修正部分の確認テストとデグレードの確認テストの規模が大きくなる欠陥があります（すべてがそうなるとは限りません）。
Test Size Based Readingでは、そのような欠陥が潜んでいる可能性のある場所からインスペクションを進めていきます。一般には、性能問題、データ構造の変更といったものがあてはまります。開発経験のある方ならば、思い当たるものがあるのではないでしょうか。
Test Size Based Readingではテスト計画書をはじめとして、見逃した場合のテスト規模を推測できるような情報を元に、潜在的なテスト規模が大きくなる欠陥から順に指摘します。図1はその指摘テンプレートとテスト規模が推測できる情報（予定テスト件数の概算）の例です。テンプレートはここ（896_1.zip/14KB）から入手できます。また、筆者らの研究グループのWebページ（http://se.aist-nara.ac.jp/html/review/formats.html）でも公開しています。
Test Size Based Readingの実際
Test Size Based Readingでは、テスト計画がたてられていることが前提であり、テスト計画には概算で予定テスト件数が集計できるものとしています。
W字モデルを採用しているウォータフォール開発やテスト駆動開発であれば、テスト計画書に準ずるデータがありますし、プロジェクト計画時点でテスト工数を見積もる際の算出根拠としてテスト計画書があると思います。また、派生開発、拡張開発であれば、ソフトウエアの過去のバージョンのテスト実施書や計画書からこれに準ずるデータをさがしてくることができるでしょう。
テスト件数の概算予定と対象ソフトウエアの構造を勘案しながら、テストで修正、変更すると、どの部分の確認テスト規模が大きくなるかを予測します。それらの部分は、多くの個所から呼び出されるライブラリであったり、性能に大きく影響するロジックであったりしますが、ソフトウエアにより異なります。
指摘した欠陥は「Test Size Basedリーディングの記録テンプレート」に従って指摘個所と指摘内容を記入していきます。欠陥を指摘している最中に、もしその欠陥を見逃してテストで発見、修正されたときに、どのくらいの確認テストが必要になったかを「削減できた確認テスト件数」として記入していけば、その指摘のインパクトを計れます。インスペクションを進めながら、その質を計ることができますので、どのような欠陥を指摘すべきかが進行中に明確になるというメリットもあります。Test Size Basedリーディングの詳細は文献[3]にあります。
指摘すべき欠陥に優先順位をつけたインスペクションは時間制約のある開発では、有効に働きます。また、紹介した2つ以外にも優先順位づけの方法が考えられます。次のページでは、どのような欠陥を指摘すべきかを検討するときのヒントとなるバグ票の分析事例を紹介します。
