WhatとＨｏｗでのテストの違い
前回（http://d.hatena.ne.jp/good_way/20080416/1208357141）のWhatとHowでは実装者に伝えている情報がまったく違います。
Whatではやりたいことが伝わっていますので、テストは条件として示されていることが実現されているかをテストすればいいことになります。
- 車は使わないで歩いているか。
- 信号では交通規則に従っているか
- 信号の確認方法とその対処は規約Ｘｘｘに従っているか
- 一番効率的に行っているか
上記の条件を何らかの方法でテストすることになります。
自分で導き出したHowを検証するのがその目的です。
Howでは示された条件が道順を示されているので、その道順通りに行っているかをテストします。
それはそれでテストとしては成立していますが、本当に重要なテストはHowとして示されたものが、本当にWhatを満足しているのかをテストすることになります。しかし、それは実装者には不可能です。なぜならばWhatを伝えていないためです。
そのテストは設計者が行わなくてはいけないのですが、多くの場合設計者は対象となるプログラミング環境を知りません。そのためテスト仕様書もWhatの視点つまり、ブラックボックステストに近い形になります。
しかし、これは設計者の役目ではありません。Whatを書いた分析者がブラックボックステストを書くべきです。それはWhatを書くために必要な条件や情報は設計者が知らないからです。
設計者は自分でHowを導き出したので、そのHowの隅をつくようなホワイトボックステストを書くべきです。
こうして考えるとHowを考えるだけの設計者という役割はとても効率が悪いことが分かります。
Howを考えることが出来ておまけに実装が出来る人なんてそんなにいないのではないか...
と考えるかもしれません。
安い単価の人は大量に確保できるので、その人を大量に使えばいい という発想です。
これは私には規格住宅ではない個別の住宅を建てる時に、腕のいい頭領が一人いれば新米もしくは言葉の通じない大工を大量に投入して家を建てられる と言っているように聞こえます。
Howを考えることはとても難しいように思えますが、ある程度のスキルとある程度の分析ドキュメント、そしてある程度の決まり事があればHowを考えることはそんなに難しいことではありません。
ではそのある程度とは どの程度なのか？ というのが次に問題になります。
