レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

テストは「最低限」のパターンではなく、与えられた時間の中で「最大限」やるべきだ。

本来、高い品質を得るには、できるだけ沢山のパターンを出来るだけテストしてみるのがよく

考え付く限りのパターンを全網羅するテストが出来れば最高だ。

しかし現実問題として、それは全くもって途方もない。


だから何らかの基準を設けて、テストパターンを絞らざるを得ない。

しかし、工数(=お金)をケチることを優先してパターンを絞ると

最低限のテストパターンを求めることになる。


工数(=時間)を掛けずにいかに最低限のテストをするかと考えると、

テスト期間をあらかじめ決めるよりも、ソースコードのボリュームに対して

何割という計り方をした方が、うまくインチキできる。

だからじゃないだろうか、テスト工数の見積りだけ、急に1キロステップ中のバグ数とか、

分岐のパターン数による見積という摩訶不思議な基準が現れるのは。

それまで散々「人日」や「人月」という、時間基準の工数計算をして来たのにだ。



僕は、むしろテストこそ時間を基準にしてやるべきだと思っている。

たとえば、実装時間を基準に単体テストのための工数を割り出すのが良い。

素早くコーディングできる上級者には、短いテスト工数でよく、

コーディングが遅い初級者には、長いテスト工数が必要だ。


テストは「最低限」のパターンではなく

与えられた時間の中で「最大限」やる


だって最大限のほうが、エンジニアは燃えるから。