黒柴的ソフトウェアテスト考　#4

では、コンポーネントテスト（単体テスト）ってどうやるの？

テスト考#3で、ようやく「ブラックボックステスト」の実施方法について理解ができた
しかし、そこでさらに考えなければならないことが出てきた

もともとインテグレーションテスト（結合テスト）以降の工程では、設計書を元にテスト項目を洗い出していたので、これは一応ブラックボックステストのやり方に則っていると思う
つまり、テストベースとなる設計書に記載された仕様と、製造されたプログラムの振る舞いが合っているかという確認だからである
だが、コンポーネントテスト（単体テスト）は、どうなのだろうか？

テスト考#1や来歴での述べたように、「ブラックボックステスト」技法を意識するまでは、ずっと「ホワイトボックステスト」技法で、コンポーネントテストを実施してきた
ホワイトボックステストの場合、プログラムの構造に着目してテスト設計を行うため、ソースコード自体をテストベースとすることが可能だった
そのため、プログラムの設計書を確認することは、ほとんどなかった

これは、恥ずかしい過去をさらけ出すことになるが、自分が携わってきた大半の開発プロジェクトでは、スケジュール遅れが発生するとプログラムの設計書は真っ先に端折られてきた
納品物としてプログラムの設計書が必要な場合は、プロジェクトのクローズフェーズでリバースエンジニアリングで作成するから、ソースコードのJavaDocをそれらしく書いておいてくださいと言われるのがせいぜいで、とにかくプログラムの製造を最優先で進めろという状況だった
いわゆる「とりあえず、動くものを作れ」という感じで・・・

しかし、プログラムのコンポーネントテストにおいて、ブラックボックステストを成立させるためには、テストベースとしてプログラムの設計書を元にテスト分析、テスト設計を行うことが必要である
しかも、このプログラムの設計書が、「正しい」ということが確認されていければならない
「正しい」とは、要件定義書の記載された仕様とプログラム設計書で定義された仕様が、合致しているということである
要件定義書の記載された仕様と異なった仕様のプログラム設計書を元に、プログラムの製造、テストを行っても、プログラム設計書に整理された仕様をプログラムが満足していることは確認できるが、ユーザのニーズをプログラムが満足していることは確認できない

ここで黒柴の頭を悩ませたのは、テストベースとしてのプログラム設計書を「きちんと」書くということである
プログラム設計書をクローズフェーズでリバースで出力しているのも、工数を圧縮したいという意図もあるが、プログラミングの実施前に作成しても、実装の最中にいろいろと気が付くことがあったり、またテスト工程が進んでいくことでプログラムの改修が発生するため、プログラム設計書の更新が多発するためである

もちろん、プログラム設計が変更される都度、プログラム設計書を改版すればよいのだが、設計書の改版に費やす工数があればプログラミングに回したいというのが、遅れたプロジェクトのリーダーが考えることである
結果として、すべて完成した後で「このコンポーネントは、こういう仕様です（でした？）」という感じで、最終形に対して設計書をリバースで作成することばかりやってきた

では、他のプロジェクトでは、きちんとコンポーネントテストをブラックボックステスト技法で実施できているのだろうか？
黒柴は、ネット上のブログなどから、実態を調査することにした