この記事はベリサーブ Advent Calendar 2021のカレンダー | Advent Calendar 2021 - Qiitaの16日目です。
ベリサーブではGIHOZ（ギホーズ）というテスト技法クラウドツールを開発・運用しています。GIHOZの開発ではAutifyを活用してE2Eテストの自動化をしています。この記事ではGIHOZ開発チームがAutifyをどう活用しているかについて解説します。
はじめに
GIHOZでは、開発の初期段階からE2Eテストの自動化に取り組んでおり、当初はCodeceptJSを使ってコードを書いていました。ある程度シナリオを作成してテスト実行もできてはいたのですが、GIHOZの製品コードの追加・修正の影響ですぐ壊れる、実行結果が不安定なことが多い、実行環境の用意が手間といった課題がありました。「メンテナンスがしんどい・・・」「E2Eテストの実行がめんどい・・・」という状況が続いており、Autifyの導入を決めました。
AutifyでE2Eテストを実行するには、テストシナリオを作成して、テストプランを作成して、テストプランにテストシナリオを紐づけて、テスト実行して結果を確認する、という流れになります。以下ではこの流れに沿って、GIHOZ開発チームでAutifyをどう使っているかを書いていきます。
テストシナリオの作成
シナリオは2021年12月時点では20個程度あります。今後もGIHOZの機能拡張に従って増えていくと思います。
Autifyを使っている人にしか参考にならないかもしれませんが、シナリオのステップ数は、一番長いものは97ステップ、短いものは5ステップでした。5ステップのものはログインしてログアウトするだけの単純なシナリオです。
97ステップのものは、ペアワイズテストの画面に対するシナリオです。テスト対象の画面に入力する部分や設定する部分が多いので、シナリオが長めになっています。
ステップ数ごとに、何件シナリオがあるか集計してみました。GIHOZのE2Eテストは20~29ステップを中心に分布していました。他のプロジェクトではどんな感じなのか気になるところです。「スモールチームにおけるAutifyを用いた効率的なE2Eテストの自動化」という記事ではステップ数を少なくしていたらシナリオが増えすぎて辛かった、といった記載がありました。この辺りは確かに悩ましいところだなと思います。
シナリオをどういった単位で分けているかについては、明確な基準は定めていませんが、大まかにはユーザがひとまとまりで使う機能の単位でシナリオを分けて作っています。例えば、リポジトリの作成、リポジトリへのメンバーの招待、プロフィールの編集、パスワードのリセットといった単位です。
GIHOZはさまざまなテスト技法のUIを備えており、各テスト技法のUIのE2Eテストはおおよそ1技法が1シナリオという形になっています。さまざまな編集操作があるため、テスト技法のUIのシナリオはステップ数が多くなりがちです。分割したほうが良い部分もあるかもしれませんが、現状は、おおよそ1技法1シナリオのままでやっています。唯一シナリオを分割しているのは、ペアワイズテストのUIに対するテストです。ペアワイズテストのUIではオプション設定など色々な設定ができるようになっており、全部の設定をいじるようなシナリオを作るとステップが長くなりすぎるため複数に分けています。
GIHOZのペアワイズテストのUIは以下のようになっています。制約やオプションなど、入力できる部分が多いです。
一部のテストシナリオでは、Autifyの「データ機能」を使ってデータ駆動テストを実施しています。例えば、GIHOZのプロフィール編集画面をテストする際に、色々な入力値の組み合わせパターンでテストする、などです。このときに使うデータを作るために、GIHOZも活用しています。以下はGIHOZのペアワイズテストで入力値の組み合わせを生成した例です。ペアワイズテストを使うと、すべての組み合わせパターンを網羅するのではなく、2パラメータ間の値の組み合わせパターンを網羅するように組み合わせを生成してくれるため、一定の網羅性は保ちつつ組み合わせの件数をかなり絞り込むことができます。ペアワイズテストの詳細についてはこちらの記事に解説があります。
生成結果のCSVファイルをGIHOZからダウンロードして、Autifyのシナリオ編集画面の「データ」タブからアップロードしておけば、Autifyがテスト実行する際にデータの行数分だけ自動でテストを繰り返してくれます。
テストプランの作成
主に使っているテストプランは以下の画像に示した7件です。GIHOZは開発用環境（チーム内ではステージング・ゼロと呼称）、ステージング環境、本番環境の3つの環境を用意しており、それぞれに対してテスト実行できるようにテストプランを分けています。
「E2Eテストの受け入れ確認用xxx」というテストプランは、新規作成や修正したシナリオがきちんと各環境でPassするかの確認に使っています。テストプランにはシナリオを複数紐づけられるのですが、「E2Eテストの受け入れ確認用xxx」のテストプランを実行する際は、動作確認したいシナリオだけ紐づけてから実行するようにしています。
「xxx環境E2Eテスト」というテストプランには既存のシナリオをほぼ全部紐づけており、開発中やリリース時にこのテストプランを実行して、すべてPassするか（リグレッションバグがないか）を確認しています。
具体的には以下の流れでE2Eテストと手動のテストを実施してしています。今回はE2Eテストの話題なので詳細は省きますが、このほかにユニットテスト・コンポーネントテストも、テストコードを書いて実行しています。
- 新規機能の追加や修正を行ったコードを開発用環境に反映
- 「stg0環境E2Eテスト」を実行＆手動で新規機能や修正部分や影響範囲のテストを実施
- 問題あれば修正して1, 2を繰り返す
- 問題なくなったら、ステージング環境に最新のコードを反映
- 「stg環境E2Eテスト」を実行＆手動で新規機能や修正部分や影響範囲のテストを実施（手動のテストは2よりは軽めにしています）
- 問題なければ、本番環境に最新のコードを反映
- 「本番環境E2Eテスト」を実行して、本番環境が問題ないか確認＆新規機能や修正部分は軽く手動でも確認
「本番環境が動いているか毎日確認するテスト」というテストプランは、毎朝決まった時間に実行されるように設定しており、単純なログイン・ログアウトの操作のシナリオのみ実行しています。1日1回の稼働監視的な使い方で、念のため実行している形です。あまり意味はないかもしれませんが、毎朝SlackにPassの通知が送られてくるのを見ると若干の心の安寧を得られます。
実行結果の確認
実行結果はSlackに専用のチャンネルを作って、そこに通知するようにしています。開発メンバーのコミュニケーションにSlackを使っているので、Slackに通知できるのは助かります。
Slack通知は、ワークスペース設定のページから設定できます。チャンネル名の最後が「ちゃん」なのは、そのほうがかわいい、と開発チームの誰かが言ったからだとかなんとか・・。
実行結果はSlackに以下の画像のように通知されます。もちろん全部Passになると嬉しいのですが、Failがあってもすぐ分かるのが良いですね。
自動化できていない部分
現状E2Eテストの自動化ができていない主な部分は、Canvasと右クリックの操作です。GIHOZでCanvasを使っているのは、状態遷移図を作成するUIとクラシフィケーションツリーを作成するUIの部分です。右クリックの操作は、各テスト技法の画面で実施できるものです。
Autifyのヘルプセンターを見ると、2021年12月時点では「Canvas内の操作や検証」「右クリック」ともに対応方針は未定になっていました。いずれ対応されると嬉しいなと思います。
GIHOZの状態遷移図を作成するUIは以下です。Canvasになっています。
GIHOZのクラシフィケーションツリーを作成するUIは以下です。こちらもグレー背景の部分がCanvasになっています。
おわりに
この記事では、GIHOZ開発チームでのAutifyの活用方法について書きました。
Autifyは、AIが自動でテストシナリオをメンテナンスしてくれたり、実行環境はAutifyにお任せなので我々は実行環境のメンテナンスを意識しなくて良かったり、テスト実行はボタンを押すだけで手軽なのもあり、Autifyの導入以前に陥っていた「メンテナンスがしんどい・・・」「E2Eテストの実行がめんどい・・・」という状況から脱出することができました。ありがとうAutify！
価値ある製品をより早くユーザの皆さまにお届けするため、GIHOZ開発チームは今後もAutifyを活用してE2Eテストを効率的に自動化していきたいと思います。
最後に宣伝ですが、GIHOZには公式ブログがあります。GIHOZのアップデート情報のほか、テスト技法の使い方についての解説記事もありますので、テスト設計やテスト技法の使い方でお悩みの方はぜひご覧ください！