V字モデルの欠陥

文書ドリブン開発 詳細設計文書編 (1/2)：システム開発プロジェクトの現場から（26） - ＠ITより

　このV-モデルを見ると単体テストは詳細設計文書をインプットにして作成されることが分かると思います。もしあなたが単体テストの仕様書をプログラムコードから起こしているとしたらそれは間違いです。もしも誤りのあるプログラムコードからテスト仕様書を起こして単体テストを実行した場合、仮に動作結果が「書かれたとおりに動いた」としてもそれは「正しい結果」とはなりません。単体テスト仕様書とは本来は詳細設計文書をベースとして書かれるべきものなのです。

この部分には同意する。
ソースコードから単体テスト仕様書をつくっても品質は上がらない。

　テスト技法を大きく分けるとブラックボックステストとホワイトボックステストに分類できますが、このホワイトボックステストのテスト仕様書を書けるようなレベル感が詳細設計文書の目指すべきレベル感だと理解してください。記述レベルが細かすぎるような気がしますが、このレベルまで落ちていない詳細設計文書を渡されたプログラマの立場になってみてください。恐らく仕様が漠然としすぎていて「あの場合は？」「この場合は？」という疑問ばかりが生じる結果になると思います。

しかし、この詳細設計書の内容をどうするかという部分には同意出来ない。
この「ホワイトボックステストのテスト仕様書を書けるようなレベル感」というのは、一体何だろう？
ホワイトボックステストはプログラムの構造に着目しなければ書けないから、ソースコードを日本語訳したような仕様書のことだろうか？
もしそうだとしたら、これもソースコードをベースにしてテスト仕様書を書いているのと変わりないのではなかろうか？

詳細設計書にはブラックボックステストのように、その機能がどのように振る舞うかを記述するべきだ。
また、「あの場合は？」「この場合は？」という疑問が起こらないように、仕様をヌケなく、モレなく、全て記述しなければならない。

V字モデルの重大な欠陥は、「詳細な仕様の決定が、テスト仕様書の作成まで先送りされている」という点だ。仕様が確定しないままコーディングをすれば、それは後にバグとなって現れてくる。

テスト仕様を基にテストし、バグ管理を行っているのであれば、そのソフトウェアの仕様は全てテスト仕様書に表現されていなければならない。
そして、そのテスト仕様書の作成がコーディングの後になっているのならば、それは、コーディング時には正しい仕様が決まってないと言えるのではないだろうか？

これまで私が経験してきたV字モデルに基づく開発では、詳細設計としてソースコードを日本語訳したような設計書（＝どうやって実装するかに着目した詳細設計書）を作成していた。

どうやって実装するかに着目していたので、とりあえずコーディングは出来るし、ソースコードを日本語訳したような詳細設計書から単体テスト仕様書も作成できて、単体テストも出来た。
しかし、どういうわけか、詳細設計書をレビューしているにもかかわらず仕様バグが多かった。

それもそのはず、どうやって実装するかに着目した詳細設計書では、正しい仕様なのかどうかが詳細設計書から読み取りにくかったのだ。
どういう事かというと、記述されている動作をいちいち追って考えなければ、記述されている機能がどのように振る舞うのが分からなかった。
だから、詳細設計書のレビューでは誤字、脱字、フォントの違い、句読点、その他諸々、
仕様にほとんど関係のない指摘ばかりが出て、バグにつながるような仕様の曖昧な部分は見逃されてしまっていた。

このV字モデルの欠陥を取り除くには、まず、詳細設計書には主に機能がどのように振る舞うのかを記述し、そして、詳細設計の段階、あるいはその直後の工程で、テスト仕様書レベルで機能の振る舞いを全て決めてしまえば良いのではないかと考えている。