E2E自動テストツールをかっちりとトライアルするためのプロセスを書いてみる

## この記事では
2021年の話ですが、E2Eテスト自動化を試み[MagicPod](https://magicpod.com/)のトライアルを行いました。
チームに展開するために結構いろいろ考えていたので（結局諸事情で展開には至りませんでしたが・・・）、その時に検討した内容を~~墓標~~備忘として残しておきます。

:::note warn
あくまでトライアルの時に検討した内容であり、本導入における課題や工夫などには触れていません。
冒頭にMagicPodと記載してはいますが、記事内容のうちMagicPodに限定した内容はありません。
:::

### 対象とする読者
E2Eテストツールのトライアルをしてみようか、何すればいいかこれから考えるか、くらいの人

### そもそもE2Eテストとは？という方へ
さらっと読める記事がありました。
[E2Eテスト(インテグレーションテスト)の利点と不利点](https://qiita.com/NAKKA-K/items/58d6b8476a3717179bda)

### （参考）弊チームについて
[mcframe SIGNAL CHAIN](https://www.mcframe.com/product/signalchain/application) という製造業向けのIoT＋業務管理アプリケーションを開発しています。BtoBです。
開発者５名ほどで開発＋テストしており、QA専用チームなどはありません。

## トライアルのプロセス
以下のプロセスを経てトライアルしました。チームへの共有資料作成と合わせて４日ほどかけました。※リンク先は弊チームに当てはめた場合の検討結果です。

1. [E2Eテストまわりにおける課題感を洗い出す](#当時の課題)
1. [ツールを簡単に試す](#ツールを簡単に試す)
1. [テスト自動化の目的を設定する](#テスト自動化の目的を設定する)
1. [自動化する候補を決める](#自動化する候補を決める)
1. [ツールに求めるもの（要件）を考える](#ツールに求めるもの要件を考える)
1. [ツールを試す](#ツールを試す)
1. [課題を整理し、運用を検討する](#課題を整理し運用を検討する)

## 弊チームの場合

### ツールを試すという判断に至った理由
* 長期的にSeleniumをメンテする覚悟はない。
* トライアルを主導したメンバー（私）はE2Eテストが担当の１つであった。

### 当時の課題
* テストドキュメントにはざっくりとしたテストケースしか記載しておらず、詳細は属人化している。
* バグ修正の影響を考慮できておらず、他機能で新たなバグが生まれることがある。リグレッションテストもできていない。
* フロントエンドのフレームワーク（Angular）の更新のたびに全画面を手動テストしており、負担が大きい。
* ユーザー向け機能の開発が優先されており、テストコードは機能を網羅できていない（バックエンド側も）。新規開発は止められない。まさにアイスクリームコーン状態。
* QA専任のメンバーがいない。
* テストの質を維持したまま効率化し、リリースサイクルを早めたい。

### ツールを簡単に試す
ツールで何ができるかざっくり知らないと後続のイメージがつきにくいです。２～３時間ほど触ったりマニュアルを読み、以下を確認しました。
* テストケース作成の手順
  * 画面コンポーネントの指定方法
  * 評価の種類
  * 画像比較方法　など
* 手動実行手順
  * PC版/モバイル版
  * ローカル環境/テスト環境 
* テスト実行結果の見方
* 不具合発生時の通知
* 結果分析
* パイプラインからの呼び出し方法
* ライセンスと実行回数の考え方

### テスト自動化の目的を設定する
以下のように目的を設定しました。下２つはできたらいいなくらいの気持ちでいました。
* 過去発生した不具合を検知し、再発を防止する。
* （Angular更新による不具合発生を検知し、最終的に更新を自動化する。）
* （テストケースを一覧にし、属人化を排除する。）

### 自動化する候補を決める

#### １．過去不具合から候補を選定する。
 各不具合に対し、自動化の相性を検討し分類しました。
* 自動化するもの
  * シンプルな操作でテストできるもの
  * 毎回のテストで実施すべきもの
* 自動化しつつ人が内容を確認する可能性がありそうなもの
  * スクショの撮影までをツールで行い、判定は人がやる、など
* 今までどおり手動で対応するもの
  * 操作感覚の評価（UX）
 
#### 2. 候補ごとに、不具合発生時のビジネス影響を評価する。
再発した場合、顧客業務にどれだけインパクトがあるかをざっくり評価しました。金額などで定量的に出したいかもしれませんが、予想であることには変わりませんし、検討のスピード感を重視します。
* High：顧客業務そのものが止まる:rage:
* Middle：顧客がストレスを感じる:pensive:
* Low：顧客が気づかない/気にしないレベル:expressionless:

#### 3. 優先度を決める
上記1,2から、ざっくりと優先度を決めます。①が優先なのは間違いないとして、②～⑤はチームの事情を考慮して決めれば良いと思います。

<img width="45%" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3620254/f4b95927-5084-1e28-33c6-167634126644.png">

完全自動化できるものでも優先度に内訳（「正常系を先」や「データ準備が難しいものは後」など）はあると思います。それらはツール機能検証の後に改めて考えるつもりでした。

### ツールに求めるもの（要件）を考える
確認する前に、ツールに求めるものを洗い出しておきます。MUST/WANTなど濃淡ありますが、弊チームの場合以下でした。
* テストケース作成/管理への要件
  * テストしたい操作に対し、ツールが十分対応している
  * APIのテストができる
  * よくある操作の流れ（ログインなど）をコンポーネント化できる
  * UI変更時の修復操作が容易である
  * テストケースを一覧で確認できる
  * コードを書いてテストケースを加工できる（評価用に文字列を加工するなど）
  * テストケースのインポート/エクスポートできる（Git管理用）
  * 影響箇所を調べ、一括変更できる
  * 画像比較でき、（異常ではなく）警告を出せる。問題なければ次回から新画像で評価できる
* 実行結果管理への要件
  * Slackへの通知機能がある（もしくは作れる）
  * キャプチャを一括で確認できる
  * 結果を見てすぐにテスト修正できる
  * 問題があればJIRAのチケットをすぐに起票できる
* 実行方法/環境への要件
  * 部分実行/一括実行できる
  * ローカル実行/クラウド実行できる
  * Jenkinsから実行できる
  * モバイルブラウザ/PCブラウザへ対応できる
  * 並列実行できる
  * 顧客に提供した過去バージョンに対応したテストプロジェクトを保持し、実行できる
  * テスト時間が長すぎない
* サポート
  * ドキュメントを見ればわかる
  * チャット形式で確認できる
* セキュリティ
  * 情シスからOKをもらえる
* ライセンス
  * 想定する実行回数、テストケース数、ユーザ数を満たす
  * 金額感が予算の範囲内である
* その他
  * 全体的にUI/UXが良く、メンバーに受け入れてもらえる

### ツールを試す
ツールを試しつつ、以下を確認していきます。
* 自動化候補のうち、テスト実装できそうなものとできないもの。また、それぞれのテストケースの作成時間。
* 要件を満たせるか。満たせないものについては代替or外側でどうにかできるか、もしくは諦められるか。

### 課題を整理し、運用を検討する

#### 課題感（当時）
* テストケースの管理方法として、手動でやるべきテスト、自動実行されるテストがわかるようにしたい。
* プロジェクトやテストケースを、基本プランに収まる範囲で、メンテしやすいよう組まなければならない。
* 保守性を高めるため、ロケータとして取り扱うべきプロパティを決め、全体的にリファクタリングする必要がある。

#### 属人化を防ぐために必要そうなこと
* メンバーがツールに対して一定の習熟度を保てるようにする
  * 一定の習熟度：テストケースを組める / 実施結果から問題点を理解できる
  * 定期的に触る/見る機会を組み込む
* ツールの使い方（目的、運用ルール、参照先）などを文書にまとめ、教育に利用できるようにする

#### ツール利用のフロー

属人化を防ぎたいので、チーム全体でツールを触るようにするつもりでした。このような流れになるでしょうか。

<img width="75%" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3620254/0d5e4890-2b80-3677-28cc-5cd9de9490c0.png">

## まとめ

E2E自動テストツールを検証するにあたり、検討プロセスを記載してみました。
せっかく導入側も提供側も時間を使うので、良い検証をするべきです。この記事が一助になれれば幸いです！