そろそろ「プログラミングファースト開発におけるバグの偏在を利用したユニットテストのコスト配分」について一言いっておくか

IT

JJUG界隈で話が挙がっている掲題の件について、自分なりに考えがまとまったのでエントリー。
尚、本エントリーで言うバグは、仕様確定後における仕様の実装バグを言っています。


ウォーターフォール開発の場合、バグが混入する原因は

  • 仕様設計書の不備

(1)設計者の仕様理解不足
(2)設計者の記述力不足
(3)設計者の記述ミス、不注意

  • プログラムの不備

(1)製造者の仕様理解不足(設計書の不備を補完する意味で)
(2)製造者の製造ミス、不注意
(3)製造者の技術力不足(使用言語、アーキテクチュア理解力不足)

  • テストの不備

(1)テスト仕様設計者の仕様理解力不足
(2)テスト仕様設計者の記述力不足
(3)テスト仕様設計者の記述ミス、不注意
(4)テスト実施者のテストミス、不注意
に収斂されるのではないでしょうか。
つまり仕様が揺るぎない場合、バグの原因は属人的ってこと。*1
ということは、各担当者によってスキルの差がある場合、バグが偏在することは正しいと言えます。
設計レビュー、製造レビュー、テストレビューをすることで品質の均一化はされますが、
全ての設計書やプログラムやテスト仕様書、テスト結果をレビューしないでしょうから、
やはりバグは偏在し続けるでしょう。


で、プログラミングファースト開発においても「バグの偏在」を元にユニットテストのコスト分配を謳っていますが、本当に当てはめて正しいの？


プログラミングファースト開発ではドキュメントより先に動くコードを書くので、詳細設計書は後付けとなっています。
また、ペアプログラミングや、スキルのある開発者にスポットを当てている(と開発者が言っている)ので、システム全体として開発者の技術力は必要十分なレベルで均一化されると考えられます。
シナリオテストに関しても、そもそもテストを書くのがプログラミングを行うペアなので、必要十分なレベルと言えるでしょう。


従って各担当者に起因するバグの偏在は起きないのでは？
つまりプログラミングファースト開発を行う場合、バグの偏在を利用したユニットテストのコスト分配は無意味なのでは？
(そもそも、人による品質の偏りが発生するような何十人もの設計、製造、テスト担当者が従事するスケールのシステム開発において、プログラミングファースト開発が想定されているかは疑問ですが、、、)


少ないテストで一定の品質を保つための方法としては
「シナリオテストを実行してバグが見つかれば、その周辺を重点的にテストする」
という帰納的な方法より
「FP法などで機能別に複雑さを定量化し、それに基づいてテストコストを分配する」
のうが効率的ではないかな、と思います。

*1:ある人は、必要以上にバグを混入させる人の事をパティシエ(=瑕疵職人)と呼んでいました、、、