テスト自動化の運用における3つの課題
バルテスグループは、ソフトウェア開発におけるV字モデルの上流から下流まで、品質向上を支援する事業を展開する企業である。同グループのバルテス株式会社では、ソフトウェアテストの支援に加え、日本語で書かれたテストケースをスクリプトに変換できる月額3630円～（7月24日現在）利用できるテスト自動化ツール「T-DASH」も提供している。江村氏は、20年以上にわたりWEB業界に携わり、アプリケーション開発やプロダクトマネジメント、QA組織の立ち上げ、テスト自動化プラットフォームの構築など、さまざまな経験を積んできた。現在は、同グループ内のバルテス・ホールディングスでテスト自動化のエバンジェリストとして社内外で活動している。
テスト自動化には、仕様の追加や変更時にスクリプトを修正する必要があり、テストの実行や結果の分析、さらにテスト自動化の品質改善など、さまざまな運用が伴う。江村氏は代表的な3種の運用について説明した。
まずは、仕様の追加や変更時のスクリプト修正だ。仕様が追加されると、テストカバレッジが低下するため、新たなスクリプトの開発が必要になる。江村氏は「この作業はかなり手間がかかる」と指摘した。仕様変更が発生した場合、既存のテストスクリプトが動作しなくなる可能性があるため、画面要素や、テストステップの修正が求められるからだ。
2つ目は、テストの実行と結果の分析だ。一般的にJenkinsなどのツールでテストが自動実行されるケースが多く、失敗した際にはアラートが発生する。次に、その失敗の原因を実行レポートから調査し、アプリケーションのバグやテスト自動化自体の問題、ネットワークなどの外部要因など、原因を特定する。最後に、アプリケーションのバグであれば修正後に再テストを実行し、成功すれば作業が完了する。江村氏は「この作業は地味ですけど大変です」と話した。
3つ目は、テスト自動化の品質改善。テスト自動化もアプリケーションの一部であり、その品質が低ければ誰も信頼しない。したがって、品質改善は継続的に行う必要があり、実行時間の短縮や、偽陽性・偽陰性の削減、信用できない（Flaky）テストの改善などが求められる。
テスト実行と再実行に時間がかかる現場
江村氏は「運用作業は多くの工数を必要とし、それが続くとテスト自動化自体が嫌になってしまうこともあるかと思います。そこで、これらの運用課題とその解決策を紹介します」と話し、テスト自動化における運用の課題を解決した3つの事例を紹介した。
最初の事例は「テスト実行と再実行に時間がかかる現場」。顧客へのヒアリングで、「最近、テスト実行に時間がかかることがある」との声があった。具体的にどのような状況で時間がかかるのかを尋ねたところ、「テストが途中で失敗すると、非常に多くの時間を費やしてしまう」とのことだった。
調査したところ、以下の問題が明らかになった。テストケースには、機能1：ユーザー作成、機能2：商品検索、機能3：お気に入り登録、機能4：商品購入という4種の機能テストが含まれており、これらがまとまったテストケースとして自動化スクリプトに組み込まれていた。しかし、開発中のプロジェクトで、機能3のお気に入り登録の部分に不具合が発生し、何度もテストが失敗するという状況が生じていた。
このプロセスを時系列で見ると、1回目のテストでは、機能1・2は成功したものの機能3で失敗した。エンジニアが修正を試み、2回目のテストを実行したが、また失敗。これを繰り返し、4回目のテストでようやくすべてのテストが成功した。
時間がかかる原因は、1つのテストケースに複数のテスト目的が含まれていたことにある。また、成功したテストが何度も繰り返し実行されていたことも時間のロスを招いていた。さらに、特定の機能だけをテストする「サブセットテスト」が実行できない状況にあり、機能4については最後のテストでしか実行されていなかった。
これらの問題の解決策として、1つのテストケースには最低限のテスト目的だけを設定すること、各テストケースが他のテストケースに依存せず、単独で実行できるようにすることを提案した。テストケースを機能ごとに4分割し、順番に実行するようにした。そうすると、機能1・2が成功し、機能3が失敗、機能4が成功となった場合、機能3だけを改修・再テストすれば良いため、全体の実行ボリュームが少なくなる。
江村氏は「ただし、機能3がバスしたあとも、フルリグレッション（すべてのテストを最初からやり通す）を行うことをお勧めします。この事例のまとめとしては、テストケースを小さくし、テストが失敗した場合の運用を考慮することが重要であることが言えます。ただし、テストケースを小さくしすぎると、テストケースの数が膨大になり、管理が難しくなるというデメリットもあるため、バランスを考慮する必要があります」と加えた。
2か月かかったテストスクリプトを実行したら修正が大量発生！
続いての事例は、「スクリプトの修正が大量に発生する現場」。顧客へのヒアリングでは「テストスクリプトが完成して実行したら、XPathの修正が大量に発生した」との声があった。大規模なUI改修のプロジェクトかどうか尋ねると「いいえ、2か月かけてスクリプトを作成し、実行したらこのような状況になった」との回答だった。詳しく調査したところ、すべての画面のテスト自動化プロジェクトを3か月かけて進めており。スクリプトが完成し、リグレッションテストとして開発プロセスに組み込んだところ、大量の修正が必要になったという。
江村氏は、この問題の原因は2つあり、1つは、プロダクトの仕様変更に追随できていなかったことだと指摘した。この自動化プロジェクトは2〜3か月かけてA・B・Cという機能のテストコードを書き、4か月目にリグレッションテストを実行した。しかし、その間に開発プロジェクトが並行して進み、機能AとBに改修が入っていたにもかかわらず、自動化プロジェクト側はその変更に気づかなかった。その結果、Cは偶然問題がなかったものの、AとBについては動作しなかった。
もう1つの原因は、テスト自動化を常に動かしていなかったため、小さな変更に気づけなかったことだ。開発側で進められたリファクタリングやUIの変更がテストに反映されないままとなっていたのだ。
解決策として、テスト自動化を定期的に実行することを提案した。スクリプトが完成したら、すぐに定期実行に組み込むというプロセスが望ましい。そのためにテスト自動化のスクリプト作成環境と、テスト実行環境を分離し、常にテストを動かせる環境を整えたい。江村氏は「テスト自動化を常に動かせる環境を整え、スクリプトが完成したらすぐに定期実行に移行することが重要です」と述べた。
「デザインが変わっただけ」でもスクリプトの修正が大変
3つ目の事例は「テスト実行が遅く、仕様変更時の修正が大変な現場」。顧客へのヒアリングにて「最近テスト実行に時間がかかって困っている」との声があがった。テストケースのステップ数が多いのか尋ねたら「画面数は数個で、UIが少し変更された程度だが、スクリプトの修正が非常に大変」とのことだった。大幅な機能変更の有無を問うと「デザインやメッセージが変わっただけ」との回答を得た。
詳細を調べたところ、テスト対象は問合せフォームで、文字列を入力し送信するページだった。テストスクリプトではデザインの検証に加え、フォームへの入力値やメッセージのチェックを行っていた。デフォルト値のチェックや、入力必須のアラートが出るかのバリデーションも行い、最後にテキスト入力をするなど、多岐にわたる検証を行っていた。
テストの実行が遅くなり、仕様変更時の修正が多くなる原因として考えられるのは、テキストの正確性などを確認するステップが多すぎることだ。また、UI検証が多いため、デザインやメッセージが少し変わるだけでも大きな影響が出てしまう。さらに、テスト自動化の目的や基準が明確でないことも原因の一つと考えられる。
解決策として、テスト自動化の目的と基準を見直すことを提案した。テスト自動化は何を目的として行うのか、その点から再検討することが重要だ。手動テストをそのまま自動化した場合、広範なテストが可能であるが、その分細かなチェックが増え、実行時間も長くなる。一方で、リグレッションテストに重点を置く場合、テキストやデザインの不具合を見逃す可能性はあるものの、機能に特化したテストを行うことで非常に効率的なテストが可能となる。テスト自動化の目的次第で、運用コストなどを加味したテスト基準を定めたい。
江村氏は最後に「テスト自動化は、構築よりも運用フェーズでいろいろな課題が出てきます。それ（課題をそのままにした状態）に慣れるのではなく、課題を認識し改善していくことが、テスト自動化を長く運用しつづける続けるコツです」とコメントした。
テスト自動化はツールに任せ、運用の課題改善に注力しよう
本セッションを振り返ってみると、テストの自動化が本当に効力を発揮するには、自動化そのものより運用フェーズが重要であることがよくわかる。特に、最近では各種ツールも出そろっており、中には非エンジニアでも扱えるものも多い。自動化はツールに任せ、エンジニアは運用フェーズの改善に注力するのも良いだろう
例えば冒頭で紹介された「T-DASH」では、インストールすればすぐ使えて、非エンジニアでも簡単にWebアプリケーションの動作確認・検証ができる。チュートリアルページも充実しているので自走も期待できる。そのほかにセミナーなども毎月開催されており、公式HPに集約されている。
気になった読者は、覗いてみてはいかがだろうか。
