Autify を導入したらなかなか良かった話 - スタディサプリ Product Team Blog

スタディサプリのコーチングサービス (合格特訓コース、個別指導コース) 開発チームで Engineering Manager をしている @pankona です。最近弊チームで取り入れている Autify の良さについて紹介します。

TL;DR

弊チームでは最近 E2E テストとして Autify を便利に活用しています。
Autify の便利ポイントは以下。
- E2E テスト構築が容易。非エンジニアでもある程度すぐに作れるようになる。細かいところは JavaScript や CSS セレクタを用いてエンジニアが補うこともできる。
- 多少 UI の見た目が変わってもテストが壊れにくい。UI の見た目が変わったことは検知することができ、問題ないと人間が判定することでテストが修復される。
- チャットで質問を出すと結構すぐに返事がきて嬉しい。感謝。

Autify について

Autify ランディングページ

E2E テストの作成を支援するためのクラウドサービスです。ブラウザ上で行った操作を記録しておき、あとから再生して同じように動作するか検証することができます。

導入の背景

私の所属しているチームは 2021 年 7 月にいくらかメンバーの減少があり、ウェブ開発者は私とメンバーもうひとりという 2 名体制になる時期がありました。そのため、日常的に行う保守や運用にかける工数を少しでも減らしたいという事情がありました。

効率化できそうな運用のひとつとして、リリース前に行っていた手動のテストがありました。弊チームでは毎週一回以上はリリース作業を行っていますが、当時のリリース前のテストは手作業でした。テスト項目に従って人間がポチポチブラウザを操作してテストをするというものです。これには一回あたり最低 10~20 分程度を要していました。週に一回ならそこまででもないかもしれないですが、場合によっては一日に 2 度 3 度とリリースを行うケースもあり、何度も同じテストを繰り返すのは時間の消費もさることながら、それなりに億劫なことでもありました。

そのような事情がありましたので、リリース前のテストを自動化できれば工数削減、ついでに心理的にも良い効果があるだろうという狙いがありました。

導入～運用に至るまで

@testtatto さんに Autify を試すことを持ちかけてもらったのがきっかけでした。さっそく試してみたところ、テスト構築に数時間費やしただけで初見でもそこそこ動くところまで作ることができたようでした。あまり迷うことなく直感的に操作ができる UI が提供されているということだと思いますが、なかなかよい体験でした。

ただ、この時点ではまだテストは不安定で、アサーションもややヌルい状態でした。より安定したテストを目指し、ひとまず毎日定時に流すようにして結果を Slack に通知するようにしました。失敗したら原因を確認してちょっとずつ直すという営みを繰り返し、安定性の改善とアサーションの強化を続けていきました。

2 週間経過したあたりでテストが安定してきたという感触が得られたので、実際にリリース前テストとして実行するよう、運用に組み込んでみました。

Autify で何を検証しているか

2021 年 11 月現在、以下の目的で Autify による E2E テストを実行しています。

本番へのリリース前テスト

本番環境にリリースする直前のフェーズ (リリース環境と呼んでいる) にて、Autify を実行しています。生徒とコーチがチャットを行う機能や、勉強スケジュール配信機能、生徒から提出されたテストを採点する機能など、コーチングサービスの主要機能を中心に検証しています。

pull request 毎に生成される環境に対して

pull request 毎に生成される環境に対して、必要に応じて Autify による検証をしています。必ず実施するわけではなく、pull request の変更が、主要な機能に影響を及ぼすことが懸念される場合などに任意で実行しています。 (CI に組み込むことができれば一番よさそうですが、2021 年 11 月現在ではそこまで至っていません)

Autify を導入して幸せな点

E2E テストを高速に作ることができる (体感)

高速にテストを作る、あるいは追加、編集できるという所感です。テスト作成の概ねは GUI の操作で完結するため、Cypress や Selenium を書くよりもお手軽という印象です。非エンジニアでもそれなりにテストを作ることができるということであり、仕様に詳しいがコードは書けない、という方にテスト作りをある程度お願いできるというのは便利なところです。

とはいえ GUI でのテスト構築だけでは細かい制御が難しい場合もあります。そういうときはエンジニアが JavaScript や CSS セレクタを用いて細かく制御して補うこともできます。

テスト工数の削減とリリース頻度の向上

弊チームの場合では、人間が 10~20 分以上かけて行っていたテストが Autify で実行すると 1~2 分で完了する程度には高速化されました。当チーム比ですが、10~20 倍くらいは時短になっていそうです。

10 個ほどのテストシナリオも並列実行されるので素早く終わる

テストがハンズフリーで高速に済むようになると、工数削減に加えてリリースが気軽なものに感じられるという副次的な効果もありそうです。

以前は「じゃあリリース作業しますか、どっこいしょ、リリースに入れ忘れているものないかー」という感じだったのが、いまでは「とりあえず Autify 流して大丈夫ならリリースしといてね、あとで追加で出したいものがあれば何度でもリリースすればいいさ」というような雰囲気になってきており (体感)、リリースが気軽になったのは良いことだなと感じています。

そこそこ壊れにくい

UI の見た目が多少変わってもただちにテスト失敗にならず、いったん「レビュー待ち」のような状態になります。人間が確認して OK とすると、今後は現在の状態が正として扱われるようになるようです。便利です。

ちょっと見た目が変わっても、人間がレビューして OK なら今後もそれを正しいとする機能 (修復する) がある

(我々にとって) これが Autify で出来るともっと幸せな点

(以下はいずれも 2021 年 11 月現在の状況です。今後 Autify の機能拡張によって解決される可能性があります)

テストのターゲットとなる URL の部分的な置き換え

昨今では pull request 毎に検証環境が作成される例を多く見かけるようになりました (私が知っている範囲でも Firebase Hosting、Netlify などが該当します) 。弊社の開発環境においても、リリース前の検証環境や pull request 毎に検証環境が生成され、それぞれ固有の URL をもっています。

(例)

リリース前の検証環境: https://learn-release.example.com
pull request 毎に生成される環境: https://learn-pr-12345.example.com (12345 には pull request の番号が入る)

現時点では Autify のクラウドサービス上から手動でテスト実行する運用を行っていますが、将来的には Autify による E2E 自動テストを CI パイプライン (ここでは pull request 作成や topic branch への push に伴って自動的に実行されるテストのことを指してています) に組み込み、デプロイされた環境に対して自動実行されるようにしたいと考えています。Autify を CI パイプラインに組み込もうと思った場合、テストのターゲットとなる URL を都度変更できるような機能があると便利そうですが、現在はそういった機能は提供されていないと思われます (要望は出してみました) 。

実行順序の制御

Autify では複数のテストシナリオを「テストプラン」として束ねておけるのですが、テストプランは「全部並列に実行する」か「全部シーケンシャルに実行する」かのどちらかしか選択することができません。 A のテストが成功したら B のテストを実行する、のように実行順序 (依存関係) を制御できると一個一個のテストシナリオを小さく保つことができるのですが、現状は「A やって B やる」までをひとつのテストシナリオにする必要があり、ひとつひとつのテストがやや大きくなってしまう傾向があるように感じています。もう少し細かく実行順序を制御できるようになると嬉しいような気がしています (要望は出してみました) 。