「テスト自動化の習慣を最速で定着させるためには」と題しているこの連載ですが、今回で最終回となります。第1回ではテスト自動化を失敗させないための「毎日テストを回す」習慣を中心に、自動化を始める際のステップについてお伝えしました。そして第2回では運用可能な自動テストを作成するにあたって非常に重要な「独立性」の考え方と具体的な実装方法をご説明しました。
今回は、第2回の続きとして自動テストの作成・運用をより効率的に進めるための工夫をご紹介します。今度のキーワードは「共通化」です。日々コーディングをしている開発者の皆様にとっては重複する処理の共通化はごく当然のことですが、ノーコードツールを使ってテストを自動化するときにも同じ考え方が有効です。以下、共通化にまつわる3つの工夫をご説明します。前回まで同様、テストケースの具体例にはノーコードテストサービスのMagicPod(https://magicpod.com)を使用していますが、紹介している概念自体は特にサービス独自のものではありません。
◆連載｜テスト自動化の習慣を最速で定着させるためには 第1回：E2Eテストの自動化を最速で成功させる秘訣 第2回：毎日の自動テストを無理なく続けるためのキーワード 第3回：共通処理を活用してさらに効率的に自動化を進めよう
工夫1：データ駆動テスト
第1回でも触れましたが、自動テストを運用する際にむやみにテストケースを増やさないことは重要です。とはいえ、せっかく仕組みがあるのですから色々なパターンのテストを導入したいと思うのも自然なことですね。そこで、おすすめなのは少ないテストケースで大きなメリットを得られる「データ駆動テスト」の利用です。
データ駆動テストとは、テストの「手順」と「データ」を分離することで効率的にテストケースを実装する手法のことです。テストケースの中にはいくつかの変数を含めておき、その変数に入れる値（データ）を表のような形式で指定します。すると、指定したデータのパターンの数だけテストを繰り返し実行することができます。この方法を使えば、データ部分の定義を増やすだけで様々な条件のテストができますので手間のかかるテストケース部分の実装コストは非常に少なくて済みます。
データ駆動テストは非常にポピュラーな手法ですのでほとんどの自動テストツールに機能として組み込まれており、CSV等を使ってデータを定義できるようになっています。実際にMagicPodを使って試してみましょう。まず、テストケースの定義とデータの定義は以下のようになります。データは手入力もできますし、CSVファイルをアップロードすることもできます。
なお、今回のテストケースではテスト対象としてテスト自動化の学習用の練習サイトであるHOTEL PLANISPHEREを利用させていただきました。ログイン情報は、サイト上で公開されているものです。
実行した結果は、パターンごとに切り替えて確認することができます。
上では説明のためにほとんど意味のない「様々なユーザIDとパスワードでログインするだけ」というテストケースを示しましたが、実際には
- ユーザの権限によって表示されるメニューや可能な操作が変わることを確認するテスト
- ECサイトなどで、購入する商品ごとにパターンを用意して購入までの操作を確認するテスト
のような用途が多いかと思います。筆者のチームでは、MagicPodの利用プランに応じて表示が変わる部分のテストをデータ駆動テストで実装しています。
非常に便利でつい多用したくなるデータ駆動テストですが、注意すべき点もいくつかあります。
- 分岐を多用しすぎない
- データごとに結果が変わることをテストしたいわけですからテストケース側にはある程度の条件分岐が発生することも多いですが、あまりに分岐が多すぎるとテストケースが複雑になり、かえって何をしているのか分からなくなることもあります。結果が変わる部分についてもなるべくデータ側で表現できるように工夫し、どうしても分岐が多くなるようならテストケースを分割することも検討しましょう。（その際、次に説明する「処理の共通化」が有効になります）
- パターンを増やしすぎない
- 最初の説明とやや矛盾してしまいますが、データ駆動テストが便利なあまりになんでもかんでもE2Eテストのパターンを増やして対応しようとするのはあまり良くないパターンです。本当にシステム全体の疎通が必要なテストであれば良いのですが、可能であればE2Eテストは最低限にしてユニットテストやAPIテストで多くのパターンを網羅した方が実行時間を短くできます。
工夫2：処理の共通化
うまくはまるケースがあれば非常に強力なデータ駆動テストですが、基本的に同じ操作の繰り返しにしか使えないので様々な機能のテストを行いたい場合にはもちろん使えません。次はもう少し汎用的な方法として、テストケースの全部ではなく一部の処理を共通化して部品のように使うことを考えてみます。
共通化される処理として代表的なのはやはりログインのように頻繁に使われる処理です。それ以外にも、テストの前処理として必要なデータ作成の処理などがあれば共通化しておくと便利です。処理を共通化しておくと、新しいテストケースを作るときに作っておいた部品を呼び出すだけで良いので当然ケース作成の工数が削減できます。それ以外にも、ユーザから見て分かりやすい単位にまとめることで処理の流れを明確にするというメリットもあります。実際に、前節で使ったホテルの予約サイトのテストを通じて共通化前後のテストケースを見てみましょう。
一通りの情報を入力して予約を行うテストケースを普通に作ると、以下のようになります。
ここではデモ用のサイトで最低限の情報しか入れていないので10ステップで済んでいますが、実際のサービスをテストする際にはもっと項目が多くなるはずです。クリックやテキスト入力といった細かい粒度のステップが並んでいると、パッと見て何をしているテストなのかが分かりにくくなりがちです。
この手順を「情報の入力」と「確認・確定」に分け、さらに予約処理全体も共通化したものが次の図です。いかがでしょうか。階層化されたものをすべて展開しているので、一見するとかえって難しく見えるかもしれません。
今度はいちばん下の階層を閉じてみました。すると、細かい処理は抽象化されてこのテストケースの概要が一目で分かるようになります。ここまで来れば、初見のメンバーがテストケースをメンテナンスすることになってもどの部分を編集すれば良いのかが分かりやすくなります。また、共通化されたステップには「宿泊数」「人数」といったパラメータが付いていることにも注目してください。このように処理の内容を変数化しておくことによって、同じ部品でも様々な値を入れて使い回すことができます。このあたりの考え方はデータ駆動テストに似ていますね。
工夫3：画面要素の共通化
最後は、もっと小さい単位で処理ではなく操作対象の画面要素（ボタン、テキストボックスなど）を共通化するという工夫です。自動テストで画面要素を操作するときは、ロケーターやセレクターと呼ばれる記述を使って対象の要素を指定します。Webアプリケーションの場合は、HTML要素のタグの名前・ID・文字列などがロケーターの構成要素になります。たとえば、「メニュー」という文字列を含むボタンであれば「//button[text()=’メニュー’]」のような表現で指定できます。ロケーターの記法は色々ありますが、この例の記法は「XPath」というものです。
ここで画面要素の共通化と言っているのは、こういった要素に名前を付けておいて要素とロケーターを紐づけておく考え方のことで、Object Mapなどと呼ばれることもあります。こうやって説明してしまうと「なんだ、そんなこと当たり前じゃないか」と思われるかもしれませんが、自動テストの実装方法によっては「ステップAとステップBでは同じメニューボタンを操作している」と認識されるとは限りません。「ステップAで//button[text()=’メニュー’]をクリックする」「ステップBで//button[text()=’メニュー’]をクリックする」と、全く別個に認識されている場合もあります。
こうなっていると、もし画面の構造が変わってメニューボタンのXPathが変わった場合、呼び出しているすべての箇所のXPathを変更しなければなりませんし、そもそも呼び出している場所をすべて探すだけでも大変な作業になります。「メニューボタン」という1つの要素として認識しておけば、メニューボタンに対応するXPathを変えるだけで済むので修正が圧倒的に楽になります。ちなみにMagicPodではテスト対象の画面全体を保存しておいて使い回すことができるので、ごく自然な形で画面要素の共通化を行えます。
共通化の本当のメリット
ここまで、「テストケース全体」「よく使う処理」「画面要素」という3つの粒度での共通化を紹介してきました。最初に「自動テストの作成・運用をより効率的に進めるための工夫」とお伝えしましたが、効率的に進めるというのはテストの作成スピードが速くなるというだけのことではありません。私たちは日々変化していくソフトウェアをテストしているので、変化に応じて素早くメンテナンスを行えることは作成スピード以上に重要です。様々なレベルで共通化を行うことによって必要な変更点を最小限に抑えることで、テストケースの可読性が上がり、エキスパートでなくても容易にメンテナンスを続けることができます。
おわりに
本連載では、テスト自動化に初めてチャレンジする方をメインの対象としてテスト自動化の進め方・効率的な実装・運用方法をお伝えしてきました。本来もっと短期間で終わらせるべきところ、筆者都合で非常に期間が長くなってしまったことをお詫びいたします。
ここでお伝えしてきたことは自動化をかじったことのある方にとっては当然と思われることばかりで、物足りないと感じられた方も多いかもしれません。自動テスト関連の技術は日々進化しています。筆者がE2Eテストの自動化を仕事として始めたのは10年ほど前ですが、その頃はSelenium 2 (WebDriver)が登場していよいよWebアプリケーションのE2EテストがOSSで手軽に実践できる！と盛り上がっている時代でした。その後モバイルアプリケーションの自動テストフレームワークも充実し、さらにAIを搭載した自動テストSaaSがいくつも出てきて自動化の敷居はどんどん下がってきました。
ただ、どんなツールやサービスを使っていても、コーディングをしてもノーコードでも、最初に理解しておくべき基本的なポイントや躓きやすい点はあまり変わっていません。筆者は以前にも初めて自動化に触れるお客様へレクチャーをする仕事に従事しており、最先端の技術を追いかけるよりも自動化の敷居を下げてたくさんの方に触れていただくことの方に喜びを感じています。本連載が皆様のテスト自動化のはじめの一歩に少しでもお役に立ちましたら幸いです。
連載一覧
第1回：E2Eテストの自動化を最速で成功させる秘訣
第2回：毎日の自動テストを無理なく続けるためのキーワード
第3回：共通処理を活用してさらに効率的に自動化を進めよう
