mablでのテスト自動化 ～実践編～

こんにちは、Eight事業部の金井です。社内の名刺を一括管理できるEightのサービス“企業向けプレミアム”で主にフロントエンドを担当しています。

今回は以前投稿されたEight Web E2Eテスト自動化に関する連載第2弾として「実践編」をお伝えしたいと思います。第1弾の記事では、mabl導入の経緯を説明していますのでぜひご覧ください。

buildersbox.corp-sansan.com

数字で見るEight E2Eテスト自動化

2020年5月から本格的に開始したmablを使ったEight Web E2Eテスト自動化ですが、定量的な成果としては記事執筆時点で以下のような結果となりました。エンジニア・QA担当者が協力してそれぞれ所属するチームの開発と並行して、E2Eテスト自動化作業を行なってきました。

項目	実績(2020年8月27日現在)
テスト自動化に関わった人数	エンジニア: 5名 QA担当者: 2名
作業期間	約3ヶ月間
E2Eテスト実装数	115
E2Eテスト実行回数	1,172/月

mablでのE2Eテストシナリオ管理

mablを使った具体的なE2Eテスト実装・運用を説明する前に、mablを理解する上での前提知識として基本的な4つのコンセプトについて解説します。

mabl4つのコンセプト

• Environment
• Test
• Trainer
• Plan

Environment

E2Eテストの実行環境です。一般的なものとしてdev・staging・productionが該当すると思います。Environmentを設定する際、devやstagingなどIPでアクセス制限している場合、mablダッシュボードからファイアウォールルールを追加してmablで操作するための設定が可能です。

Test

E2Eテスト自体のことで、具体的には「会員登録する」「メッセージを送る」などのユーザーシナリオが該当します。mablではアプリケーションとの各インタラクションにあたるStepを記録して実装します。Stepの中で、アプリケーションが期待通りに動作していることを確認するためのアサーション (遷移先URLや要素の有無などのチェック)を行います。単純なインタラクションだけでは不十分な場合には、カスタムJavaScript・Cookieの設定・条件付きロジックなどの高度なステップを含めることもできます。

Trainer

テストの作成・編集は、Google Chrome拡張機能であるmabl trainerを使って行います。テストが保存されると、サポートされているブラウザを設定しクラウド上でテストを実行することができます。また、保存されたテストはmablを操作できるコマンドラインツールmabl CLIを使ってローカルでテストを実行することもできます。

Plan

Testの実行計画を設定するためのものです。1つ以上のTestをまとめて設定しmablがいつ、どの環境(Environment)のテストを実行するかを定義します。例えば「すべてのリグレッションテストをカバーするテストを含むPlanを作成し、毎週実行」するようにスケジュールし、staging環境に対して実行します。また、Planではクロスブラウザの設定や、Planに含まれる複数のTestを直列または並列実行するかなど、Test実行方法を細かく選択することができます。

Eightにおけるmablを使ったE2Eテスト実装・運用の流れ

mablの基本的なコンセプトをつかめたと思いますので、ここからはEightにおける実際のE2Eテスト実装・運用の流れを説明します。
前提として、mablダッシュボードでの初期セットアップがされた状態を想定します。
また、語彙統制としてここではmablコンセプトに合わせてE2EテストをTestと呼ぶこととします。

1. テスト設計を行う
2. Test用Eightユーザーアカウントを新規作成する
3. Testを実装する
4. Testを実行・レビューする
5. Planを作成・定期実行開始

1. テスト設計を行う

ドキュメントに、対象ユーザーシナリオにおけるTest実装要件・使用するアカウント情報などをまとめます。特にTest実装要件はQA・エンジニア・サービスのステークホルダー(プロダクトマネージャーなど)間で、実装するTestで担保すべき事項に合意する上で重要なためきちんと文書化します。

2. Test用Eightユーザーアカウントを新規作成する

Eightでは原則「1Test1Eightユーザーアカウント」としてTest管理をしています。そのためmablでのTest実装へ入る前に、使用するEightユーザーアカウントを作成します。
「1Test1Eightユーザーアカウント」とした理由としては以下が挙げられます。

• Eightは権限や状態によって期待値やフローが変わるケースが多い
• 何度もTest実行するために操作後の状態を元に戻す必要がある

複数のTestを共通アカウントで実施する選択肢もありますが、1Testが複雑でメンテナンスコストが高くなることが予想されたため「1Test1Eightユーザーアカウント」としました。

3. Testを実装する

いよいよTest実装に入ります。UIを操作しながら「ボタンを押下する」「フォームにテキスト入力する」などのStepを記録していきます。Stepを記録していく中で「遷移後のURLが期待通りのURLであるか」「登録操作が行われた後の表示が正しいか」といったアサーションStepを、期待通りに動作していることを確認するために加えていきます。Test実装はUI操作中心なので、初めて触った時からあまりつまずくことなく作業を進めることができました。

＊Eight企業向けプレミアムでのTest実装イメージ

Eightではメール受信を含むユーザーシナリオが多数ありますが、テストコードではそれらのTestに対応できていませんでした。しかしmablにはメールをチェックするための機能であるmabl mailboxが備わっていて、今回対応することができました。

＊Eight企業向けプレミアムでのTest実装イメージ

4. Testを実行・レビューする

Testの実装作業が終わったら、実際にブラウザを指定してTestを実行してみます。Test実行方法はいくつかあるのですが、最も簡単なのはmablダッシュボードのTest詳細画面から行う方法で、Testを実行するブラウザを選択して開始します。Test実行が終わるとTest一覧に成功・失敗のStatusが表示されます。EightではTestを実行して成功したら、実装者とレビュワーでレビューを行って実装要件に問題なければ実装完了としています。

＊mablダッシュボードでのTest実行設定イメージ

5. Planを作成・定期実行開始

定期実行を開始するために実装したTestを含めたPlanを作成します。Eightでの定期実行は現状週1としていて、PlanでのTest実行結果をslackチャンネルへ通知するように連携しています。slack通知で届く失敗したTestをチェックして、それぞれのチームの担当者が修正しています。また、定期実行以外にもチームごとに開発スプリント内のリグレッションテストで別途Test実行しています。

＊Testのslack通知イメージ

mabl導入・運用してみて

mablを本格的に使い始めてから3ヶ月程度を経過しましたが、Eight Webの主要なユーザーシナリオのうち60~70%程度を実装して運用に乗せることができました。
さらに、実際にTestを回すことでサービスとして重要なユーザーシナリオのバグを早期発見して、市場流出を防ぐこともできました。特に開発スプリントやライブラリアップデートによるリグレッションテストにおいて、効果を発揮していると感じます。
テスト自動化への参加メンバーについては、導入初期の段階は機能の検証やどうしてもコードで対応しなければならないケースもあるためエンジニアがいるのが望ましいと感じました。

今後解消していきたい課題

一方で、関わったメンバーからは次のような課題も出ているので今後解消に向けて取り組んでいきたいと思います。

• IEでTest実行した際、失敗するケースがまだ多く一定の修正コストがかかってしまっている
• Test実装においてルール化できていない部分があり、共通化が適切になされていない
• 重要度の高いPlanのみCI/CD連携
• 新規の開発案件においての正常系Test実装の実現

最後に

本稿では、mablを使ったEightにおけるE2Eテストチーム自動化の取り組みについて紹介しました。まだ課題は多いですが、mablの導入でQA担当者の負担が軽減されてきたと同時に、継続的にE2Eテスト実行することでバグ早期発見の仕組み化が実現できてきました。
リソースとパフォーマンスのバランスを取りながら、引き続きより良いE2Eテストチーム自動化のカタチを目指していきたいと思います。