こんにちは、SOMPO Digital Lab QAエンジニアの穴原です。
以前書いた記事「SOMPO Digital Labでの品質向上の取り組みをご紹介します」でSOMPOホールディングスの内製開発組織での品質向上に向けた全体戦略についてお伝えしました。 今回はその中でも触れているE2Eテストの自動化に活用しているツールの選定過程について記載します。
はじめに
約1年ほど前の話になるのですが、E2Eテスト自動化ツールのAutifyの導入を決定しました。 そこから1年が経過して順調に利用できていることもあり、当時のツール選定についてこれまでの利用状況も含めて振り返ってみることにします。
導入検討を開始した経緯
当時なぜE2Eテスト自動化ツールの導入を検討したかというと、デプロイするとこれまで動いていたものが動かなくなることがたまに発生しており、これが全体の開発生産性を下げているという問題がありました。
PlaywrightやCypressを利用した自動化ももちろん実施はしていたものの、プロダクトのコード作成やユニットテストのコード作成に加えて、テストコードの作成やメンテナンスを続ける作業コストも小さくないこともあり、かといって手動での確認も煩わしいこともありツールの導入をしてみようかという話が持ち上がりました。
検討の進め方
当時すでに実績のあるSaaSのツールがいくつかある状況だったので、それらをベースに検討を進めることとしました。
各社のホームページなどWeb上参照できる情報を集めながら必要であればデモを依頼し、自社で実現したいことにマッチしそうかを検討し、その上で実際にトライアルを行うプロダクトとして下記の2社を選定しました。
- Autify
- MagicPod
導入後はエンジニアによるツールの利用も予定していたので、トライアルではQAだけでなくエンジニアからも有志を募って行いました。
機能での検討
機能面では以下のような観点で比較しました。
基本的な機能
まずはE2Eテストの基本的な部分について。
- テスト作成、編集
- 短時間で作れるか
- エンジニア以外にも作成やメンテが可能か
- テスト実行の安定性
- テスト失敗時の調査のしやすさ
- メンテナンスのしやすさ
Playwrightなどのテストコードから切り替えるにあたって、生産性の高さ＆保守コストの小ささは重要な観点でした。 ここは実際に触ってみないとわからない部分だったのでトライアルで実態の把握をしました。
ツールによって作り方に差はあるものの、実際に使ってみるととてもサクサク作れました。 Autifyでは実際に画面操作をしながらテストスクリプトを記録するのに対して、Magic Podは画面情報を取得してその画面情報を元に順にシナリオを組み立てていく、という操作方法でした。
新規で新しくテストスクリプトを作成する際にはAutifyの方が手短にできて、Magic Podの場合には既存テストの編集がやりやすい。（初回作成時にテスト対象の画面情報を保存しているので、編集時にはテスト対象の画面を操作しなくてもテストの編集ができる） この辺りの差分は慣れ＆好みかなと感じました。
トライアルをしてみて感じたことはこれまでコツコツ手でコードを書いていたのは一体何だったんだろうという感想でした。
実行の安定性もしっかり対応されているのでテストが失敗することはほとんどなく、また画面上の要素の軽微な変更であればスクリプトの変更をせずに追従してくれるので、E2Eテストあるあるの「画面を少し変更しただけでテストが通らなくなる問題」への対処もなされています。
これまで１年ほど使ってみてもこの辺りのテストスクリプト作成の生産性の高さや実行の安定性については十分に利用に値するものだと感じています。
前職ではノーコードでのE2Eテスト実行ツールの内製開発でリードエンジニアをしていたものの、当時は実行の安定性を実現するのにとても苦労した記憶がありました。 せっかく便利なものがあるなら、いちいち自前で開発せずにお金出して利用すべきだなと痛感しました。
対象システムへのログインに関する機能
次に目立たない部分ではあるものの、テスト対象のシステムにログインできるかどうかについても重要な観点として存在します。
当社で内製開発しているシステムは原則的にMFAへの対応が必要になるため、それらへの対応状況についても確認しました。
- 固定IPによるアクセスができるか
- 多要素認証を備えたアプリへのログインができるか
- QR認証、メールによる認証コードなど
メール送信される認証コードの利用やQRコードによる認証は問題なかったものの、SMS認証については当時トライアルした際には各社未対応だったように記憶しています。
また、SOMPOグループ会社内での利用に限定されるシステムの場合にはホワイトリスト形式で接続元のIPアドレスを制限するケースも多いため、テスト実行元の端末のIPを指定できることも重要な点でした。
利用しやすさ
次に必須ではないものの、あると便利なものとして以下のような観点での調査も行いました。
- CIからの実行ができるか
- テスト実行回数の制限があるか
- 並列実行数をどこまで増やせるか
テスト実行回数の制限については導入時はあまり重要視してはいなかったのですが、実際に利用するフェーズにおいては費用とテストの実効性に直結する部分でもあるので、観点としては大事だなと感じています。
Autifyでは事前に購入したクレジットを利用して実行をする形式で、MagicPodは実行数が無制限のようにAutifyとMagicPodでは取り扱いに違いがあるようです。
現状の運用では残りクレジット数を意識しながらテストの実行頻度を調整しているものの、本来はコード変更の直後にテスト実行してなるはやで問題を検出したいなとも思っています。
並列実行については逆に運用では今のところあまり重要な要素にはなっていません。 実行しているテストシナリオの量がさほど多くないことや、テストのシナリオ的に同時実行すると意図しない動作をするものもあることもあり、ほとんど直列実行で運用をしています。
対応可能なテストオペレーション
対応可能なテストのバリエーションに影響する機能についても以下の観点で確認を行いました。
- 見た目の変更を検知できるか
- クロスブラウザの対応ができるか
- メール本文の内容をチェックができるか
- ファイルの内容をチェックができるか
実際の運用では見た目の変更は画面単位で実施することがほとんどで問題があればそのタイミングで対処されるため、あまり自動テストで問題を見つけることは多くない印象です。 ただ、コンポーネントの差し替えのように画面横断的に変更が生じる際には変更前後の比較がしやすく役立っています。
メール本文のチェックは画面を中心に触っていると確認の頻度が低くて問題に気づきづらいので、ツールでリグレッションテストが実施されるのは助かっています。
アカウント＆権限管理
アカウントの管理に関する観点として、以下の確認も行いました。
- SSOによるログインの可否
- 管理者とユーザーとの権限の分離
- プロジェクトごとでの権限管理
- ユーザー数制限の有無
- ユーザー追加時の課金の有無
当初はプロジェクトごとにワークスペースを分けて細かく権限を管理しようかと考えていましたが、調べてみたところコスト面での負担が大きくなることもあったのでやめました。
そのほかの観点での検討
機能面の他にも以下のような点を確認しました。
- ドキュメントの充実度
- サポートのクオリティ（レスポンスの速さや内容）
ドキュメントやサポートは自走のしやすさとして確認しました。 ただ、実際に利用してみるとわかりやすいUIでドキュメントなしでも利用できるシーンがほとんどで触りながら覚えていけて、たまにわからないことがある時に参照する程度でした。
あとは提供企業がスタートアップということもあり、今後企業や製品がどのように成長していくかという視点で以下の項目をチェックしました。
- 資金調達状況
- 導入事例
- 開発メンバーや人数
まとめ
トライアルをしてみて各社ともに基本的な機能は揃っていてベーシックなテストは対応ができるように感じました。 とはいえ、自社のシステムに合うかどうかは試してみないとわからないので、期待通りに動作することをトライアルを通じて検証するのはとても重要だと思います。
当時選定をする際にどんな観点で確認したら良いか頭を捻った覚えがあるので、これからツール選定をする方にこちらの記事が参考になれば幸いです。
SOMPO Digital Labでは一緒に働くエンジニアを募集しています
SOMPO Digital Labではエンジニアを募集しています。
以下のリンクからカジュアル面談の応募ができますので、興味を持った方は是非話を聞きに来て下さい！
