皆さんはこれまでにテスト自動化に挑戦したことがありますか？ソースコードの静的解析・コードレベルの単体テスト・結合テスト・E2Eテストなど様々な種類を含めると、「全くやったことがない」という方はむしろ少数派ではないかと思います。しかしUI操作を含むE2Eテストが対象でなおかつ「テスト自動化がうまくいった経験はありますか？」という問いに対しては「はい」と答える方はぐっと減ってしまうのではないでしょうか。私たちはこれまで多くのお客様のご相談を受けてきましたが、多くの方はE2Eテストの自動化に挑戦はしたものの作成・維持のコストが高過ぎて諦めたという経験をお持ちでした。

では、E2Eテストの自動化がそれほど高コストになってしまうのは何故なのでしょうか。最大の要因の一つは、せっかく作成したテストが様々な理由で壊れてしまうからです。画面のデザインや文言の変更、テストデータの差分、OSのバージョンアップなど、多種多様な理由でこれまで成功していたテストが通らなくなります。中でも、デザイン・文言変更によるテストの失敗は活発に開発されているアプリケーション・サービスであればあるほど頻発し、テストエンジニアの心を折る要因の一つとなります。変更があるからこそテストが必要なのに変更のせいでテストが失敗してしまうというのは、テスト自動化のつらいポイントです。

MagicPodの「自動修復」機能は、そんなつらさを解消してくれます。アプリケーションのデザインが変更されて既存のテストケースでは操作したい要素が見つからなくなったとき、MagicPodは変更後のデザイン上で対応する要素を自動的に見つけ、テストを続行します。テストが終了すると、MagicPodが要素の変更を提案してくるのでそれを承認もしくは却下します。すると、特に他のメンテナンス作業をしなくてもテストケースが最新のデザインに対応した状態になります。

では具体例を見てみましょう。テスト対象のモバイルアプリにはシンプルなユーザ登録画面があり、その画面を使ったユーザ登録から始まるテストケースが既に複数存在してうまく動いているとします。

しかし、ある日ボタンの文言が「Register」から「Register me」に変わったせいで、動いていたテストが失敗し始めます。

自動修復機能がない場合、再びテストを成功させるための手順は以下のようになります。

1. テストが失敗した理由を調査
2. 「Register」ではなく「Register me」という文言を使ってボタンを探すよう、テストケースを修正
3. テストケースを最初から再実行

一方、自動修復機能がある場合の手順は次のようになります。

1. 自動修復の結果を確認
2. 結果を承認

自動修復結果のダイアログには要素がどのように変更されるかという詳細な情報が含まれているため、承認すべきかどうかの判断を簡単に行えます。

この機能のメリットは大きく二点あります。一つは修復後もテストが続行されるという点です。つまり承認した後にテストを再実行する必要がないため、特に修復された箇所以降も多くのステップが続く場合には実行時間の節約になります。また、もし後続のステップに問題が潜んでいた場合にも、自動修復なしの場合に比べて早期に問題を発見できます。もう一つは、同じ要素を使う全てのテストケースに修復結果が適用されるという点です。例えば同じ登録ボタンを10個のテストケースで使っていた場合、一つの修復結果を承認するだけで全てのテストケースが成功となります。こちらもメンテナンスの時間短縮に繋がりますし、テストケース間の一貫性を保つこともできます。

自動修復は、もはや自動テストのメンテナンスに不可欠な機能と言えるのではないでしょうか。ぜひMagicPodをお試しいただき、その威力を感じていただきたいと思います。