テスト自動化はテスト実行を効率化する正攻法だ。多くの現場が取り組もうとしている。ただ、知らないと陥りがちな落とし穴があり、テスト自動化の適用に失敗してしまう現場も少なくない。テスト自動化を失敗させる典型的なケースと、そこからの脱出法を紹介しよう。

 テストを効率化するため、テスト自動化に取り組む現場は数多い。思った通りに工数や工期の削減を実現できる現場もあれば、テスト自動化の適用に失敗してしまう現場もある。失敗した現場では、せっかく構築したテスト自動化の仕組みが使われなかったり、本来の目的とは逆に工数や工期の足を引っ張る存在になったりする。今回の前半では、テスト自動化を失敗させる主な原因となる4個の間違いを基に、適切にテスト自動化を導入するコツを解説しよう。後半では、アジャイル開発でテスト自動化を適用する場合のポイントを説明する。

テスト自動化に失敗する
現場が犯している4個の間違い

 手間のかかっていたテストを自動化したが、システムの機能更新のたびにテスト自動化用のスクリプトの変更に追われている。だんだん業務が追いつかなくなり、スクリプトの変更は放置されるようになった。せっかくテスト自動化の仕組みを整備したのに役立たずの代物と化した―。テスト自動化を導入した現場でよくある失敗例だ。

 テストの自動化では、リリース前に画面上で行うテストを「Selenium」などのテスト自動化ツールを使って人手を使わずに実施できるようにする。あらかじめテスト担当者がテストの手順を定義して、テスト自動化ツールに読み込ませるプログラム(テストスクリプト)を作成する。一度テストスクリプトを作成すれば、その後のテストはテストスクリプトのジョブを実行するだけで済む。

 テスト自動化が主に採用されるのは、プログラムの一部の変更でほかの箇所に不具合が出ていないかを確認する「リグレッションテスト」と呼ばれるテストだ。例えば新バージョンを開発した際、新たに実装した機能だけをテストすればいいのではない。機能追加・変更が既存機能に影響を及ぼしていないかもテストを実施する必要がある。これがリグレッションテストだ。

 昨今のソフトウエア開発では、開発スケジュールの短納期化、リリースの早期化を求められる。その結果、リグレッションテストを実施する頻度はますます高まっている。毎回のように同じテスト手順となるリグレッションテストを自動化して、テスト全体の期間や工数を減らそうとする現場が多い。

 ただ、安易にテストの自動化を適用すると失敗してしまう。テスト自動化に失敗した多くの現場は、適用後の長期的な運用への想定が欠けている。例えば、テストスクリプトの保守がそうだ。テスト自動化を適用したシステムで機能や画面に変更があると、それに応じてテストスクリプトも改修しなければならない。改修があまりにも度重なると、テストスクリプトの保守工数がプロジェクトを圧迫する。予定した工数を上回るような状況になると、テストスクリプトの更新が機能追加・変更に追いつかなくなる。結果、テスト自動化が利用されなくなってしまう。

 筆者の経験から、よくあるテスト自動化の失敗要因を4個に類型化したのが図1だ。「(1)自動化に不向きなシステム」は、不向きなシステムに対してテスト自動化を適用してしまうといった例。テスト自動化のために投資したコストを回収できなくなる。「(2)適用タイミングの誤り」は、テスト自動化の適用タイミングが早すぎるといったケースだ。テストスクリプトの実装で手戻りが生じる。「(3)変化に弱いテストスクリプト」とは、テストスクリプトの作りが悪いといった失敗要因だ。ちょっとした画面の変更のたびにテストスクリプトの修正が必要になる。「(4)コーディング規約の欠如」では、テスト対象が自動化を意識したプログラムの書き方になっていない。テストスクリプトの実装・保守に手間がかかる。

図1●テスト自動化で陥りやすい4個の失敗
[画像のクリックで拡大表示]

 以下では4個の失敗要因を基に、テスト自動化に失敗しないためのポイントを解説しよう。適切な方法でテストを自動化できれば、プロジェクト全体の工数を削減できる。ヒューマンエラーの防止にもつながる。テスト自動化を適用すると、コンピュータが同じ内容を正確に繰り返すようになるからだ。こうしたメリットを十分に引き出せるようにしてほしい。全ての完璧な実践は難しくても、できるだけ心掛けると失敗の可能性を減らせるはずだ。

(1)自動化に不向きなシステム

 テスト自動化には向くシステムと向かないシステムがある。その見極めが重要だ。

 一般にテスト自動化の効果はテストを実行する回数が多くなるほど増大する。図2は横軸をテスト実行回数、縦軸をテストにかかる累積工数として、手動テストと自動テスト(テスト自動化を適用後のテスト)の工数をプロットしたイメージ図だ。手動テストは初期投資はかからないが、テスト実行のたびに大きめの工数がかかる。一方、自動テストはテスト実行工数は小さいものの、初期投資が必要になる。自動テストでは、自動化基盤の構築やテストスクリプトの作成などを実施しなければならないからだ。

図2●自動テストと手動テストのテストにかかる工数の比較
[画像のクリックで拡大表示]

 自動テストでは、テスト実行回数がゼロでも工数がかかっている。そのため、テストの実行回数が少ないと、テストにかかる累計工数は自動テストのほうが大きい。テスト実行回数が多くなると、自動テストのほうが累積工数が小さくなる。手動テストの累計工数と自動テストの累計工数がクロスする点が、テスト自動化の損益分岐点である。損益分岐点を超えるシステムかどうか、テスト自動化を適用する前に検討しておいたほうがよい。

 環境やシステム、要員スキルによる差異はあるが、筆者の経験では「機能追加や修正といった変更回数が月1回(年12回)を下回るシステムでは、テスト自動化が十分な効果を発揮しづらい」と感じる。テストの実行回数はプロダクトやシステムの性質に依存する。例えば1カ月に複数回の変更を行うようなシステムは、リグレッションテストの回数がそれだけ多く、テスト自動化に向いている。一方で、変更が半年に1回しかないようなシステムはリグレッションテストを行う機会が少ない。テスト自動化を適用しても、その導入にかかるコストや労力に見合った効果は得にくい。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら