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

単体テストフェーズで確保する品質とは？

　「標準化」は「生産性向上」の取り組みという位置づけでとらえられますが、効果はそれだけではありません。作業の属人化解消による「品質向上」と、テンプレート導入時の意識改革による「スキル底上げ」を同時にもたらし、その結果「生産性向上」につながるといった仕組みになっているのです。

　今回もこれらの観点を織り交ぜながら単体テストフェーズについて、ダウンロード可能なテンプレートファイルを使って説明していきます。

　前回までの上流工程ドキュメントにおいても、「品質」について触れました。その際は「顧客満足度の切り口」で解説しましたが、品質には「企画品質」「設計品質」「製造品質」「使用品質」といった工程別に確保するべき品質を定義した考え方もあります。システム開発では、それぞれの品質とそれを確保する工程は図1のようになるでしょう。

　「第2回：要件と機能を簡潔に伝えるテンプレート（http://www.thinkit.co.jp/article/140/2/）」の上流工程でお話した「当たり前品質」と組み合わせて考えると、「当たり前品質」とは「企画品質」の内容が、顧客とのコミュニケーションによって共有化することで確保されるものといえます。ちなみに「設計品質」は「ねらいの品質」「製造品質」は「できばえの品質」ともいいます。

詳細設計と単体テストの関係

　単体テストとは、詳細設計書のとおりにプログラムが作成されているかを検査する工程です。先の工程別品質で考えると、図1では「設計品質」「製造品質」に当たり、「ねらい」どおりの「できばえ」となっているかをチェックする工程ともいえます。

　したがって、単体テストのドキュメントテンプレートを考える場合、まずは詳細設計書の記載項目が、すべて漏れなく単体テスト仕様書にも存在しているような工夫が必要です。そういった意味では、詳細設計書に単体テスト用のチェック項目があればいいはずです。しかし紹介する「DUNGEON」テンプレートでは、次の3つの理由で別ファイルとしています。

　まず1つ目の理由としては、詳細設計書が顧客指定の場合があるからです。例えばシステムリプレイス案件で顧客にシステム室があると、見慣れている前システムの設計書フォーマットに合わせてほしいという要望が出てきます。そのような場合に、詳細設計書は顧客指定を使用しても、単体テスト仕様書は「DUNGEON」を使用できるようにしているのです。

　2つ目の理由は、単体テストのチェック項目をマージしてしまうと、設計書自体が読みにくくなるからです。後ほどテンプレートを見てもらうとわかるのですが、テスト結果を記載する欄といっても1項目だけではないため、それらをあらかじめ設計書に用意すると、ページの右半分はテスト関連項目になってしまい、設計時や実装時に読みにくく非効率になります。

　最後の理由は弊社の都合で、自社パッケージの設計書にWordのものがあるからです。設計書はExcelとWordのどちらがいいかという、よくある議論になってしまうので、ここで細かく述べるつもりはありません。ただWordは、顧客への納品物として体裁がよい、見出しマップや目次機能により必要な個所へのアクセスがよいなどのメリットがあるため、一部弊社パッケージでは詳細設計書がWordとなっています。

　しかし、設計書はWordでも、単体テストのドキュメントテンプレートは断然Excelがいいのです。なぜなら、単体テストでは集計値が必要だからです。後で表紙を見ていただければわかりますが、ほとんどの項目が集計値となっています。

　以上のような理由で、単体テストのドキュメントテンプレートはExcelで詳細設計書とは独立して作成することとしています。次は、いよいよテンプレートを紹介しながら、実際に使い方をみていきましょう。