テストコードを書くとアジャイルのテストのROIは3倍になる

今回は、アジャイル開発におけるテスト手法に関するお話です。
手動テストと自動テストについて、会計的・数学的な観点から比較します。
今回の記事は、定量的な比較をしただけで、主張の内容は、GoogleやFacebookなどの先進的なWeb系企業やオープンソースでは常識であり、特に目新しい主張ではありません。

結論

1年継続するシステムであれば、自動テストのROIは、手動テストの約3倍です。

4ヶ月未満で改修が完全に終了するプロジェクトならば手動テストを行うべきで、4ヶ月以上改修が継続するプロジェクトであれば、自動テストを行うべきです。

前提
1週間に1回のイテレーション
現在割引価値算出のための年率は上場企業平均のROI年率5%
テストケースが作成されている状態で、テストコードを書く工数を手動テストする工数の8倍とする(8倍は弊社実績)

背景

イテレーションをすばやく繰り返すだけの名ばかりアジャイルがSierによって誇大的に喧伝されています。詳細は後述しますが、自動テストなしにきちんとした品質を担保しながらイテレーションを繰り返すことはほとんど不可能に近いです。どこかで手を抜くか、工数を盛るかしないといけません。Sierは人月商売を行っており、手がかかればかかるほど工数が膨らむので、それも後押ししているのかもしれません。また、キーマンズネットの調べによると、 91.5%の企業は自動テストを行っていません(参考)。
昨年までは、私達もそういったSierの1つでした。今年から、上記の反省を踏まえ、自作のVB6用テスティングツールVUnitとjenkinsによる自動テストにより、品質の向上に努めています。

定性的な根拠
プログラムに一部変更を加えた場合、通常は、そのたびに他に影響がないかを確認しなければいけません。変更や修正を繰り返すアジャイル開発では、この確認がイテレーションのたびにかかるので、うまく工夫をしなければ工数が爆発的に増加してしまいます。現実には、手動テストでは、影響範囲を人間がヒューリスティックに判断し、テストの範囲を狭めることで対応しますが、人間の判断なので得てして見落としが発生し、思わぬところに影響が出たりします。もちろん、カプセル化や関数型プログラミングでリスクを低減させることは可能ですが、現実には見落としが発生してしまいがちです。一方、自動テストでは、一度書いたテストは再利用可能であり、一度書いたものであれば全体に対してテストを行うことができます。また、今回の計算式には算入していませんが、自動テストの実行自体も自動化し、定期的にテストを実行することで、バグの検知もすみやかに行うことができ、工数を削減できます。jenkinsの導入も即日可能です。

定量的な根拠(読み飛ばし可）
1イテレーションにつき1つ機能がリリースされ、1イテレーションの間にリリースされたすべての機能をテストするものとする。

また、1つの機能に対して1回の手動テストをすることよる工数をM、1つの機能についてテストコードを開発する工数をT、自動テストによる1回あたりのテストの工数を0、1イテレーションあたりの利率をi、イテレーションの回数をn、テストをすべて手動テストで行った場合の工数の総和をH、テストをすべて自動テストで行った場合の工数の総和をA、割引率をj = 1/i(j≠1)とする。

Hを求める
H = M+2Mj+3Mj^2+...+nMj^(n-1)
jH=      1Mj+2Mj^2+...+(n-1)Mj^(n-1)+nMj^n
H-jH=(M+Mj+Mj^2+...Mj^(n-1))-nMj^n
(M+Mj+Mj^2+...Mj^(n-1))は初項M,公比j,項数nの等比数列の和なので、式を変形して、
(1-j)H=M(1-j^n)/(1-j) - nMj^n
j≠1より、
H=M(1-j^n)/(1-j)^2 - (nMj^n)/(1-j)

Aを求める
A = T+Tj+Tj^2+...+Tj^n
A = T(1-j^n)/(1-j)

HとAに前述の前提の項の値を代入して比較した結果、前述の結論になった。