テストコードを書くとアジャイルのテストの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に前述の前提の項の値を代入して比較した結果、前述の結論になった。

Excel帳票駆動開発用ツール「ブックみくらべ」をリリースしました

前回、テスト駆動開発について少しお話をしました。今回は、Excel帳票駆動開発のためのツール「ブックみくらべ」をリリースしたので、テスト駆動開発との違いに触れながら帳票駆動開発(弊社造語)のお話をします。

ブックみくらべ(ベクターでも公開する予定です)
https://bitbucket.org/mozanitworks/books-difference

テスト駆動開発とは

テストを行うプログラムを先に作成し、そのテストに通るようにプログラムを書く開発手法のことです。
プログラムの修正は、影響範囲を読み切ることが難しく、A、B、Cといった機能があるときに、Aという機能を修正すると、BとやCに想定外のバグが出ることがしばしばあります(参考:バグ修正のための変更の40%が新たなバグを混入させる)。

これを防ぐために、A、B、Cのプログラムに自動で動作確認をするプログラムを書きます。そして、Aを修正したときに、Aを確認するだけでなく、A、B、Cのすべてのプログラムを自動で実行し、他に影響がないことを確認します。

テスト駆動開発とExcel帳票駆動開発の共通点
両者ともに共通することは、自動で確認をするため、修正や変更に強くなることです。

テスト駆動開発と帳票駆動開発のちがい
テスト駆動開発は、"プログラム"にまちがいがないかを自動で確認する開発手法です。一方、Excel帳票駆動開発は、"帳票"にまちがいがないかを自動で確認する開発手法です。
テスト駆動開発は、自動で動作を確認するテストプログラムを書きます。これにより、プログラムレベルの堅牢性は増しますが、テストプログラムを書くコストがかかります。
これに対し、帳票駆動開発は、最終的に出力されるExcelの帳票の差分を比較します。現行のプログラムが出力する帳票と修正したプログラムが出力する帳票を自動で差分比較します。比較は、今回のツールを使えば、ワンクリックで終了します。
これにより、差分として出力されなかった部分については動作を保証し、差分として出力された部分を確認すれば、修正の確認が完了します。
Excel帳票駆動開発は、テスト駆動開発に比べて内部の堅牢性は下がりますが、その分遥かに高速にユーザーに見える部分をテストすることができます。

どちらが優れているのか
ナイフとハンマーがその用途によってその利便性が違うように、用途によって変わります。私が前回テスト駆動開発用ツール「VUnit」をリリースし、今回ブックみくらべをリリースしたのは、相互に足りない部分を補うためです。
テスト駆動開発は、たしかに堅牢性が増すのですが、チームやソフトウェアに浸透させるまでに時間がかかります。今あるソフトウェアの規模だと、1年から2年の仕事になると思います。長期的にはこれでも構わないと思うのですが、短期的な面では不満が残ります。そこで、ブックみくらべを作成しました。弊社のソフトウェアはExcelやCSVで帳票を出力する機能がほとんどなので、短期的にもこれで品質向上が望めます。

背景
弊社はとても小さなチームです。今のメインクライアントは、複数のベンダーと契約しています。その多くは、とても大きなベンダーで、通常ではとても太刀打ちができません。
確認作業なども、マンパワーが足りないため、どうにかして効率化する必要があります。効率化の源泉は、先日お話したアジャイル開発と小さなチームならではの小回りです。使えるツール・手法はどんどんスピード感をもって導入・学習し、なければサクっとつくり、改善する。特に、品質保証に関わる効率の向上は、スピードに直結します。確認やバグ修正、それに付随する手戻りが減り、手が空くことで、より人間的な作業に集中し、新しい機能を開発していくことができるからです。

VB6用テスティングツールVUnitをリリースしました

品質向上の一環として、テストツールVUnitを作成・リリースしました。
オープンソースとして公開しています。ライセンスはMIT Licenseです。
https://bitbucket.org/mozanitworks/vunit
VUnitの紹介とともに、弊社の運用体制についても解説します。

1.VUnitの特徴

Visual Basic6.0のIDE上で動作し、テスト結果をイミディエイトウィンドウに出力します。
類似のテストツールVBUnitでは、この機能が有償となっています。


2.開発体制について

詳細な要件定義をせずに、まずプロトタイプをすばやくつくります。
そして、そのプロトタイプを元にお客さんから修正点・要望を引き出し、徐々に完成度を高めます。この手法を採用している理由は、具体的な動くソフトウェアがない状態でエクセルを見ながらミーティングを重ねても、地に足のついた要件になりにくいからです。お客さんにとっても、事前に綿密に要件定義をする必要もなく、ストレスの負荷が低くなります。
この手法の長所は、柔軟で、スピードがあることです。一方、短所は、開発側からすると、お客さんとの信頼関係を構築する必要があることです。チェックポイントごとに提出する荒削りなソフトウェアに面食らってしまうため、事前に説明が必要になります。

3.今後の展望

今回開発したVUnitをもとに、開発途中のソフトウェアでも担保できる品質を可視化していきます。お客さんの安心と実質的なクオリティを上げていく予定です。
現在使用しているバージョン管理のMercurialとプロジェクト管理ツールのRedmine、今回作成したVUnitを連携させて行く予定です。

#あとがき

制作時間1.5日でした。頭の中に設計の構想があったので、それを考えるために手がとまることがなく(普通はこれに一番時間がかかる)、思ったより速くつくることができました。「つくりたいものをつくりたいようにつくる」と、興味が働いて手を動かしていない時間に頭の中で仕様を検討するため、生産性が高くなるような気がしました。