テスト自動化

一言でいうと

人が手作業で繰り返していた確認を、プログラムとして書き、変更のたびに自動で実行できるようにする取り組みです。

提唱者と登場年

テストをコードとして書き、自動で実行する形は、Kent BeckがSmalltalk向けに作ったSUnitからJUnitを経て、xUnitと総称されるテストフレームワークとして各言語に広がりました。

自動化するテストの配分を示した考え方としては、Mike Cohnが2009年の著書『Succeeding with Agile』で示したTest Automation Pyramidがよく参照されます。Martin Fowlerの解説によれば、Cohnはこの図で、単体テストを土台に多く置き、画面を通したテストを頂点に少なく置く形を示しました。画面を通したテストは遅く、システムの改修で壊れやすいためです。テスト技術者の資格を運営するJSTQBのシラバスも、このテストピラミッドを取り上げています。

何を解決するか

変更のたびに行う確認の手間と見落としを減らします。手作業の回帰テストは、機能が増えるほど時間がかかり、リリースの頻度を上げる妨げになります。自動化すれば、同じ確認を数分から数十分で何度でも実行でき、壊れた箇所を変更の直後に見つけることができます。

自動化は、同じ確認を繰り返し実行する場合に効果を発揮します。一度しか行わない確認や、仕様が頻繁に変わる画面の確認は、テストコードの保守の手間が効果を上回ることがあります。

実際の進み方

どの確認を自動化するかを、実行の頻度、壊れたときの影響、保守の手間から選びます。テストピラミッドに沿うなら、単体テストから始め、APIの結合テスト、画面を通したエンドツーエンドテストの順に範囲を広げます。

書いたテストはCIに組み込み、変更のたびに実行します。JSTQBのシラバスは、テストの四象限のうち、単体テストと部品の結合テストを自動化してCIのプロセスに含めるべきだとしています。失敗したテストを放置しない運用と、不安定なテストを直す時間の確保が、自動化を続ける条件になります。

導入でよくある失敗

• 画面を通したテストから自動化を始め、実行が遅く不安定なテストが増える
• 自動化の件数や割合を目標にし、価値の低いテストの保守に時間を取られる
• 失敗が常態化したテストを放置し、結果を誰も確認しなくなる

求人票にこの語がある場合に読み取れること

QAエンジニアやSETの求人にテスト自動化とある場合、手作業のテストを中心にしてきた組織が自動化へ移行する段階か、既存の自動テストを拡充する段階かで、求める経験が異なります。候補者には、どの粒度のテストを自動化したか、使ったツール、テストの実行時間と不安定なテストへの対処を確認してください。

隣接手法との違い