AIの真実とどうやってE2EテストにAIを適用させるか? #STAREAST で一番面白かったセッションメモ

STAREASTで一番面白かったセッションは「The Truth about AI and How it Applies to End to End Testing」でした。発表者はテスティングプラットフォームを提供する老舗TestimのCEOです。この発表を聞くと、テスト自動化というものが現段階でどういう位置にいるのかがよくわかります。

The Truth about AI and How it Applies to End to End Testing

まずはどこでどんなテストをするかをまとめた図。これすごくわかりやすいですね。E2EテストもSmokeレベルと前流しと分けている点が実用的で素晴らしい。

AIについてはそのまえのキーノートでも語られていましたが、テストにおける成熟度はこの図が一番わかりやすいです。

期待するのは自律的に自動でテストする仕組み(Level 3)ですが、それはあと数年はかかる見込み(test.aiとかね)。現状はLevel 2が徐々に実装されてきて、メンテナンスコストが劇的に下がってきている段階でしょうか。乞うご期待。

テスト自動化におけるAIはUI部分と妥当性部分に分けて考えてみます。UIの正確性(画面崩れなど)はApplitoolsのようなVisualValidationが花を咲かせてきました。テストの自動実行や再利用性はもう当たり前レベル。テストの自動修復も多少なりすすんでいます。

デモはTesimをつかった要素検出について解説。さすが老舗。機能がリッチです。画面右側には要素の候補が一覧で並んでおり(LOCATORS)、「Target Element 74%」のように正確性?らしき数値もでています。

この辺の考え方はAutifyのブログ「なぜE2Eテストでidを使うべきではないのか」がとてもわかりやすいですが、id, class, text, tag name, link, css selector, xpathによる要素特定は問題を抱えています。

  • ID
    • Random ids
    • コードが変わる。ふるまい(testing is mostly AOP)
    • iframes: ただしいContextを見つけるのが難しい
    • IDの重複。最初の要素がだいたい返ってくる
    • Two bodies
  • class
    • non unique
  • Other
    • too fragile

重要な点は以下です。

  • 一意は難しい
  • アプリが変化したときに、最適な要素を手に入れるためもっとダイナミックなアプローチが必要

AIによる妥当性チェックはどうでしょう。自動で値のValidationは比較的簡単にできそうですが、VisualValidationはPixelレベルのチェックだと不安定になりがちです。

重要な点は上記。本番テストへ進んでいく必要があります。

  • AIはテストを安定化してくれる
  • 妥当性チェックも助けてくれる
  • 本番ユーザのようなテストも作ってくれるだろう
  • 本番でE2Eを実行することによって致命的な問題を見つけてくれる

リスクマネジメントについてはカバレッジやテストの実行結果などから数値化が簡単にできるようになってきました。昔からあるコードカバレッジのように、E2Eのカバレッジも定義できます。

最近僕はテスト自動化エンジニアになりつつあるのですが、要素が表示されているか問題はテストを不安定にします。

ReactやVueのようなフロントエンドの登場で、素敵なアプリが簡単に作られるようになりましたが、一方でそれらが管理する状態をテストするのは難しくなっています。

簡単に作れる VS 複雑でテストしにくい問題です。

しかし、AIによってこのストレスも軽減されていくでしょう。自動で要素の登場を待ったり、Waitを追加したりしなかったり。人間のように「よしなに」待つようになっていくはずです。