テスト自動化のROIとは？
By Omar Galeano（Translated by 鈴木良和、元記事はこちら）
要約：ROIをここで計算しましょう！
アジャイルソフトウェア開発の時代に、テストの自動化は "Nice to have" から、高品質のソフトウェアを迅速にリリースするために重要な "Must have" のケイパビリティになりました。
通常、ビジネスサイドの意思決定者はテスト自動化が良いアイデアであることに同意します。しかし、予算と締め切りがタイトなシチュエーションにおいては、特にテスト自動化フレームワークの構築と運用コストが明確でない場合、それがもたらす価値に疑問を抱く可能性があります。また、多くのステークホルダーは、スプリント毎に増加する手動の回帰テストがチームの開発・リリース能力を大きく制限することを説明するだけで、テスト自動化への投資の必要性を理解します。しかし、ITやテクノロジーに詳しくないステークホルダーには、定量的な算出を用いた説得が必要となることがあります。
この記事では、あなたとあなたのチームがファイナンスを重視する意思決定者にテスト自動化の価値を伝える方法とツールを紹介します。
手動回帰テストを自動化は、初期コストとランニングコストはあるものの、長期的に見て価値のある投資になることをステークホルダーは理解してくれるかもしれません。
テスト自動化の価値
テスト自動化の価値の多くは、自動テストを複数回実行することに起因しています（注１）。
テストを少数回しか実行しない場合、初期コスト（テスト自動化ツールの購入、フレームワークの構築、テストのコーディングなど）より、すべてのテストを手動で実行する方がコスト効率が高い場合があります。
ただし、新しい開発プロジェクトに対して自動テストが繰り返し実行されると、いずれ損益分岐点に達します。この時点から、その後のすべてのテスト実行は、プラスのROI、キャパシティの増加、そしてカバレッジの増加を意味します。つまり、以前は手動で実行することができなかったであろうテストを実行することが可能になります。
次の例では、25回の自動化テストの実行後に損益分岐点に達し、50回目の実行では約1.75倍のROIに達しています。つまり、テスト自動化は投資額より75％多くの価値をもたらしたことになります。
ROIの算出
（もし計算が得意でない場合は、【テスト自動化のROIシナリオ】に進んでも結構です。）
ここでは、ROIは手動回帰テストを自動テストに置き換えて得られた節約をテスト自動化への投資で割ったものとして定義・算出されます。
ROI = 節約 ÷ 投資
ROIは単位のない数値であるため、例えば節約と投資が金額であるか時間であるかは関係ありません。ただ、ほとんどのインプットは時間であるため、ここでは計算を簡単にするために時間（分）を使用します。
ちなみに、テスト自動化作業を行う人員の時給・請求レート（注２）を分単位に変換すれば、ROIを金銭的価値で算出することができます。
同様に、テスト自動化のコスト削減額は、節約分から投資（両方とも分単位）を差し引き、それを時間に変換してから、時給・請求レートを掛けることで見積もることができます（注３）。
コスト削減・節約
節約とは、一連のテストを手動で実行するコストと、同じテストを一定期間に何度も自動的に実行するコストの差です。
節約 =（A - B) × テスト数 × 実行回数
A = 1つの手動テストケースの実行にかかる時間（注４）
B = 1つの自動テストケースを実行する時間
テストの数は期間中の平均値です。 例えば、テストスイートがゼロテストから始まり、最終的に200まで直線的に増加した場合、テスト数の平均値は100になります。
統合テストはエンドツーエンド（e2e）UIテストよりも5〜10倍速く、信頼性が高くなる傾向があるので、できるかぎりe2e UIテストの代わりに統合テストを使用することによってプラスのROIをより早く達成できます。
テスト自動化への投資
投資とは、テスト自動化ツールまたはフレームワークの構築と構成に費やされた時間、および自動テストのコーディングまたは保守運用に費やされた時間を含む、テスト自動化の固定費とランニングコストの合計です。
投資 = （C × テスト数) + フレームワークを構築する時間 + 保守運用コスト
C = 1つの自動テストをコーディングする時間（注４）
導入コストまたはライセンスコストがある場合は、前述のように請求レートで割って金額を分に換算した後、ここに追加できます。
メンテナンスコストは、失敗したテスト（偽陽性と実際の失敗の両方）を調査して修正するためのコストです。機能やテストに欠陥があるかどうかを判断するには調査が必要であるため、不安定なテストや開発バグも同様にメンテナンスコストの原因になります。テストが失敗する頻度が高ければ高いほど、プラスのROI達成にかかる時間が長くなります。
保守運用コスト = D × E × テスト数 × 実行回数
D = 失敗テストケース1件毎のメンテナンス時間（注釈４）
E = 実行ごとの失敗テストケースの割合
ここでは、すべてのテストの平均失敗率を想定しています。
テスト自動化のROIシナリオ
前述の例は、次のシナリオに基づいています。
この場合、25回のテスト実行後に損益分岐点に達し、50回実行後にROIは約1.75でした。
他のシナリオを見て、ROIと損益分岐点がどのように影響を受けるかを見てみましょう。
シナリオ１：10回のみ自動化テストを実行した場合
10回実行をした後、プロジェクトが終了したか、テスト自動化フレームワークが破棄された想定です。 どちらの場合も、投資の約45％（ROI = .45）しか回収されておらず、手動の回帰テストを行う方が費用対効果が高くなります。 ここでの仮定は平均150テストでしたが、スイートがまだテスト数を増やしている場合、ROIはさらに低くなっていました。
シナリオ２：テストフレームワークの構築に2倍の時間がかかった場合
基準となる元のシナリオに戻りましたが、今回は2週間ではなく、テストフレームワークがコーディングテストを開始できるようになるまでに4週間かかったと仮定します。 一見、2週間の追加作業は高価に思えるかもしれませんが、テスト自動化フレームワークをさらに9回（25回ではなく34回）実行した後にマイナス分の投資は補われ、その後ROIは改善されます。 50回実行した段階でのROIは約1.4になります。
シナリオ３：テストの実行に2倍の時間がかかった場合
このシナリオでは、各自動テストの実行に30秒ではなく1分かかることを想定します。 実行時間は長くなりますが、基準シナリオプラス4回（25回ではなく29回）で損益分岐点に達し、50回実行するとROIは1.6未満になります。
シナリオ４：失敗テスト数が2倍の場合
テスト自動化ROIのもう1つの主な要因は、テストの堅固さです。テストが失敗した場合は、実際の失敗か偽陰性かに関係なく、問題の特定、診断、および修正に時間がかかります。タイミングの問題などが原因で多数のテストが断続的に失敗することが多い場合、ROIに大きな影響を与える可能性があります。このモデルでは、50回の実行後のROIが1.35で、損益分岐点までにはプラス6回（計25回ではなく31回）実行する必要があります。
さらに、このモデルは「障害が実際に存在するかどうかの確認を怠るたびに自動化テストの再実行に費やされる時間」を考慮しないため、実際のROIは上記よりもいくらか低くなる可能性もあります。
シナリオ５：フレームワークとテストに2倍の時間がかかり、2倍の頻度で失敗した場合
この場合、シナリオ2〜4の障害が全て起きる最悪のシナリオです。 ROIの算出の方法としてまずはじめに思い浮かぶのが、各シナリオの遅延を合計して損益分岐点を推定することです。これらを合計すると、19回の追加のテストが行われ、結果として損益分岐点に達するまでには44回の実行が必要になる可能性があります。
しかし実際は、複数の要因がROIへの打撃を増幅するので、50回目の実行でプラスのROIをかろうじて達成しているだけでした。
最後のシナリオ：すべてのテストがサービスレベルもしくは統合テストに置き換えられた場合
プロジェクトの特性によっては、一部の手動テストを自動化サービスまたは統合テストに置き換えることが可能な場合があります。この場合、これらのテストはUIを介して実行されなくなり、実行時間が短縮され、テストがより堅固になり、メンテナンス時間が短縮されます。このシナリオでは、損益分岐点は左に19回に移動し、50回の実行後のROIはなんと2.4です。
アプリケーションのすべての手動テストをサービスもしくは統合テストに置き換えることはできない場合がありますが、テスト自動化ピラミッドに従ってE2E UIテストに完全に依存することを避け、サービスおよび統合テストをできるだけ実行することをお勧めします。
このモデルの制限
私たちのROIモデルは、インプットの数を低く抑え、できるだけ一般的に適用できるように意図的に単純化されています。そのため、ROIに影響を与える可能性がある下記の要因を算出に組み込んでいません：
• 単体テスト：単体テストは、コードの品質を向上させる重要なアクティビティです。本質的に、単体テストは狭義すぎるので手動テストに取って代わることはできませんが、調査する必要のある失敗の数が少なくなる可能性があるため、その価値はモデルに暗黙的に含まれています。
• テストカバレッジの向上：自動テストを迅速に、または営業時間外に実行できるため、テストカバレッジまたはキャパシティが向上します。時間がないため手動で実行できないテストを実行したり、自動テストの実行中に追加の手動テストを実行したりできます。このような価値は、ROIの算出には考慮されていません。
• テスト再実行のコスト：不安定なテストを同じビルドに対して繰り返し実行する必要がある場合、これらの再実行コストはROI算出には含まれていません。
• その他のコスト：考慮されていない追加のインフラストラクチャおよび運用コストは、時間（分単位）に換算され、投資合計に追加できます。
• ROIの金額変換：上記のように、ROIを金額ベースに変換するのは容易です。これはビジネスサイドの意思決定者とのコミュニケーションに役立ちますが、モデルのシンプルさ故、その精度は制限される可能性があります。
ROI算出の精度を高めるために、このモデルをカスタマイズして、あなたの組織に関連する要因やコストを考慮しましょう。
結論
テストの自動化には、それに見合うだけの利益をもたらす先行投資と継続的な投資が必要です。全体的なテスト自動化戦略の一部としてサービスレベルまたは統合テストを実装することにより、大きな価値を得ることができます。
プロダクトがスケールしつつ手動の回帰テストに依存することは、これらの価値を実現できないだけでなく、プロダクトと組織そのものを危険にさらす可能性があります。テストとバグ修正のコストはイテレーションごとに増加し、最終的にはプロダクトのコスト、品質、市場ローンチまでの時間に影響を与えます。
このROIモデルを使用すれば、ビジネスサイドの意思決定者は、時間の経過とともにテスト自動化がもたらす価値をすばやく簡単に理解でき、テクノロジーサイドはテストフレームワークの価値に対するテスト速度、堅固性、および保守性の影響についてインサイトを得ることができます。また、双方のステークホルダーも、このモデルを使用することで正しい意思決定を推進し、組織内の高価値なテストの自動化の達成につながります。
追記事項
注１：同じビルドに対してテスト自動化を繰り返し実行しても、実行の間に新しい回帰バグが見つからないため、価値はありません。テストの不安定さのためにテストを繰り返し実行する必要がある場合、これは投資コストの原因となり、全体的なROIを低下させます。
注２：異なる請求レートを持つ複数の人がテスト自動化作業を行っている場合、請求レートの加重平均を彼らの努力に比例して使用できます。
注３：この方法を使用すると、手動の回帰テストを効果的に置き換えるあらゆる種類の自動テストを推定できます。
注４：ここでは平均時間が使用されます。平均テスト時間を取得する1つの簡単な方法は、triangular 3-point estimateを使用することです。このテストでは、単純、標準、および複雑なテストが識別され、それぞれの時間が試算され、合計を3で除算します。
= = = = =
あなたの組織は、アジャイル、DevOps、クラウド、顧客体験、イノベーションについてのビジネス課題をお持ちですか？アメリカの最新事例、ツール、ノウハウを使い、共にあなたの組織を変革しましょう。詳しくは tokyo@slalom.com まで。
= = = = =
スラローム・コンサルティングについて
スラロームは、戦略・アジャイル・クラウド・イノベーションに特化した、ハイペースで先進的な総合コンサルティングファームです。
私達の活動は、33ヶ所のオフィス、7つのビルドセンター、世界規模のコラボレーション文化と、トップテクノロジープロバイダーとのパートナーシップによって支えられています。
2001年に設立され、シアトルに本社を置くスラロームは、8,000人以上のコンサルタントと1,200社を超えるクライアントを抱える企業に成長しました。フォーチュン社の「働きがいのある企業ベスト100」などのランキングにも毎年名を連ねる、多様でインクルーシブな企業文化のあるコンサルティングファームです。