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

単体テスト仕様書兼報告書の使い方

　図2は「DUNGEON」のテンプレートの「単体テスト仕様書兼報告書」です。単体テスト仕様書兼報告書のフォーマットは、こちら（http://www.thinkit.co.jp/images/article/140/3/14031.zip）からダウンロードできます（14031.zip/42.7 KB）。

　当テンプレートの工夫点を挙げてみます。

　1点目は前節で述べた詳細設計書との連携部分です。詳細設計書と別ファイルであるということは、同一ファイルの場合に比べて、作成時の工数増、テスト項目の漏れが発生するリスク増というデメリットがあります。

　しかし、詳細設計書から転記しやすいフォーマットにすることでそのデメリットを解消しているのです。構成として、詳細設計書の章立てごとにシートを分けています。なぜならチェックする内容ごとにシートのフォーマットが異なるからです。極力リスト形式にして汎用性を高めていますが、チェック内容に応じたアレンジを多少することでテスト効率も上がります。今回の例は、弊社パッケージの詳細設計書の章立てを例にしていますが、皆さんは自社の詳細設計書に合わせて、各シートは変更してかまいません。

　2点目は、誰がこれを使用するかという観点での工夫点です。単体テストフェーズの実施手順をおおまかに示すと次のようになります。

1.テスト仕様書を作成する。
2.作成したテスト仕様書をレビューする。
3.テストを実施し、テスト報告書を作成する。
4.作成したテスト報告書をレビューする。

　さて、上記それぞれの手順で、テンプレートを誰が使用するのか考えながら説明しましょう。

実施方法の標準化

　この手順のうち、1.の単体テスト仕様書作成は誰が行うものでしょうか？通常は設計者が詳細設計書に合わせて作成するケースが多いでしょう。しかし、筆者が担当するプロジェクトではプログラマに作成させています。

　その理由としては、まずプログラマに作成させ、そのでき栄えを確認することでプログラマが製造に入る前の理解度を測ることができるからです。また、あらかじめテスト項目を書かせることで、どういった点に注意して製造しなければならないかという品質意識を持たせる教育になるからです。さらには、一般的にはSEよりもプログラマのほうが原価が低いため、コストダウンによる競争力アップにもつながります。したがって、プログラマが作成する以上、プログラマでも書きやすい工夫をしています。

　例えば先の詳細設計書との連携にも関連しますが、詳細設計書から簡単に作成しやすいフォーマットを意識しています。詳細設計書の1チェック項目ごとに、その文言をそのままExcelの行に張り付けていけば完成するようなイメージです。また、作成後に必ず設計者がレビューする運用とし、その際のチェック観点をわざわざ表紙に記載しています。この観点を事前に明示することで、作成する側のプログラマにも品質意識が共有化できるのです。

　では、手順3のテストを実施し報告書を作成するのは誰でしょうか？候補としては実装担当のプログラマ、設計担当のSE、実装担当外のプログラマ、プロジェクトリーダー、専属テスト担当者などを挙げることができます。しかし実は誰でもいいのです。最低限守ってほしいのは実装担当のプログラマ以外の目で1回はテストするという点です。

　その意味で、当フォーマットは計2回の結果を入力できるようになっています。例えば1回目は実装担当プログラマ、2回目は専属テスト担当者が実施というような運用で使用してください。

　「標準化」においては、ドキュメントを作成するだけでは不十分です。なぜなら上記のようにドキュメントを使う際の想定ルールが必ずあるからです。誰がどういった手順で使用するかという運用ルールもきちんと標準化してこそ、ドキュメントが真の効果を発揮すると認識しましょう。