テスト自動化の8原則

1. 手動テストはなくならない

2. 手動でおこなって効果のないテストを自動化しても無駄である

3. 自動テストは書いたことしかテストしない

4. テスト自動化の効用はコスト削減だけではない

5. 自動テストシステムの開発は継続的におこなうものである

6. 自動化検討はプロジェクト初期から

7. 自動テストで新種のバグが見つかることは稀である

8. テスト結果分析という新たなタスクが生まれる

これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。

解説

1. 手動テストはなくならない

ユーザビリティテストなど、そもそも自動化できないテストタイプが存在する。システムに対してはじめて実行されるテストはテストケース自体の成熟度の観点から、手動で実施したほうがテスト実行の品質が高いケースが多い。また、自動化がうまく進行している機能テストの残り数％など、テストを自動化するコストとベネフィットが釣り合わないケースもある。これらの事情によって、手動で実施されるテストが無くなることはない。

2. 手動でおこなって効果のないテストを自動化しても無駄である

そもそも、テストプロセス（e.g.テスト分析、テスト設計、テスト実装、報告）、特にテスト分析、テスト設計が適切に行われていないテストは、優秀なテスターが手動でテストを実施したところで、テストに期待される動作の保証やバグの検出といった効果を発揮しない。いわんや、自動テストにおいておや、である。

3. 自動テストは書いたことしかテストしない

人間による手動テストは、テストケースの記述に対して驚くほど広範な要素を暗黙的にテストしている。これに対し、操作、合否判定を厳密に記述する必要がある自動テストにおいては、おのずと視野は「記述された様に」限定される。ユーザ名とパスワードを入力してログインする、といったテストが自動化されていたとして、その自動テストは仮にログイン画面に表示されているロゴが競合他社のものであったとしても、それに気づくことはない。

4. テスト自動化の効用はコスト削減だけではない

もし、テスト自動化によってなんらかのコストが削減できるとしたら、十分に成熟しているテストケースが既に存在しており、そのテストは今後何度も実行される予定があり、自動テストの開発を円滑に進めるための準備が完了している場合と、テストの手順が同じで、テストすべきデータが膨大に存在する場合の「テスト実行」のコストである。テスト自動化には、繰り返し型開発におけるセーフティネットとしての役割や、バグ修正日数の低減、影響範囲レビュープロセスの代替、といった、開発アクティビティへの効用も存在するため、冒頭にあげたひどく限定された局面を狙うより勝ち目があるかもしれない。

5. 自動テストシステムの開発は継続的におこなうものである

テスト自動化に関わる苦労を10とすると、自動テストシステムが完成するまでが3、残りの7は運用に関するコストである。テスト対象の変化への追従、テストケース、テストタイプ自体の追加、変更に対する適応、といった、今あるものが継続的に効果を発揮するための活動はもとより、自動テストのターンアラウンドタイムの向上、信頼性の向上、などなど、システムの価値を向上させていくための活動など、やるべきことは多岐に亘る。テスト自動化システムの提供はプロジェクトというよりサービスとしてとらえるべきである。

6. 自動化検討はプロジェクト初期から

自動化を考慮せず「出来上がってしまった」システムに対して自動テストを書いていくことは、よくあるテスト自動化エンジニアの苦行のひとつである。自動テストシステムがシステムをよりよく操作、判定できるように、ひいてはセーフティネットを最適なコストで構築するためにはシステム側で最初から検討して設計に織り込んでおく必要がある。また、繰り返し実行されるテストが予めわかっているなら、自動化を前提として、テスト計画を策定すれば効果的である。

7. 自動テストで新種のバグが見つかることは稀である

運用に乗った自動テストは基本的に「枯れた」テストケースを対象とするため、ほとんどの種類のバグはテストケースを枯らす過程、あるいは自動テストを実装する過程で既に人間によって発見されているはずである。多くの運用に乗った自動テストの意義は「一度動いたはずの機能がうっかり壊れる」ことを最速で発見することにある。ただし、手順が同じでデータの種類が膨大なテストを自動化する場合、ファジング、テストパターンを有機的に生成できるAPIレイヤのテスト、ブラウザやRDBなどのバージョンアップの影響を受けていないことを確認するテストなど、いくつかの例外もある。

8. テスト結果分析という新たなタスクが生まれる

マニュアルテストでバグが発見された場合、その再現手順は明らかであるから人間はある程度の最適化ののち、即座にバグ登録を行う。しかし、自動テストがFAILEDを出してきた場合、何が起きたのかを改めて人間が確認する必要がある。これが1日数件ならまだかわいいものであるが、自動テストが無事？拡大した結果、数万件のテストケースに対して数千件のFAILEDが検出されたとしよう。それを種類ごとに仕分ける作業だけでも憂鬱である。自動テストが拡大した結果、テスト結果分析のコストがそれに伴ってリニアに伸びないような施策、例えばコールスタックやAPIコール履歴などから、ある程度自動的にFAILEDを仕分ける機構などを検討する必要がある。

2016.4 テスト自動化研究会 ※本原則は定期的に見直しをおこなっています。