単体テスト仕様書の「表紙」
そこそこの規模の開発をやっていれば、単体テスト仕様書の作成は避けては通れないですよね。もちろん、私もこれまで様々なプロジェクトで様々なフォーマット、粒度、考え方で単体テストを実施する機会がありました。つい最近、私が2年ちょっと関わっていたプロジェクトが終わったのですが、最終フェーズで単体テスト仕様書の見直しタスクというものがあり、そのタスク内において、単体テストの実装と仕様書の乖離がないか、そもそも仕様書がなかったりしないかなどを実施していました。
今回このネタを語ってみようと思ったきかっけは下記のCodezineの記事です。
まだ始まったばかりの連載のようなのですが、テスト計画書のアウトラインや第１回の記事を見て、トラジショナルな感じかなという印象と、大規模システムのときに意外と問題となる点についてはやっぱり書いてないなぁという印象を受けました。
(紹介した記事の趣旨は「テンプレートから学ぶ」なので、批判するつもりは毛頭ありません)
そんなわけで、私が経験したプロジェクトの中でこの単体テスト仕様書の「表紙」の問題について、少しご紹介しようと思います。
単体テスト仕様書に限らず、また、ファイルフォーマットがWordだろうがExcelだろうが、日本では納品はCD(DVD)＋印刷したものをバインダー で閉じて持参又は送付ってパターンが多いですよね。そういうわけで、印刷が避けては通れなかったりする以上、表紙は必要で、かつ、その次に必ず来るのが改訂履歴（変更履歴）ではないでしょうか？
最も多いパターンだと思われるので、Excelでテスト仕様書を作成しているという前提で話を進めます。これまで私が経験した中で多かったのは1シート目が「表紙」シートとなっていて、そこにタイトルとテスト対象の画面名、クラス名等が書いてあって、さらに改訂履歴の表が書いてあるというパターンです。レイアウトはそのプロジェクトごとに様々だったり、微妙に違ったりはしますが、概ね書いてある内容については大差ないでしょう。
この単体テスト仕様書は、本来実装とセットで修正をするものですが、開発が忙しいときには「テスト仕様書は後でいいから、とにかく早く作って、ソースをコミットしてくれ」なんて横暴な発言を開発リーダがしてしまうケースが多々あります。もちろん、「やらなくていい」とは一言も言ってないのですが、だいたい最後のほうになって、問題が顕在化して、品質がボロボロじゃないかって話になります。
さて、本題の「表紙」ですが、上述のように忙しいときに、「画面名の変更」や「クラス名の変更」があった際に、単体テスト仕様書だけが放置されると、他のドキュメントや実装と不整合が発生します。通常、テスト仕様書を管理するために、ファイル単位で管理IDを採番しているケースが多いと思いますが、ファイル名がこの管理IDだけだとわかりづらいので、通常テスト対象の画面名だとかクラス名などを入れたりすることが多いです。そうすると、名称変更に伴い、「あれ、この画面の単体テスト仕様書が見当たらない」ってことになり、これまた全部見直しをしないとダメだなんてことになるわけです。
そして、表紙だけでもこんな悲しい話があるにも関わらず、改訂履歴で問題になりやすいのが、実際に単体テストの実施日と改訂履歴の改訂日の整合性が取れていないという問題です。どちらかの修正を怠ったのが原因なわけですが、SVNなどでドキュメントのバージョン管理をやっていない場合は、もはやトレースできないため、無理矢理整合性を合わせるというタスクが発生してしまいます。
改訂履歴はSVNで一元管理して、別途変更管理表として納品するのも手かなと私は考えています。とはいえ、SVN履歴をそのまま納品するためには、ふざけたコミットコメントを書かないようにさせるとか、変更管理表に記載しないコメントには、[NO-DOC]などとプリフィックスを入れてもらうとか、ルール作りが大事でしょうね。