テスト自動化の3つの目的とROIの必要性、定義:テスト自動化のROIを計算してみよう(1)
テスト自動化の導入理由や効果測定をROIという観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを解説する連載です。
はじめに:本連載について
本連載を担当しますテスト自動化研究会(STAR)の太田健一郎と申します。本連載では、読者の皆さまがテスト自動化の導入理由や効果の測定をROI(return on investment、投資利益率、投資収益率、投資回収率)という観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを数回にわたって解説させていただきます。
連載の流れは以下の通りです。
- テスト自動化とROI
- ROIの試算式の構成要素と試算式
- ROIの試算式の詳細と実際
本連載の対象読者は以下を想定しています。
- テスト自動化を推進するエンジニア
- テスト自動化の定性的な効果は理解しているが、定量的な説明がうまくできないエンジニア
本連載で取り上げる内容は以下の通りです。
- テスト自動化のROIを試算する際の構成要素
- 目的に応じた複数のROIの試算式
- 具体例を使ったROIの試算
本連載では以下の内容は取り上げません。
- ROIの試算とは直接関係ないテスト自動化のアンチパターンやベストプラクティス
- 特定のテストレベルやテストタイプに依存するROIの話題
- ROIを試算した後にテスト自動化を成功裏に導入するノウハウ
テスト自動化におけるROIの必要性
筆者は現在、ソフトウェアの第三者検証を専門とするSHIFTという会社に属し、エンタープライズからWeb、ゲームなど多岐にわたる業界のお客さまへテスト自動化やCI(継続的インテグレーション)の導入支援をしています。
このように、テスト自動化を外部から支援する場合だけではなく、社内の品質改善や効率改善の一環としてテスト自動化を推進する場合であっても、人件費をはじめとする自動化のためのコストが発生します。そのため、よほど小規模なものでない限り、予算や契約を取り付けるためには定性的な効果以外に定量的な根拠が必要になります。
すなわち、テスト自動化のためにはどれだけコストが掛かり、いつの時点からコスト削減効果が見込めるのか、また、自動化を続けていく際の継続的なコストはどれだけかなどを定量的に説明できる必要があります。
筆者の案件での経験では、テスト自動化に限らず、何らかの品質改善活動やコスト低減活動には、必要コストの絶対額、コスト削減の絶対額(つまりコスト削減による利益)や損益分岐点までの時間などを根拠にする場合が多いです。
テスト自動化では対象となるテストレベル(*1)、テストタイプ(*2)、使用するツールなどの組み合わせで複数の施策が考えられます。そのような各施策に対して、着手すべき施策を決定したり優先順位付けをしたりするために、各施策が他の施策と比べてどれだけ投資効率が良いのかを比較検討できる必要があります。
- *1:『ソフトウェアテスト標準用語集 日本語版 Version 2.2.J03』(PDF)より。テストレベル(test level):系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
- *2:『ソフトウェアテスト標準用語集 日本語版 Version 2.2.J03』(PDF)より。テストタイプ(test type):コンポーネントまたはシステムをテストするためのテスト活動をまとめたものであり、例えば機能テスト、使用性テスト、回帰テストなどのように特定のテスト目的に焦点を当てている。テストタイプは一つ、または複数のテストレベルまたはテストフェーズで行われる。
このような目的のために、組織や企業の投資効率を「利益 / 投資額 * 100」で求められるROIが利用できます。ROIを利用した場合、投資効率を比率で比較できるため、単純に投資額や投資期間を比較する場合に比べて、複数の施策を比較検討しやすくなります。
単に手動テストに対して自動テストを導入する効果を試算するだけではなく、ユニットテストとシステムテストの自動化、静的検証の導入など複数の施策を同時に検討できるようになります。
テスト自動化の3つの目的とROIの関係
読者の皆さまが自動テストを導入する目的は何でしょうか? テスト実行時間の短縮やテスト対象ソフトウェアの品質向上など、さまざまな目的があると思います。
テスト自動化の目的に対して、テスト自動化の知識体系であるTABOK(Test Automation Body of Knowledge)ではテスト自動化の効果は最終的に以下の3つに集約できると述べています。
- コストの削減:繰り返し実行可能で再利用できる自動テストや、従業員の工数削減、欠陥の早期の発見と修正、再作業の削減によって長期間のコスト削減となる
- 効率の向上:テスト実行時間とスケジュールの短縮によって、テストの効率を向上させる
- ソフトウェア品質の向上:対象のソフトウェアとハードウェアのテスト実行カバレッジを増加させることにより、リリース前の潜在欠陥のリスクとコストを低減する
同時に、効率の向上とソフトウェア品質の向上は障害対応コストを考慮した場合、最終的にはコストの削減に還元できると説明しています。このため、TABOKが解説しているテスト自動化のコンテキストでは、テスト自動化の効果や目的は最終的にはコストという指標に還元でき、ROIで試算や評価できるといえます。本連載でも、このTABOKの解釈を基に、「テスト自動化の目的や効果はコストに還元でき、ROIを試算できる」として解説を進めていきます。
テスト自動化におけるROIの定義
実際にテスト自動化のROIの計算方法を説明していく前に、会計学上のROIの定義を示しておきます。
ROI = (当期営業利益 + 減価償却費) / (株主資本 + 有利子負債) * 100
テスト自動化の場合、直接営業利益につながったり、株式を発行して資本を集めたりしているわけではないため、もう一段階抽象化して、その後テスト自動化のROIで利用する要素を当てはめてみることにします。以下は抽象化したROIの式です。
ROI = 利益 / 投資額 * 100
ROIの構成要素と試算例を解説している『The Return on Investment(ROI)of Test Automation』(PDF)を基に現在手動で行っているテストを自動化した場合を考えてみましょう。自動テストを開発し運用しているある時間「t」の関数をROIとします。
ROI(t) = 利益(t) / 投資額(t) * 100
利益(t) = 手動テストを続けた場合の運用コスト(t) - 自動テストの運用コスト(t)
利益は手動テストを続けた場合の運用コストと自動テストを開始した後の運用コストの差分として定義します。
投資額については2つの解釈があります。
先ほどの『The Return on Investment(ROI)of Test Automation』(PDF)では、以下のように自動テストの初期開発コストのみを投資額としています。
投資額 = 自動テストの初期開発コスト(時間tの関数にはなりません)
一方、『Cost Benefits Analysis of Test Automation』(PDF)をはじめ、他のテスト自動化のROIを解説している記事や論文では、以下のように時間tの関数となる自動テストの運用コストを含めています。
投資額(t) = 自動テストの初期開発コスト + 自動テストの運用コスト(t)
まとめると、投資額に自動テストの運用コストを含めないか、含めるかで以下の2つの式があることになります。
ROI(t) = (手動テストを続けた場合の運用コスト(t) - 自動テストの運用コスト(t)) / 自動テストの初期開発コスト
ROI(t) = (手動テストを続けた場合の運用コスト(t) - 自動テストの運用コスト(t)) / (自動テストの初期開発コスト + 自動テストの運用コスト(t))
式1は分母に自動テストの運用コスト(t)を含めないために、ROIは、同じtではより高い値となり、同じROIを達成するにはより短いtで済むことになります。組織や目的に応じてどちらの式を使用しても構いませんが、同一組織で複数の施策や期間を比較する場合には同一の式を使用する必要があります。
筆者がテスト自動化のROIについての複数の文献を調査したところ、式2に基づく試算や分析をしている文献が多かったため、本連載では以降、式2に基づいてROIの試算式を解説していきます。
次回は、ROIの試算式の構成要素と試算式
ROIの式を構成する要素として以下であることが分かりました。
- 手動テストを続けた場合の運用コスト
- 自動テストの運用コスト
- 自動テストの初期開発コスト
これは単純に上記に関わるエンジニアの工数を積み上げれば出てくるものでしょうか? 例えば、有償ツールを採用した場合、ツールの購入コストが自動テストの初期購入コストに組み入れるのか、あるいは時間tの減価償却コストとして自動テストの運用コストに組み入れるべきか、時間tまでで手動テストと自動テストの実行頻度が異なる場合どのように各運用の実施コストを考えるべきか、障害の対応コストはテストの運用コストに組み入れるべきかなど、実際にROIを試算してみようとすると、まだ分からないことがたくさんあると思います。
次回は、そのようなROIの式の構成する要素を『The Return on Investment(ROI)of Test Automation』(PDF)から引用しながら解説していきます。
著者プロフィール
太田健一郎
大手SIerで開発支援ツール開発SEを経験した後、商用・オープンソースを使った各種の自動テスト、パフォーマンステスト、インスペクションをお客さまプロジェクトで担当。その後、大手Webサービス会社でJenkinsを始めとするCIやテスト自動化、パフォーマンスチューニングなどを担当。
現在、株式会社SHIFTでテスト自動化やCIの導入、トレーニングを担当。その他、コミュニティ活動として、JaSST実行委員会、テスト自動化研究会などに所属し、公私ともにテスト自動化を始めとする自動化に情熱を燃やしている。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- テスト自動化の歴史と今後、良い/悪い事例〜システムテスト自動化カンファレンス2013レポート
テスト自動化を開発の“武器”にするための3つのポイントや、“自動化”の良い事例、悪い事例など、テストの現場を「進化させる」知見が多数紹介されたカンファンレンスの模様をレポートする。 - Selenium WebDriverでWebアプリのテストが変わる(前編):iPhone/Android含むブラウザ自動テストの最終兵器Selenium WebDriverとは
Chrome、Firefox、Internet Explorer、Opera、Android、iOSといったブラウザに対応し、Java、C#、Python、Rubyが使えるWebテスト自動化ツールの3つの特徴と環境、実装方法を簡単に紹介 - フレームワークで実践! JavaScriptテスト入門(5):Capybara-Webkit+Cucumber+Sinon.JSでJavaScriptのテストはここまで変わる
RubyでWebKitをヘッドレス化するフレームワーク、受け入れテストの記述が日本語でできるツール、スタブやモック、スパイが使えるライブラリを組み合わせたテスト方法などを紹介。 - Railsで目指せ、情熱エンジニア(8):実例で学ぶRailsアプリのテスト方法
前回はRailsで使われるテストフレームワークをご紹介しました。今回は具体的なWebアプリを例に、簡単なテストを使ったリファクタリングについて解説します - Androidアプリ開発テスト入門(2):Android SDKでビジネスロジックのテストを自動化するには
Android開発におけるビジネスロジックについて解説し、Android SDKのテストフレームワークの概要と使い方、テストの書き方を紹介します - 特集:受け入れ検査の自動化手法の考察:Windowsアプリの受け入れテストを自動化しよう
単体テストの次は、エンド・ユーザーへの納品時の受け入れテストも自動化したい? それを実現する手法を紹介する。 - 特集:UIオートメーションによる自動UIテスト:WindowsアプリのUIテストを自動化しよう!
Windowsアプリのユーザー・インターフェイス、どうやってテストしていますか? 単体テストで徹底的に自動化して開発効率アップ! - 連載:ASP.NET MVC入門【バージョン3対応】最終回 テスト自動化でアプリケーションの品質向上
M、V、Cに明確に分離されたアプリ構造は従来に比べ単体テストも実施しやすい。テストの基礎からモック・ライブラリ活用までをまとめる - PHP開発者のためのテストのすゝめ(1):ユニットテストはなぜ必要なの?
開発の全工程の中で、あまり人気がないのがテスト工程だ。ソフトウェアの品質を証明するためのテストは、なぜ低く見られてしまうのか - Eclipseプラグインq4eでカンタンMaven入門(前編):ビルドやテスト、依存ライブラリ追加は自動化できる!
ビルドやテスト、レポート作成、依存ライブラリ追加を自動化するMavenと、その操作を簡単にするEclipseプラグインを紹介 - 第1回Androidテスト祭りレポート:Android開発で泣かないための「テスト」の重要性
その自由度の高さや多様性ゆえに、さまざまな課題を抱える、Androidアプリ開発の“テスト”に焦点を当てたイベントの模様を紹介します - UX Clip(28):JavaScriptのテストを開発工数に入れてもらうには?
Webアプリの大規模化とフロントエンド領域の拡大により、JavaScriptのテストの必要性が高まっている。数ある高機能なテストフレームワークをどう使いこなせば、高速かつ高品質な開発が可能になるのだろうか。