TABOK粗読による自動化の座学 - カテゴリー1「テスト自動化の役割」(3)W. Charles Slavin. Software Peer Reviews: An Executive Overview. Cincinnati SPIN. January 9, 2007.
第4回、ようやくsegment2（カテゴリ1）が終わりですね。
www.kzsuzuki.com自動化のROI
さあ、自動化がうまくいってテストエンジニアが単純労働から解放された！・・・としても、浮いた時間や、その浮いた時間によって得られる新しい取り組みの成果が、ツール導入にかけたコストより小さかったら・・・。金勘定をする人は怒りますね。
導入の前に、その効果の見積もりをエライ人にアピールすることが必要でした。導入後も、ツール導入への投資によって得られる収益ROI(Return On Investment)の報告が継続します。ちょっと油断すると、せっかくの成功が忘れられたり、またぞろ例の誤解が這い寄ってきます。
導入の効果としてのROIを測る方法は、実は金額だけじゃありません。TABOKでは、3つのROIを紹介しています。
- いくら節約できた？
- どんだけ効率上がった？
- どんだけリスク減った？
どれかが絶対というわけではなく、目的に応じて、使い分け、組み合わせて用います。
単純なROI（Simple ROI）
コストに基づく計算で、一番わかりやすいですね。ツール導入にかかったコストに対して、節約できたコストの比率を見ます。
コストはたとえば、ツールの代金、トレーニング、スクリプト作成と維持。成果はたとえば、テストエンジニアの工数削減。
「従来より早い工程で欠陥を摘出できた」というのも、成果です。hpの研究では、要件定義時点で直しておけば1ドルで済む欠陥も、それがリリース後に出てしまうと、改修に109ドルもかかるよと言っているようです（元資料*1、見つけられませんでした）。
コストはたとえば、ツールの代金、トレーニング、スクリプト作成と維持。成果はたとえば、テストエンジニアの工数削減。
「従来より早い工程で欠陥を摘出できた」というのも、成果です。hpの研究では、要件定義時点で直しておけば1ドルで済む欠陥も、それがリリース後に出てしまうと、改修に109ドルもかかるよと言っているようです（元資料*1、見つけられませんでした）。
ただ、計算する側にとっては、推定の難しい金額があるのが難点。たとえば、「早く見つけたから108ドル節約できました」という主張がどれだけ説得力をもつか、ということです。いわゆる「鉛筆をなめる」ということができてしまいそうですよね。
効率のROI（Efficiency ROI）
これは、エライ人向けじゃなく、どちらかといえば現場寄り。効率の向上、つまり「いかに楽になったか」を表現します。
よって用いる量は、コストじゃなく、時間。もちろん節約した時間で他のもっと人間的な手動テストをやることになるのですが、手動から自動に置き換えた部分でいかに楽になったか、ですね。
よって用いる量は、コストじゃなく、時間。もちろん節約した時間で他のもっと人間的な手動テストをやることになるのですが、手動から自動に置き換えた部分でいかに楽になったか、ですね。
リスク低減のROI（Risk Reduction ROI）
これは実は、「投資収益率」とは言いがたいかも知れません。ここで表現するのは、自動化の収益として、いかにリスクを下げられたか。
リスクの単位って？ということになりますが、そこは様々で、たとえばテストのカバレッジ。これまで2因子網羅でやってた組み合わせテストを、自動化を使って3因子網羅しました！とか（それが正しいかどうかは別にして）。また逆に、浮いた時間でこんな探索的テストをやりました！というのもあります。
気になるのは、それを定量的に表現するのが難しく、どうしても主観が入ってしまう点ですね。
リスクの単位って？ということになりますが、そこは様々で、たとえばテストのカバレッジ。これまで2因子網羅でやってた組み合わせテストを、自動化を使って3因子網羅しました！とか（それが正しいかどうかは別にして）。また逆に、浮いた時間でこんな探索的テストをやりました！というのもあります。
気になるのは、それを定量的に表現するのが難しく、どうしても主観が入ってしまう点ですね。
ROIを高めるには
ROIの式と、それぞれの項を構成する要素を眺めてみると、向上にはいくつかのアプローチがあります。
たとえば自動化したテストの実行時間。短くすれば別のテストを追加することで、リスク低減のROIを向上できるかも知れません。
そのためにできることは、たとえば、自動実行中にコケた場合の仕組み。「よーし、おれは帰るから、明日の朝までにリグレッション終わらしとけよー、アディオス☆」とか言って朝出社してみたら1個目のテストでコケてたら絶望しますよね。想定外の事象からうまく立ち直れる仕掛けをどう作りこんでおくかがカギになります。
そのためにできることは、たとえば、自動実行中にコケた場合の仕組み。「よーし、おれは帰るから、明日の朝までにリグレッション終わらしとけよー、アディオス☆」とか言って朝出社してみたら1個目のテストでコケてたら絶望しますよね。想定外の事象からうまく立ち直れる仕掛けをどう作りこんでおくかがカギになります。
自動テストのメンテナンス時間は、効率のROIに関わってきます。TABOKでは、自動テストを行うために最初に作るフレームワークやプロセスに十分な時間をかけることが大切と言っています。ただここでいう自動化の「フレームワーク」「プロセス」とは一体何？ということには言及がなく、今後のsegmentで説明されるものと思います。
さて、次回はSegment3（カテゴリ2）ですが、こちらはたったの7ページなのです。多分1回で終わる。合計5回をもって、TABOK紹介ファーストシーズンを終わる予定です。セカンドシーズンは7月予定。
*1:W. Charles Slavin. Software Peer Reviews: An Executive Overview. Cincinnati SPIN. January 9, 2007.
