テスト自動化のメリット〜欠陥特定の改善〜
この記事はソフトウェアテストあどべんとかれんだー2014の12月15日のブログ記事として執筆しています。
昨日はKyon Mmさんのパフォーマンステストについての記事でした。
この記事は最近見かけたクソコードから思いつきで書いています。内容はテスト自動化のTipsですが、普通のプログラマーにとっては当たり前レベルの内容です。
バッググラウンド：テスト自動化のROI
テスト自動化を始める際一番最初にテスト自動化のROIについて議論します。例えば４回以上繰り返し実行するテストを自動化すれば元が取れるとか、テストスクリプトの保守のためのコストを低減するための工夫を取り入れようとか。昨日開催されたシステムテスト自動化カンファレンスでも、共有スクリプト、データ駆動テスト、キーワード駆動テストなどの手法によりテストスクリプトのメンテナンスコストを抑えようというお話がありました。
この話は至極もっともで私がテスト自動化を行う時も必ずそうします。ですがこの辺りの議論について、コスト=投資を最小化する話ばかりでメリット=利益の最大化の議論が少ないなあと思っています。テスト自動化に対してメリットがあるから投資をするわけで、そこを無視して議論したらそれは減価償却ではないのか？とか。
ではテスト自動化のメリットとは何か？
昨日のシステムテスト自動化カンファレンスのKyon Mmさんの発表スライドを引用。
テストを自動化する事が正しいのではなく、ソフトウェア開発自体をよいサイクルにすること、そしてリリースにかかる時間を短くするための有用な選択肢
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン 17p
ソフトウェアの開発サイクルやリリースに存在するボトルネックを解消出来る事がテスト自動化のメリットである、この意見に私も賛成です。
システムテストの典型的なボトルネック
コンポーネントの完成を待ってからでないと開始出来ないという事情により、システムテストではコンポーネントの結合、欠陥特定とバグ修正にボトルネックがある事が典型的です。もちろんシステムテストそのものの実施に時間がかかっているというケースもあると思いますし、そういう場合はテスト実行そのものの効率化が目的になるでしょう。ですが開発サイクルを俯瞰した場合、多くの場合のボトルネックは欠陥特定とバグ修正なのではないでしょうか？
今年のJaSST'Tokyoではシステムテストの自動化によりバグ修正コストを中央値で５日から２日に短縮した事例を発表しました。
「システムテストの自動化に失敗するプロジェクトも多いが、何故この事例では成功したのか？」と聞かれる事がしばしばあり、社外のエキスパートの方達とディスカッションをしながら改めて自分の中で整理する機会がありました。そこで導きだした答えは「システムテストのボトルネックであった欠陥特定の問題を解消し、バグ修正日数の短縮というメリットの最大化に成功したから」です。
欠陥特定の短縮というメリット
開発プロセスにテスト駆動開発やCIを導入して、ちょっとずつテストをしながら機能の実装をしていくようにすると、まとめてテストをする場合に比べてはるかに早く欠陥特定が出来るという経験をした事のあるプログラマーは多いのではないでしょうか？
当たり前ですよね。ちょっとずつテストで確認をしながら実装をすれば、もしテストが失敗したとしてもその原因は直前のソースコード変更にあるはず。だから膨大なソースコードの中から欠陥特定するよりもはるかに早く済む。これと同じメリットをシステムテストの自動化でも享受する事が出来るのです。
例外処理設計とログレベル設計
では、そのメリットを最大化する為にはどういった工夫が必要か？テスト戦略とかデプロイメントパイプラインとか障害許容性とか移植性とか色々あると思いますが、ここでは例外処理設計とログレベル設計を取り上げます。
自動テストの実行結果からの欠陥特定という文脈で考えたとき、単体テストとシステムテストでは大きな違いがあります。（もしかしたらこの主張が正しいコンテキストはWeb系だけかもしれませんのでご注意ください。）単体テストでの欠陥特定はIDEのデバッグ機能等を使って簡便に行う事が出来ますが、システムテストでは疑似本番環境にデプロイしますし、コンポーネントも複数ありますのでIDEのデバッグ機能のように「１ステップずつ実行」という事が出来ません。
いや、やれば出来るのは分かります。でもそんな事するよりも、本番運用と同様の例外処理設計とログレベル設計をしっかり行い、テストのログを見るだけで欠陥特定する事を可能にした方がスマートです。
前述のJaSSTで発表した事例でバグの修正日数を５日から２日に短縮出来たのは、システムテスト自動化後、テストのログとソースコード変更履歴を１０分から１時間くらい見るだけでほとんどの欠陥特定を行えるようになったからです。
例外処理にまつわるクソコード
この記事を書いてみたモチベーションは、最近いくつかの場所で下記のようなクソコードを見た事です。
public void method() throws Exception {
try {
// some logic
} catch (Exception e) {
// some logic
throw new Exception("An error message");
}
}
このコードでもExceptionが起きない正常処理は問題なく処理出来ますし、どんなException が起きても例外処理はしてくれます。そういう意味ではソフトウェアは動きます。でもこうしてしまうと
- 異常系のテストが書けない。例えば「異常な入力に対しIllegalArgumentExceptionが発生する事」「通信先に障害が起きている時にConnectionRefusedExceptionが発生する事」を区別して書けない。
- 実際に例外を処理している部分がどんなExceptionも同じものとして処理してしまうので、テストが失敗した時に実際に何が起きたのかをログから追跡する事が出来ない。
という問題が生じます。こんなコードが至る所にあるような場合、欠陥特定やバグ修正に関するボトルネックの解消が達成出来なくなってしまうのではないかという気がしてなりません。
おわりに
普通にテスト自動化に成功している人達にとっては”当たり前”の話ですみません。色々なもやもやに対する勢いだけで書きました。
ただ、「開発者はテストをしない」と嘯くと開発とテストの良好な関係を築くのが難しいのと同様に、「テスターに欠陥特定は関係ない」と嘯く事もまた開発とテストの関係を悪化させてしまう原因になると思います。
開発とテストの関係をよりよいものにするために、「欠陥特定の改善」を目的としたテスト自動化に着手してみるのはいかがでしょうか？
---
明日12/17はnemorieさんです。よろしくお願いします。
