品質を定量的に把握するテンプレート

障害処理票の使い方

　「第3回：機能をモレなくテストするテンプレート（http://www.thinkit.co.jp/article/140/3/）」では単体テスト、「第4回：要件をモレなくテストするテンプレート（http://www.thinkit.co.jp/article/140/4/）」では結合テストと続けてテストフェーズのドキュメントテンプレートを紹介しました。

　その中で出た共通の話題として、品質を把握する際の「定量的な分析」がありました。今回はテストフェーズのまとめとして、定量的な分析にポイントを絞り、品質管理を行うためのテンプレートを解説します。また、顧客側での品質チェックフェーズである受入テストについても、テンプレートとともに、そのフェーズに開発側がどのようにかかわるべきか述べたいと思います。もちろん、今回のテンプレートもダウンロードして活用することができるようにしています。

　早速、「DUNGEON」の「障害処理票」（図1）と「障害管理一覧」を見てみましょう。障害処理票と障害管理一覧のフォーマットは、こちら（http://www.thinkit.co.jp/images/article/140/5/14051.zip）からダウンロードできます（14051.zip/443 KB）。

　障害処理票のフォーマットは単票形式で、1つの障害につき1枚起票するルールとなっています。また、テストフェーズ全般で使用できるよう、汎用的に作成しており、単体、結合、総合など、どのテストなのかをヘッダ左部分の項目で選択するようになっています。

　障害が発生した場合、障害処理票の「障害内容」欄に、その現象を記載します。その欄を確認する調査・修正担当者がすぐわかるように記載することは、おそらく多くの人が心がけていることでしょう。

　一方おろそかにしがちなのが、原因分析です。これを怠ると同じようなバグが出続けたり、次の開発時に同じ過ちを繰り返します。とはいっても、スケジュールに追われていると、原因分析を後回しにしてしまいがちです。いざ後でやるとなると、バグが大量にある場合、1つ1つの現象を思い出したり、それをすべて分析しなおすのに相当な労力がかかるため、結局は断念してしまう傾向があります。

　したがって、原因分析もバグ検出時に随時行うこととし、そのようなスケジュールをたてておきましょう。原因の記載は、フリー入力欄以外に分類欄を設けてあり、障害の原因分類をしておくことで、後にグラフ化し、分析することが可能になります。

そのプロジェクトはいつ「鎮火」するのか？

　分析時には「障害管理一覧」を使用します。「障害管理表」シートにて「障害票の取込実行」ボタンを押してみましょう（Excelのマクロを有効にする必要があります）。任意のフォルダを指定するダイアログが表示されますので、「障害処理票」が保存されているフォルダを選択すると、フォルダ内のファイルを自動収集し、一覧管理することができます。また「品質見解報告書」シート上で原因分析のグラフが自動作成され、内部レビュー時や顧客への品質報告時に使用することができるようになっています。

　「品質見解報告書」シート上で特に重要なのは、前回少し紹介した「障害収束率経過表」のグラフです。「障害収束率経過表」シートにて「障害管理表シートより反映」ボタンを押下することによって自動作成され、「品質見解報告書」シートにも表示されるようになっています。

　このグラフは縦軸が件数、横軸が日付となっており、日々のバグ発生件数とバグ改修件数がプロットされることで、2種類のグラフが表現されています。バグ発生件数の線がテスト日程の前半に上昇し、その後、日を追うごとになだらかになって収束しているかという点と、バグ改修件数の線がバグ発生件数の線に追いついているか、つまりバグの残件数がたまっていってないかという点の2点を一目で把握することができます。

　よく品質の悪いプロジェクトは「火事」に例えられて話題にされます。プロジェクトの途中であっても、このグラフを見れば、その「火事」が「鎮火」に向かっているのかがわかります。もし「鎮火」しないのならば、改修要員補充などの対策が必要であることがわかります。