機能をモレなくテストするテンプレート

管理者の立場での品質チェック

　前項で述べた運用手順について、弊社の例を図3に紹介しますので参考にしてください。
さて、この図の最後にある「リーダーチェック」での当フォーマット使用法も解説しましょう。

　プロジェクト管理者としての立場で品質を見る場合、小規模であればでき上がったプログラムを1つ1つチェックすることも可能ですが大規模案件の場合、そうはいきません。ではどうするのかというと、単体テスト結果報告書をチェックします。

　まず、その報告書が定量的に結果を把握できるようになっていれば、そのデータを品質の判断基準とします。また、エビデンスを見て精度を確認します。この2点が怪しい場合、担当者にヒアリング、再テストといった手順を踏みます。再テストの結果次第では、類似機能またはその担当者の全作成プログラムについても再テストに踏み切る場合があります。このような流れで管理者は品質をチェックしますので、まずは、その対象を選定するための最初の判断材料として定量的なデータが必要なのです。

　当フォーマットでは、表紙さえ見ればテストの規模と品質がわかるようになっています。その機能はどの処理が重たいのか、バグ発生率が高いのかなどが数値として一目で把握できます。

　各集計項目のうち特に着目したいのは、「想定バグ数」と実際に発生した「バグ数」との関係です。「想定バグ数」は、対象プログラムの難易度によってチェック項目数にバグ発生予想係数を掛け、算定したものです。この「想定バグ数」に対してどの程度の「バグ数」が検出されているかを、この表紙で判断します。

　ついバグが出ないほうがよいと考えがちですが、発生するバグ数は規模に応じて統計上予想されていて、その分を見つけられないと後工程にバグが残り、品質が低下するという考えに基づいています。したがって、「バグ数」が「想定バグ数」に満たない場合は、表紙中段の右端に「未達」の赤文字が表示され、「品質は大丈夫ですか？」と警告するようになっています。

　しかし、非常に優秀なプログラマが作成した場合などは、「未達」だからといって品質が悪いとも限りません。そこで「品質見解」という欄を設けています。テスト結果の定量データと、テスト実施時の感触、およびレビュー結果を踏まえて、問題ありなしの報告を記載してもらいます。

　テスト結果は定量的に判断することが必須ですが、併せて定性情報としての「品質見解」も管理者の品質判断に役立てているのです。また、この記入によって、担当者のテスト作業自体への責任感を意識させることも隠れた効果として意図しています。

優秀なテスター＝顧客視点に立てるSE

　単体テスト自体は、最近では第三者検証サービスや自動テストツールが普及してきているため、可能であればここの工程はどんどんこういったものに任せ、開発の近代化を進めていくべきと考えます。しかし、テスターとしての観点は、顧客に良い製品を届けるという意識そのものだと思います。つまり優秀なテスターになることが顧客視点に立てるSEへの第一歩なのではないでしょうか？

　したがって、こういった地道なテストも品質意識、顧客意識をはぐくむステップとして、一度は経験しておくべきでしょう。

　今回は「単体テスト仕様書兼報告書」のテンプレートを紹介しながら、詳細設計との関係やドキュメントだけでなく運用方法も標準化すべき点、品質の定量的把握などのお話をしました。次回はテストフェーズの続きとして「結合テスト仕様書兼報告書」を紹介します。