UIテスト自動化の流れをおさらい 導入から運用までのライフサイクルを振り返ろう：一から分かる！ テスト自動化（終）
テスト自動化に取り組みたいけれどノウハウがない、過去に導入していたがうまくいかなくてやめた人に向けて、テスト自動化の「あるある」な失敗事例とともにどうすればうまく取り入れられるのかを解説する本連載。最終回はテスト自動化のライフサイクルについて。
これまでの連載で、テスト自動化にまつわるさまざまな問題と、それをどのように解決するのかをお伝えしてきました。今回は連載の総まとめとして、テスト自動化のライフサイクル、つまり導入から運用、そして運用停止までの流れを解説していきます。
テスト自動化技術の進歩に伴い、テスト自動化の範囲やできることも今後増大していくでしょう。しかし、ここに記載した内容は今後も基本の考え方として使えます。
UIテスト自動化のライフサイクル
それでは、UIテスト、つまりユーザーが実際に画面などを操作して行う処理を想定したテストの自動化について、ライフサイクルを見ていきましょう。原則として、他の部分（単体テストやAPIテスト）の自動化も同様です。しかし、UIテストは特に導入や実行にコストがかかるという点で、ライフサイクルを意識していくことが求められます。
1．事前調査
まず、テスト対象システムがそもそも自動化可能かどうかを調査します。対象システムが使用している環境やプログラミング言語によってはテスト自動化ツールが十分に備わっていない場合もあります。自動化ツールを自作するという方向もありますが、非常に高コストであるため、見合った効果が得られるかどうかを慎重に検討した上でツール自身の作成に取り組むべきでしょう。
また、一般のツールなどが使用可能であったとしても、コストがかかりすぎるようであれば自動化のメリットを受けることは難しいでしょう。ここでいうコストとは、自動化ツールの導入費用や保守費用といった金銭的なコストもありますが、どちらかというと工数的なコストの方を重要視すべきです。なぜなら、テスト自動化の導入メリットは、テスト実行に人の手をかけないことによる工数的なメリットが大きいため、その部分での効果を最大限に発揮する必要があるからです。テスト自動化の作業には、自動化したテストの環境構築やスクリプト作成、そして実行手順の作成など、大小さまざまな作業が必要になります。それらの実施時間をきちんと見積もることが大切です。
Webシステムの自動化などで画面の要素にIDが割り振られていない場合、どの要素を操作するのかをX-PATHなどの相対的な形で指定することがあります。しかし、そうすると画面のレイアウトが変わるたびに自動化スクリプトを修正する必要が生じ、自動化のコストが想定よりもかかってしまった、ということが実際にありました。場合によってはテスト対象のシステムを自動化しやすくするように、開発チームの協力を依頼することも有用でしょう。
2．フィジビリティスタディ
事前調査の結果、導入を検討することになった場合、次にすることがフィージビリティスタディ（実現可能性調査）です。フィジビリティスタディについては第3回で詳しく解説していますので、そちらをご覧いただくとして、ここではフィジビリティスタディで行う試験的な導入において、どのような部分をまずは自動化してみるとよいかの指針をお伝えします。
まず、重要な機能などをフィジビリティスタディに選ぶことは避けた方がよいでしょう。テスト自動化の導入によって開発が遅延したり、バグが発生したりしてしまっては本末転倒です。テスト自動化の導入初期にはどうしても問題が生じてしまいます。その際に影響が大きくなることは避けるべきです。
そして、あまりにも単純すぎる機能で実施するのも問題があります。フィジビリティスタディは、テスト自動化を本格的に導入した際に生じる問題点などを早めに洗い出して効果を検証することにあります。そのため、簡単に実現できる部分で検証してしまうと、問題を洗い出すことができず、本導入の後にトラブルが頻発する事態にもなりかねません。ある程度複雑な機能で実施することが重要です。
3．導入
フィジビリティスタディの結果、導入するとなった場合にも幾つか注意点があります。まずは、テスト環境の構築やテストスクリプトの作成について、きちんと手順を明確にしてマニュアルやガイドラインを整備していくということです。ここまでの連載の通り、属人化を可能な限り排除し「この人がいないと自動化できない」という状況を作らないことがテスト自動化成功の第一歩といえます。導入時点から、多少手間がかかったとしても属人化しない仕組みを構築しておくことが重要です。また、合わせてメンバーの教育についても計画的に実施していくことが大切です。
もう1つ重要な準備が、ツールのバージョンアップについてきちんと調査し、対応する体制を構築しておくということです。テスト自動化は、開発期間中ずっと実施するものではなく、テスト工程に入ってから開始することが多いでしょう。その際に、最新版のツールにバージョンアップしておらず、いざ実施の段になってうまく動作しないといったトラブルが発生することがよくあります。実際に動かす前にきちんとバージョンアップをしておく、定期的に動作テストを実施するなどの対策を採るとよいでしょう。
自動化の適用範囲についても、一度に全ての機能を自動化するのではなく、導入しやすいところから段階的に進めていくことが効果的です。その場合も途中で尻切れトンボにならないよう、計画を立てて進めていくとよいでしょう。
4．運用、保守
テスト自動化は運用し続けることこそが重要です。途中で止めてしまうとコストメリットを得ることができません。ですので、ここまでのプロセスでも非常に丁寧に解説してきました。運用が始まった後にも注意すべき事項があります。
まずは、ツール自体の不具合対応やメンテナンスなど、いわゆる保守に関する工数をきちんと確保しておくことが挙げられます。テスト自動化ツールもソフトウェアであることは変わりなく、テスト対象のシステムと同様に保守の対象とします。そういう認識を持ち、問題が発生した際に迅速に対応できれば、陳腐化を防ぎ運用し続けることが可能になります。
また、テストスクリプトとテストケースとの乖離（かいり）には注意する必要があります。テストしなければならない内容はテストケースという形で人間の分かる形にしておくことが望ましいのですが、時間がないなどの理由で、テストスクリプト（プログラム）のみを仕様変更に合わせて修正するようなことも起こってしまいます。そのズレを修正しないまま時間がたってしまうと、何が正しいのかが分からなくなり、結果としてテストケースやテストスクリプトにも大幅な修正が必要となります。そして修正工数がかさみ、テスト自動化が暗礁に乗り上げてしまいます。自動化する部分に関しても、しっかりとテスト設計を行うことが重要です。
自動化ツールを運用し続けるためには、テスト対象システムの機能変更や機能追加にも対応する必要があります。場合によってはツール自体の機能を拡張する必要があるでしょう。そういった機能拡張についてもドキュメント化し、担当者が代わっても引き継ぎできるように準備しておくことが求められます。
また、キーワード駆動型のテスト自動化ツールを導入することも有効です。キーワード駆動とは、プログラム言語による操作の記述を日本語などの「キーワード」に置き換えて、キーワードを指定してテストスクリプトを記述することで、テストケースとテストスクリプトを一致させることです。そうすることで、テストケースを修正すると自動的にテストスクリプトも変更されます。また、工数の削減やテストスクリプト作成のためのプログラミングスキルの習得が不要となります。いいことずくめのように聞こえますが、対応するツールがテスト対象システムに合致するかどうか、ツールのサポートが必要不可欠となるため、それを利用できる体制があるかどうかなどを、導入時に検証することが重要です。
5．運用停止・次期ツールへの引き継ぎ
どのようなツールでも永遠に使い続けられるものはありません。テスト対象システム自体の刷新や、テスト自動化ツールのサポート停止など、さまざまな理由でツールはその役目を終えることになります。また、ツールの運用コストがメリットを上回る場合にもツールの使用を停止することになります。ツールの運用を停止する場合には、担っていた機能を後継のツールなどに置き換え、現行ツールのデータやスクリプト、ドキュメントなどはアーカイブとして保管します。
次期ツールへの引き継ぎについても、以前の資産が流用できるのであれば積極的に行うべきですが、テストスクリプトやテスト環境などのツールの実装にまつわる部分については大きく手を入れることが通常です。逆に、テストケースやテストデータなどのテスト対象システムと関わる部分については共通して使用できることも多いので、新ツールの導入に関する事前調査にはその当たりの検討も含めるべきでしょう。ただし、使い回しにこだわるあまり、運用や保守に余計な工数がかかってしまうと本末転倒なので、バランスを考えることも重要です。
連載の終わりに
ここまで、テスト自動化のライフサイクルについて解説してきました。テスト業務には、手動で実施する場合に「その場の判断」で採られてきた表に出ない作業や検討事項が幾つもあります。テスト自動化ではそれらを事前に丁寧に考慮しなければなりません。考慮事項を一つ一つ押さえてクリアしてこそ、テスト自動化を制することができる、といえるでしょう。
連載を通じて、テスト自動化に関する「現実」をいろいろとお伝えしてきたように思います。非常に厄介なことも多いのですが、その分うまく軌道に乗ったときの恩恵もまた非常に大きなものです。また、テスト自動化の技術も近年大きく発展しており、高品質で高採算なシステム開発にますます貢献できると思います。ここでまとめたテスト自動化の考え方を使っていただければ幸いです。
筆者紹介
江添 智之
クロス・ファンクショナル事業部 R&C部 マネージャー
Web系、エンタープライズ系、医療系などさまざまな開発業務にプログラマー、システムエンジニア、プロジェクトリーダーとして携わった後、バルテスにてテストエンジニア、コンサルタント業務に従事。現在は、主にテスト業務に関する研究開発および人材育成を担当。Scrum Alliance認定スクラムマスター、ディープラーニング検定（G資格）、ネットワークスペシャリスト、データベーススペシャリスト、JSTQB Advanced Level（テストマネージャ、テストアナリスト）など、ソフトウェアの開発およびテストに関する資格を多数取得。JaSST Kansai 実行委員。同社が運営するソフトウェア品質向上プラットフォーム「Qbook」の執筆を担当するなど、ソフトウェア開発に携わるエンジニアに対しての情報発信を積極的に行う。
Copyright © ITmedia, Inc. All Rights Reserved.