インスペクションで何を指摘するべきか
バグ票からひもとくインスペクションとテストのバランス
インスペクションはテストに先立って実施できる品質向上の技法です。インスペクションで見逃された欠陥はインスペクションが終わった後の開発過程の中で発見されて修正されるか、テストで発見され修正されます。場合によってはリリース後にみつかったり、みつからないまま使われなくなることもあります。インスペクションでは、見逃された欠陥すべてが開発の進行とともに修正コストが大きくなるという前提を置いています。しかし、詳しく調べていくと開発が進んでいっても修正コストがそれほど大きくならない欠陥も存在します。筆者らの研究グループでは、実際に不具合の修正コストを分析し、これらの欠陥の特徴を明らかにしようとしています。
図2はテストで発見された不具合の修正工数の傾向を可視化したものです。元データは商用の開発時に収集された約1,300件の不具合の属性と修正工数です。開発プロセスや収集した属性など詳細は文献[4]をご覧ください。なお、このデータは経済産業省の先進的ソフトウェア開発プロジェクトの開発時に、開発ベンダ各社の協力を得、筆者らの研究チームと情報処理推進機構（IPA）ソフトウェアエンジニアリングセンターとで収集したものです。
図2-1、2-2ともに、グラフの横軸は修正工数の平均、縦軸は修正工数の標準偏差（ばらつき）です。1つの点は、1つの傾向を表しており、あてはまる不具合の割合が1％以上（13件以上）の傾向17,000件を可視化したものです。右にいけばいくほど修正コストが大きくなり、上にいけばいくほど修正コストがばらついている（大きかったり小さかったりする）ことを表します。つまり、左下は修正が簡単な不具合、右上はやっかいな不具合であり、右上の領域に含まれるものが、特にインスペクションで発見すべき欠陥と言えます。
図2-2は図2-1に「修正工数が小さい」「修正工数のばらつきが大きい」「修正工数の平均が大きい」という3領域を追記したものです。この事例では「修正工数が小さい」領域（修正工数が1人時未満）に特定機能（入力値チェック機能、出力フォーマット整形機能）が含まれていました。また、「修正工数のばらつきが大きい」領域には、たまにしか再現しない不具合が含まれていました。「修正工数の平均が大きい」領域には、コーディングで混入されシステムテストで発見された不具合が含まれていました。
これらすべての傾向が、どのような欠陥を指摘すべきかを考える際に役立つわけではありませんが、役に立つものもあります。この事例では修正工数の大きな不具合として再現性の低い不具合が挙がりました。これをもとに、タイミング問題をインスペクションの観点とすることができるでしょう。また、修正工数の小さな不具合として挙がった、入力値チェック機能、出力フォーマット整形機能についてはインスペクションの優先順位を下げることができそうです。
また、この事例では修正工数の平均が小さい不具合は、1人時程度で修正、修正確認ができるものでした。修正工数がばらつく領域では、修正工数の平均が10人時程度、標準偏差は25程度というものした。修正工数の平均が大きいものとしては、システムテストでみつかった不具合で修正工数は20人時前後かかるものもありました。
インスペクションでみつけるべき欠陥は？
図2の傾向からどのような不具合をインスペクションで除去し、どのような不具合はテストで検出すべきか、その一端が垣間見えます。インスペクションで「誤字脱字等の細かいことは後回しにして」と言われたことはないでしょうか？これは図2の「修正工数が小さい」に属する欠陥であることが多いのです。インスペクションでは、見逃した場合に「修正工数のばらつきが大きい」「修正工数の平均が大きい」欠陥を指摘することが望ましいのです。
図2の中には、見逃したことによって修正工数が増えたという事実だけを表しているものもあるため、全部が全部有益な傾向ではありませんが、どのような欠陥をインスペクションで検出し、どのような欠陥をテストで検出すべきかを考えるにはよいきっかけとなります。また、平均、標準偏差の具体的数値が示されるので、インスペクションで必要となる工数と勘案しながら考えることができます。
今回、図2の傾向を抽出するために利用したツールの情報は（http://www.naist.jp/topics_pdf/admin_c89027ca8391b94b8b737512bab9432c_1207629219_.pdf）にあります。一般的に修正工数の大きい、ロジックが複雑なもの、修正範囲の大きなもの、再現性の低いもの以外にも、ソフトウエアやプロジェクト固有で修正工数が大きな欠陥をみつけることができると思います。
