チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

E2EテストツールAutifyを使うまでの話

こんにちは!
本格的に家の在宅勤務環境を揃え始めたQAチームのリーダーをしている生井(id:riririusei99)です。
今回はE2Eテストツール「Autify」を使用することになったので、これまでの話をブログに書こうって回です。

Autifyとは

「AIの力で品質保証の課題を解決し、素早い開発サイクルを実現する」最近話題になっているツールです。

autify.com

従来のE2Eテストと課題感

TeamSpiritのE2EテストはJavaで書かれたSeleniumを使ったテストを行っているのですが、E2Eテストを定期実行するためには様々な領域での作業が必要でした。

  • 実行するテストのテスト設計
  • テストコードのコーディング
  • 定期実行するためのサーバ作成・管理
  • クロスブラウザテスト用のサービス連携 or 各種ドライバーの管理
  • 落ちたケースのレポート確認・メンテナンス

などなど、テストを実施するためには幅広い知識が必要なため、どうしても属人化しがちな領域になっていました。
なのでチームのメンバーが自動テストを使えるような、E2Eテストを用意する必要がありました。

技術検証(2019年12月くらい)

と言うわけでフロントエンドエンジニアでも書けるようにとJavascriptのE2Eフレームワークを中心に技術調査を行いました。(自分もJavascriptでテスト書いた経験もあるし)
検証したツールは以下です。

  • TestCafe
  • WebDriverIO
  • Cypress.io
  • Autify

また、この時はこんな観点で検証しています。

  • インストール: 導入・インストールが容易か
  • エラー調査: エラー調査が容易か
  • クロスブラウザ: クロスブラウザテストのしやすさ
  • 拡張性: 機能拡張ができる・しやすさ
  • テストの書きやすさ: テストの実装が容易か
  • VisualforcePageへの自動テスト: Salesforce上のアプリケーションに対して実行できるか

そして自分たちのプロダクト開発に合致するか独断と偏見で色付けをしてみました。

観点 TestCafe WebDriverIO Cypress.io Autify
☆インストール
エラー調査
クロスブラウザ ×
拡張性
☆書きやすさ
☆Visualforcepage
への実行
× ×

特に☆をつけたところについて重視しました。

改めて思ったのですが、Salesforce上のアプリに対してE2Eテストを実行することが結構大変。
この辺は、また別の記事のボリュームになりそうなので別の機会にします。

今回はAutifyが全体的に自分たちのニーズに合致してそう。と言うことでトライアルを申し込みました。

トライアル期間(2020年1月~4月)

流石に全てのスクラムチームに導入…と言うわけではなく、まずは自分の所属しているチームにトライアル用のケース作成とチームメンバーにAutifyのハンズオンに参加してもらいました。
トライアル期間でハンズオンや実際に触ってみていくつかの気付きがあったのでシェアします。

習得が容易

トライアルを受けて感じたことは、メンバーの役割や言語に限らず全てのメンバーが習得できると感じた点です。
当初の技術検証ではJavascriptで書こうとしていたのでフロントエンドのメンバーと協力していたのですが、これならフロントエンドに限らず、バックエンド、QAもテストが作成できそうです。なんなら、プロダクトマネージャの人に直感的に作成してもらうことも可能だと感じました。
一方で、Autifyは習得を容易にした分、独自の使用性になっていますので習得したスキルは他のフレームワークには持ち運びできない部分があります。
既にSeleniumや他のフレームワークを習得しているエンジニアが多く所属している場合や、サーバの管理の部分に課題がない場合とかは何を大切にするか検討が必要だと思いました。

実行環境のメンテが不要

クロスブラウザのテストを実施しようとした時、TeamSpiritの場合はBrowserStackを使った自動テストを実行していたのですがここでも課題がありました。 Salesforceの組織(東京リージョン)⇄ BrowserStack(欧州)の通信が発生するため、テストを実行する際に時間が掛かっていました。
ここの問題については自動テストの中でクロスブラウザテストのケースを分けて精査し、テストケースを減らすように工夫するなど、どちらかと言うと消極的な対応を取っていました。

この問題にテストの実行環境を改善するには正直、自分としては悩ましい領域です。テスト以外のこういった課題を解決するには手が足りません。
先日、参加したイベントの中で聞いた情報によるとAutifyの実行環境の改善により、この部分についても将来改善もされそうなので、インフラを肩代わりしてくれることについては非常に助かりそうです。

jawsdays2020.jaws-ug.jp

サポートあり

これは個人的には非常に嬉しいです。これまで落ちたケースについては一人で調べてなんとか解決する…みたいなケースが多かったのですが、Autifyでのサポートが受けられます。
もちろん、プロダクトの製品自体に起因する問題だとサポートしづらいのは承知してますが…リカバリーする時に心強い味方がいることの安心感は大きいと思います。(あくまで個人の経験ですが)

総括すると

個人的には、「テストのコーディング」「サーバの管理」「落ちたケースのサポート」みたいなところをシンプルにできるのは非常に良いなと思いました。 チームのフロントエンド・バックエンド・QAに限らず自動テストが作れるので、当初の課題感になっている属人性の解消には役立ちそうな印象を受けました。 これだけシンプルに作れるなら、立ち上げや新しい自動テストを作るQAにとっては、心強い見方になりそうと言う印象です。

f:id:riririusei99:20200416225208p:plain
自動テストの役割をシンプルに

終わりに・これからの話

TeamSpiritにおけるAutifyの自動テストの役割は自動テストの全て担当してもらう!!…みたいなことではなく。
UIのテストの特に重要な回帰テストの部分や、よく変更がかかる部分のテストを担当してもらったりするような使い方にするのが良さそうです。
機能拡張も順次行われるようなので、今後のアップデートにも期待していますし、TeamSpiritでも積極的に活用していきたいと思います。

と言うところで今回の記事は以上となります。