本来、高い品質を得るには、できるだけ沢山のパターンを出来るだけテストしてみるのがよく
考え付く限りのパターンを全網羅するテストが出来れば最高だ。
しかし現実問題として、それは全くもって途方もない。
だから何らかの基準を設けて、テストパターンを絞らざるを得ない。
しかし、工数（=お金）をケチることを優先してパターンを絞ると
最低限のテストパターンを求めることになる。
工数(=時間)を掛けずにいかに最低限のテストをするかと考えると、
テスト期間をあらかじめ決めるよりも、ソースコードのボリュームに対して
何割という計り方をした方が、うまくインチキできる。
だからじゃないだろうか、テスト工数の見積りだけ、急に１キロステップ中のバグ数とか、
分岐のパターン数による見積という摩訶不思議な基準が現れるのは。
それまで散々「人日」や「人月」という、時間基準の工数計算をして来たのにだ。
僕は、むしろテストこそ時間を基準にしてやるべきだと思っている。
たとえば、実装時間を基準に単体テストのための工数を割り出すのが良い。
素早くコーディングできる上級者には、短いテスト工数でよく、
コーディングが遅い初級者には、長いテスト工数が必要だ。
テストは「最低限」のパターンではなく
与えられた時間の中で「最大限」やる
だって最大限のほうが、エンジニアは燃えるから。
