スポンサーリンク

E2Eテスト自動化についてお客さまからよく聞かれる質問とその回答例

Photo by Eric Krull on Unsplash

最近、テスト自動化の導入や推進のご相談をいただくことが多くなり、Autifyやmablを使ってもらったり、安定した運用になるまでの戦略を立てたりしています。そんななかで、みなさん共通して質問されることがあるようなので、それをまとめて回答してみました。

スポンサーリンク

はじめに

ここでは、前提として、mablやAutifyが得意な「WebアプリのE2Eテスト」をベースに書いています。mablやAutifyについては「E2E自動化サービス」と呼ぶことにします。また、調査内容等は当時の情報に基づくものなのでご注意ください。

Q. 使っていて一番良いと感じるE2E自動化サービスの機能は何ですか?

個人的には、運用コストに響いてくる機能性と操作性が重要なのですが、機能面で言うなら自動修復機能(オートヒーリング)が重要だと感じています。

たとえば、ID、ClassNameやXpath指定での要素特定はSeleniumIDEやWebDriverなどを中心にこれまでいくらでも手段はありました。

しかし、E2E自動化サービスの特徴的な点として、画面変更に強くするためにサービス側で要素特定を工夫してくれている点があります。これはとても大きく、実際使ってみると、かなりのケースでこれが動作して安定化につながっているのがわかります。

その他に、サービスによってはクロスブラウザテストやメール受信もできますが、こういった機能はお客さまにとっては不必要な場合があるので、あればいいけど必須ではないと思っています。

Q. 自動修復機能(オートヒーリング)は適切に動いてくれますか?

成功率はわかりませんが、だいたいうまく動いているように見えています。もちろん、変更に耐えきれず失敗している部分もあります。今後この機能に開発投資されれば、より良くなっていくと思いますし、そう期待しています。

1点、自動回復させるためにはアプリ側の工夫も必要です。

参考: なぜE2Eテストでidを使うべきではないのか

よって、開発とテストをうまく組み合わせればよりよい自動修復効果が見込めます。

Q. E2E自動化サービスを使った結果、マニュアルテストはどのくらい減りますか?

テストにはいろんな種類のテストがあるので、ここでは4つのレベルにわけるとします。

  • 単体(UT: ENGが作るやつ)
  • 機能テスト(よくQAが手でやってるやつ)
  • リグレッションテスト(全体をざっくり見て回る壊れてないことテスト)
  • 本番テスト(リリース後に本番で動作確認するやつ)

単体レベルはmablやAutifyよりエンジニアがプログラムを書いたほうが効率がいいので、E2Eテストの対象からいつもはずしています。

機能テストもやればできますが、このレベルをいきなり自動化するかどうかは企業によってまちまちです。例えば楽天トラベルは、開発と同時に自動化しているようですが、

参考: 楽天トラベルの開発プロセスに関して

単純に開発者とテスト開発者の2倍のコストがかかるため、ここまでできるところは少ないのではないでしょうか。

そこでE2E自動化サービスが生きてくるのだと思います。

参考: mablはmablでmablをテストする 〜 QA自動化プラットフォームが実現するDevTestOps

リグレッションテストは、ほぼ完全に置き換わると思います。ただ、リグレッションテスト項目が多い場合は、それを自動化するか、一部するか、あるいは項目をリファクタリングするかの選択が必要です。マニュアルテストと自動テストは相反するメリットデメリットがあるので、単純にマニュアルテストを自動化するのは、経験上おすすめしません。

本番テストも置き換えられます。置き換えると言うより、リグレッションテストを活用できるという感じでしょうか。

最後に、機能テストに戻りますが、リグレッションテストや本番テストを安定運用できるならば、機能テストの自動化にチャレンジするのもいいと思います。たとえば、いきなり自動化が難しいなら、1回目は手動でやるけど、2回目からは自動テストを使う・・・というプロセスでもいいはずです。

Q. マニュアルテストからの移行は複雑ではなかったですか?

複雑ではありませんがベストプラクティス的なノウハウはすでにいろいろあります。

Q. E2E自動化サービスにその移行をサポートする機能はありますか?

移行のサポートについて、mablだとWebDriverで書かれたテストをマイグレーションしてくれる機能があります。SeleniumIDE形式にエクスポートもできます

ただ、マニュアルテストを自動化するのは経験上あまりうまくいかないアンチパターンに感じるので(自動化によってコスト削減もアンチパターンだと思う)、今あるテストを自動化に適した形に移行していくほうが成果は大きいと思います。

最近相談を受けるテスト自動化のお仕事は、こういった移行や自動化の立ち上がりの相談ばかりなので、運用が軌道にのるまでを目標に、上記のようなノウハウを活用して失敗しにくい形で進めるのがおすすめです。

Q. ウォーターフォール型開発でも利用可能ですか?

プロセスは関係ないと思います。実際に、WF的な開発でも2E自動化サービスを活用している現場があります。

ポイントは、WFなどのプロセスと言うより「さいごにまとめてテストする場合」だと、E2E自動化サービスなどの効果は低くなりがちな点です。

理由は簡単で、実行回数が少なくなるからです(最後に一挙にどーん)。せっかく自動化されているので繰り返し使うに越したことはありません。よって、頻繁なデプロイごとの実行や、ある程度のコミットごとの実行だと最大限にテストを活かせると思います。

E2E自動化サービスを使えば、テストを並列で高速に実行できます。これによって結果を早く受け取り、デグレやその他の問題にすぐ気がつけるようになるわけです。

プロセスと言うよりツールの使い方が大切です。

Q. E2E自動化サービスをパフォーマンス(性能)テストに利用していますか?

していません。ダッシュボード画面に表示されたり、通知が飛んだりするので、たまに確認しますがそこまで重要視していません。

機能的にはこの分野もカバーできると思いますが、大抵の開発現場ではSREなりがシステムを監視しているはずです。そこまでできない小さい組織や人手不足なら、E2E自動化サービスを使ってパフォーマンスをモニタリングするのも手でしょう。

ちなみに、教えてもらったのですが、監視ツールのDatadogもブラウザテストができます。ただ、監視ツールのサービスなのでE2Eテストではなく「User experience monitoring」と紹介されていますね。

参考: User experience monitoring with Datadog Browser Tests

得意なものを得意なサービスがポイントでしょうか。

Q. E2E自動化サービス以外にテストツールを併用しているか

使っていません。もしかしたらエンジニアがUTフレームワークを使っていたり、QAエンジニアが疎通確認でPostmanとかを使っているかもしれませんが、E2Eやリグレッションとして使うのは主にこういったサービスが多いです。

Q. Autifyやmabl・・・いったいどれがおすすめ?

自分の課題解決に見合った、気に入った道具を使えばいいと思います。

余談ですが、似たようなプロダクトを調べていたときに、Testimも調べたことがあります。

参考: Web向けテスト自動化サービス「Testim.io」を試してみた 

このCEOが先見性を持っており、カンファレンスの発表も面白いのでとても注目しています。たとえば、ThoughtWorksの最新技術の動向のページではE2EフレームワークCypressが定番になったようです。そして、Visual regression testing tools
が注目されてきています。

TestimのCEOはVisualTestingで有名なApplitoolsのR&Dも担当されているようです。今後、Testimと連携すれば、ロジックと見た目の両面で強いプロダクトになりそうですね。

タイトルとURLをコピーしました