この記事では
2021年の話ですが、E2Eテスト自動化を試みMagicPodのトライアルを行いました。
チームに展開するために結構いろいろ考えていたので（結局諸事情で展開には至りませんでしたが・・・）、その時に検討した内容を墓標備忘として残しておきます。
あくまでトライアルの時に検討した内容であり、本導入における課題や工夫などには触れていません。
冒頭にMagicPodと記載してはいますが、記事内容のうちMagicPodに限定した内容はありません。
対象とする読者
E2Eテストツールのトライアルをしてみようか、何すればいいかこれから考えるか、くらいの人
そもそもE2Eテストとは？という方へ
さらっと読める記事がありました。
E2Eテスト(インテグレーションテスト)の利点と不利点
（参考）弊チームについて
mcframe SIGNAL CHAIN という製造業向けのIoT＋業務管理アプリケーションを開発しています。BtoBです。
開発者５名ほどで開発＋テストしており、QA専用チームなどはありません。
トライアルのプロセス
以下のプロセスを経てトライアルしました。チームへの共有資料作成と合わせて４日ほどかけました。※リンク先は弊チームに当てはめた場合の検討結果です。
弊チームの場合
ツールを試すという判断に至った理由
- 長期的にSeleniumをメンテする覚悟はない。
- トライアルを主導したメンバー（私）はE2Eテストが担当の１つであった。
当時の課題
- テストドキュメントにはざっくりとしたテストケースしか記載しておらず、詳細は属人化している。
- バグ修正の影響を考慮できておらず、他機能で新たなバグが生まれることがある。リグレッションテストもできていない。
- フロントエンドのフレームワーク（Angular）の更新のたびに全画面を手動テストしており、負担が大きい。
- ユーザー向け機能の開発が優先されており、テストコードは機能を網羅できていない（バックエンド側も）。新規開発は止められない。まさにアイスクリームコーン状態。
- QA専任のメンバーがいない。
- テストの質を維持したまま効率化し、リリースサイクルを早めたい。
ツールを簡単に試す
ツールで何ができるかざっくり知らないと後続のイメージがつきにくいです。２～３時間ほど触ったりマニュアルを読み、以下を確認しました。
- テストケース作成の手順
- 画面コンポーネントの指定方法
- 評価の種類
- 画像比較方法 など
- 手動実行手順
- PC版/モバイル版
- ローカル環境/テスト環境
- テスト実行結果の見方
- 不具合発生時の通知
- 結果分析
- パイプラインからの呼び出し方法
- ライセンスと実行回数の考え方
テスト自動化の目的を設定する
以下のように目的を設定しました。下２つはできたらいいなくらいの気持ちでいました。
- 過去発生した不具合を検知し、再発を防止する。
- （Angular更新による不具合発生を検知し、最終的に更新を自動化する。）
- （テストケースを一覧にし、属人化を排除する。）
自動化する候補を決める
１．過去不具合から候補を選定する。
各不具合に対し、自動化の相性を検討し分類しました。
- 自動化するもの
- シンプルな操作でテストできるもの
- 毎回のテストで実施すべきもの
- 自動化しつつ人が内容を確認する可能性がありそうなもの
- スクショの撮影までをツールで行い、判定は人がやる、など
- 今までどおり手動で対応するもの
- 操作感覚の評価（UX）
2. 候補ごとに、不具合発生時のビジネス影響を評価する。
再発した場合、顧客業務にどれだけインパクトがあるかをざっくり評価しました。金額などで定量的に出したいかもしれませんが、予想であることには変わりませんし、検討のスピード感を重視します。
- High：顧客業務そのものが止まる
- Middle：顧客がストレスを感じる
- Low：顧客が気づかない/気にしないレベル
3. 優先度を決める
上記1,2から、ざっくりと優先度を決めます。①が優先なのは間違いないとして、②～⑤はチームの事情を考慮して決めれば良いと思います。
完全自動化できるものでも優先度に内訳（「正常系を先」や「データ準備が難しいものは後」など）はあると思います。それらはツール機能検証の後に改めて考えるつもりでした。
ツールに求めるもの（要件）を考える
確認する前に、ツールに求めるものを洗い出しておきます。MUST/WANTなど濃淡ありますが、弊チームの場合以下でした。
- テストケース作成/管理への要件
- テストしたい操作に対し、ツールが十分対応している
- APIのテストができる
- よくある操作の流れ（ログインなど）をコンポーネント化できる
- UI変更時の修復操作が容易である
- テストケースを一覧で確認できる
- コードを書いてテストケースを加工できる（評価用に文字列を加工するなど）
- テストケースのインポート/エクスポートできる（Git管理用）
- 影響箇所を調べ、一括変更できる
- 画像比較でき、（異常ではなく）警告を出せる。問題なければ次回から新画像で評価できる
- 実行結果管理への要件
- Slackへの通知機能がある（もしくは作れる）
- キャプチャを一括で確認できる
- 結果を見てすぐにテスト修正できる
- 問題があればJIRAのチケットをすぐに起票できる
- 実行方法/環境への要件
- 部分実行/一括実行できる
- ローカル実行/クラウド実行できる
- Jenkinsから実行できる
- モバイルブラウザ/PCブラウザへ対応できる
- 並列実行できる
- 顧客に提供した過去バージョンに対応したテストプロジェクトを保持し、実行できる
- テスト時間が長すぎない
- サポート
- ドキュメントを見ればわかる
- チャット形式で確認できる
- セキュリティ
- 情シスからOKをもらえる
- ライセンス
- 想定する実行回数、テストケース数、ユーザ数を満たす
- 金額感が予算の範囲内である
- その他
- 全体的にUI/UXが良く、メンバーに受け入れてもらえる
ツールを試す
ツールを試しつつ、以下を確認していきます。
- 自動化候補のうち、テスト実装できそうなものとできないもの。また、それぞれのテストケースの作成時間。
- 要件を満たせるか。満たせないものについては代替or外側でどうにかできるか、もしくは諦められるか。
課題を整理し、運用を検討する
課題感（当時）
- テストケースの管理方法として、手動でやるべきテスト、自動実行されるテストがわかるようにしたい。
- プロジェクトやテストケースを、基本プランに収まる範囲で、メンテしやすいよう組まなければならない。
- 保守性を高めるため、ロケータとして取り扱うべきプロパティを決め、全体的にリファクタリングする必要がある。
属人化を防ぐために必要そうなこと
- メンバーがツールに対して一定の習熟度を保てるようにする
- 一定の習熟度：テストケースを組める / 実施結果から問題点を理解できる
- 定期的に触る/見る機会を組み込む
- ツールの使い方（目的、運用ルール、参照先）などを文書にまとめ、教育に利用できるようにする
ツール利用のフロー
属人化を防ぎたいので、チーム全体でツールを触るようにするつもりでした。このような流れになるでしょうか。
まとめ
E2E自動テストツールを検証するにあたり、検討プロセスを記載してみました。
せっかく導入側も提供側も時間を使うので、良い検証をするべきです。この記事が一助になれれば幸いです！