はじめに
こんにちは。enechainのQAエンジニアのtaise- です。
enechainのQAチームでは、昨年より各プロダクトのE2Eリグレッションテストの自動化を進めており、ツールとしてMagicPodを活用しています。既に導入・運用を開始しているプロダクトがある一方で、現在導入準備中のプロダクトも存在します。
本稿では、以下の点について、enechain独自の経験を交えながらご紹介します。
- 自動化ツールの選定
- ツール導入から運用開始までの流れ
- 自動化推進における課題と展望
本稿が、E2Eリグレッションテストの導入を検討されている方、または運用中の方にとって、少しでも参考となれば幸いです。
E2Eリグレッションテスト自動化のモチベーション
E2E（End-to-End）リグレッションテストは、機能追加や修正によって既存機能が意図せず壊れていないかを確認するために行われます。
E2Eリグレッションテストを実施する主なメリットは以下の通りです。
- ユーザー視点での品質保証：実際のユーザーの操作フローを模倣することで、より現実的な視点から品質を保証できます。
- システム全体の整合性確認：複数のコンポーネントが連携するシステム全体を通して、問題がないかを確認できます。
- 本番環境に近いテスト：本番環境に近い環境でテストを行うことで、リリース後のトラブルを未然に防ぎます。
一方で、E2Eリグレッションテストはシステム全体を含む包括的なテストとなるため、実行に時間がかかります。これをシステムに何らかの変更が加えられるたびに繰り返し実行する必要があるため、その対応コストおよび速度が課題となります。
そこで、E2Eリグレッションテストを自動化することによって、その課題を解決し、以下のメリットを得ることができます。
- テスト効率の向上: テスト実行を自動化することで、手動テストに比べて大幅な実行時間の短縮が可能です。
- テスト精度の向上: 自動化により人的ミスを排除し、テスト実行精度を高められます。
- 継続的な品質保証：定期実行やCI/CDパイプラインへの組み込むによって、常に最新の状態での品質保証を実現できます。
enechainにおいても、品質向上とリリースサイクルの短縮の両立を目指し、E2Eリグレッションテストの自動化に着手しました。
自動化ツールの選定
E2Eリグレッションテストの自動化に取り組むため、まずはツールの選定をしました。
enechainが自動化ツールに求める要件は以下の内容でした。
アプリケーションエンジニア・QAエンジニア双方でテストの作成やメンテナンスができること
enechainは複数プロダクトの開発を同時並行で行っており、各プロダクト1〜2名の専任QAエンジニアが担当しています。その中で、各プロダクトのアプリケーションエンジニアのみ、QAエンジニアのみで自動テストを作成・メンテナンスしていくことは困難なため、両者が協力して利用できることを重視しました。
2要素認証の突破に対応していること
enechainのプロダクトはログインする際の2要素認証が必須となっています。ログインも含む包括的なテストを自動化するため、認証アプリ、SMSのいずれかの方法で2要素認証を突破できることを必須要件としました。
ケース内で複数のドメインを跨ぐテストができること
enechainの主要なプロダクトは、顧客向けシステムの他、社内のブローカーやオペレーター向けシステム、システム管理者向けシステム等、複数のシステムで構成されています。プロダクトのユースケースの多くは、これら複数のシステムを跨いで構成されるため、テストケースの実行においても、ドメインの異なる画面を跨いだ手順が必ず含まれます。そこで、1つのテストケース内で複数ドメインを跨いだテストの実行に対応していることを必須要件としました。
以上3つの要件をもとに、候補となるツールの中からもっともenechainの要件を満たすものがどれかを検討しました。
候補として当初はCypress等のテストフレームワークもありましたが、1つ目の要件を加味し、JavaScriptが書けないQAエンジニアでも扱えるノーコードツールとして、Datadog Browser Test, Autify, そしてMagicPodの3つに絞って検討しました。
結論として、比較検討の結果enechainではMagicPodを採用することにしました。各要件に対するMagicPodの評価は以下の通りです。
アプリケーションエンジニア・QAエンジニア双方でテストの作成やメンテナンスができること
ノーコードツールであり、UIもわかりやすく、はじめて使う人でもすぐに操作に慣れることができました。
2要素認証の突破に対応していること
認証アプリを用いた2要素認証に対応しており、TOTPのQRコードを登録しておくことで、認証のタイミングでワンタイムパスワードを生成できました。
ケース内で複数のドメインを跨ぐテストができること
ケース内で複数のドメインを跨ぐ手順の実行も特に制約なく可能でした。
この他にも、以下のようなノーコード系ツールの弱い部分を補う機能も充実しており、総合的に評価した結果、MagicPodを選択しました。
- 使用頻度の高い共通の手順を1つの共通ステップにとして切り出し他のケースに流用することができる
- ページのHTMLの要素、属性、値等を変数に格納し、ロケータや要素の評価に使用できる
- ループや条件分岐といった制御のための機能が強力
- 説明文、コメント、ラベル付け等、テストケースの理解や可読性を高める機能が充実している
導入・運用
ツールの選定ができたので、ここからは導入から運用までの流れを説明しつつ、実際にMagicPodを使っていて良かったことや大変だったことをお話します。
1. 社内承認の獲得
導入の最初のステップはMagicPod導入に伴う予算承認の獲得です。
これについては、大きな苦労はなく、前述したE2Eリグレッションテストの課題やモチベーションを事前にCTOと共有できていたため、スムーズに承認を得ることができました。
自動化ツール導入のROIを定量的に示すことはなかなか難しいです。 しかし、我々のようなスタートアップにおいてはスピードも非常に重要で、プロダクトリリースサイクルを早めていくためにはE2Eリグレッションテストの自動化が必要、という点において同じ目線を持てていたことが大きいと考えています。
2. 運用ルールの策定
enechainでは自動テストのケースはアプリケーションエンジニア・QAエンジニアと、複数人で作成・メンテナンスしていくことを当初から想定していました。このとき、人によってケースの作り方や管理方法が変わってくると、自分以外が作成したケースの理解や編集ができない、どこにどんなケースがあるか全体像の把握や管理が難しい等の課題が生まれます。
そこで、複数人が共同で適切にテストを管理・運用していけるよう、MagicPodを利用する上での最低限の運用ルールを定めました。
テストケース名、ケース情報の記載
ケース名を見ただけでどのプロダクトのテストなのかがわかるようにします。
ケース情報にはテスト内容、もしくは別シートでまとめているシナリオと紐付けるためにシナリオNoを記載し、そのケースがどんなテスト内容なのかをわかるようにします。
テストケースのラベル設定
そのケースの作成が完了しているのか、自動実行に乗せていいケースなのか等ステータスを判別するためにラベルを設定します。
キャプチャの名前統一
テストケースが増えるとどうしてもキャプチャは増えていきます。 自分が使いたいキャプチャがどこにあるか探しやすくするため、また不要なキャプチャを残さないために、画面名や状態の名前をつけます。
手順の可読性を高めるための工夫
シナリオNoや実施内容をコメントとして記載する、手順の区切りに空行を入れる等、可読性を高め、作成者以外が見ても内容が把握しやすいようにします。
3. 実装
運用ルールが定まったため、実際にMagicPodを用いてテストを実装していきます。
多くのプロダクトではすでにE2Eリグレッションテストのケースがあり、定期的に手動で実行している、という状況でした。そのため、テスト実装にあたっては、テストの優先度が高いケースからピックアップして自動化を行いました。
また、一部E2Eリグレッションテストケースがまだないプロダクトの場合は、CUJ(クリティカルユーザージャーニー)を元にシナリオを作成し、ケースに落とし込むところからはじめました。
フレーキーテストの回避
自動化したケースが、ある時は成功し、またある時は失敗するといったような不安定なケースにならないよう、基本的なことではありますがいくつかの対策をしています。
ロケータに変わりやすい値を使わない
ビルドする度に値が変わってしまうようなIDをロケータに設定していると、要素が見つからず失敗してしまいます。そのため、変化しないIDやname属性などを使用しています。
画面遷移の待機
画面遷移を挟むテストの場合、環境によっては動作が重く、遷移後の画面表示が完了する前に手順だけ進んでしまった結果、要素を取得できずに失敗することがあります。
その場合は、「⚪︎秒待つ」や「⚪︎⚪︎が表示されるまで待つ」のような待機処理を入れます。
4. 運用
実装したケースの運用を開始します。
実行のトリガー
定期的に実行するかCIと連携するか等、実行トリガーをプロダクトチームと相談して決めます。
定期実行
毎週特定の時間にテストを走らせています。
定期的に実行することで、システムの安定性を継続的に監視しています。
実際にマニュアルテストで発見できなかった不具合をリリース後に早期発見できました。
CI連携
CI/CDパイプラインに入れて、コード変更後のビルドしたタイミングで自動的にテストを実行しています。
開発者はテスト実行にかかる時間を削減し開発に集中できるのと、リリースサイクルの高速化が期待できます。
実行結果の通知
実行結果はプロダクト毎に設定したSlackチャンネルに通知しています。
失敗した際には、担当のアプリケーションエンジニアとQAエンジニアをメンションし、すぐに確認しています。
失敗原因の調査
テストが失敗した場合、エラーメッセージやログから原因を特定します。
アプリケーションの問題の場合にはバグチケットを起票します。一方、テスト側の問題である場合は、すぐに直せるものはその場で直して再度テストを実行し、そうでない場合は該当のテストケースを一度自動実行から外し、時間が確保できた時にまとめて改修しています。
課題と今後の展望
ここまでenechainでの自動化運用についてお話しましたが、実際にはまだまだ課題がたくさんあります。
現状、システムテストの計画・設計・実行等、他のQA業務に多くの時間を割いている実情があります。 これにより、
- 自動テストのメンテナンスに十分な時間が取れず、数日間テストの失敗が放置される
- プロダクトの仕様変更に追従しケースに反映するためのフローが確立しておらず、実行が失敗してはじめてケース修正が必要なことに気付く
等の課題が発生しています。
そこで、
- 仕様書に自動ケース修正有無の記入欄を作って、修正が必要かどうか判断する
- テスト計画の段階で自動テストのメンテナンスもスケジュール計画に含めることで、そのための時間を確保する
等、工数を計画的に確保し、常に最新の仕様に合わせたケースを維持できるような施策が必要だと考えています。
この課題については 、QAチームの4-7月のOKRの中で「持続可能なE2E自動テスト導入・運用のプロセス定義と適用」というKRを立てています。
このKRを通じて、以下の状態を実現していきます。
- テストケースのFailが即時に検知されていて、計画的に修正対応が行われている
- プロダクトの改修に対して、E2Eリグレッションテストへの影響の有無が認識できている
- プロダクト改修に対するE2Eリグレッションテストの追従がタスクとして管理され、計画的に行われている
- E2Eリグレッションテスト自動化の新規導入について、プロセスが定義され、ドキュメントになっている
ここで定めたプロセスに沿って、プロダクトチームのアプリケーションエンジニアとQAエンジニアとで一緒にプロセスの適用に取り組んでいきます。
また、プロダクトによってはまだ自動テストに取り組めていないものもあるため、今後さらに自動テストの活用範囲を広げ、リグレッションテストの実施工数削減とリリースサイクル短縮を目指していきたいと考えています。
最後に
ここまで読んでいただきありがとうございました。本記事が自動テストの導入を検討している方にとって少しでも参考になれば幸いです。 また、E2EリグレッションテストにはMagicPodを使っていますが、インタラクションテストにはPlaywrightを利用する等、テストの種別に応じてツールを使い分けています。ぜひこちらの記事もご覧ください。
enechainでは、事業拡大のために共に技術力で道を切り拓いていく仲間を募集しています。