E2Eテストの運用を属人化しないための3つの取り組み

QC

はじめに

こんにちは。QCの佐藤です。
月日が経つのは早いもので、QCメンバーも増え、多くのメンバーがブログを書いてくださっており嬉しい限りです😊*1

私がブログを書いたのはもう2年前...（徐々に間隔が長くなっている...）
今回は私の担当しているプロジェクトでの、E2Eテスト管理・運用方法についてお話します。
以下のような課題ってE2Eテストあるあるですよね (´;ω;｀)

  • E2Eテストの運用が属人化してしまっている... 
  • むか～しに作ってからはただ回しているだけ...
  • テストに失敗していることはわかっているけどなかなか直せない...

この記事で少しでもお困りごとの手助けになれば幸いです！



1. 定期実行結果確認の持ち回り

E2EテストはAutifyを採用しています。
Autifyにはテストプラン という複数のシナリオをまとめる機能があります。
この機能の定期実行を平日9:00に設定し、実行結果をslackへ通知するようにしています。

テストの実行環境は開発環境です。

実行結果の確認は、曜日ごとにメンバー固定にしており、Slackのワークフローで10時に投稿されます。
担当者はワークフローに沿って実行結果を確認します。
実行結果を確認するメンバーは、エンジニアとQCで担当しています。

slackのワークフロービルダー機能を使用してAutifyの確認依頼を通知している

お休みを取得する方も考慮して、代打の担当者も指定しています。
このように曜日固定とすることで、開発メンバー全員でE2Eテストに関わるようにしています。*2
この運用とワークフロービルダーの設定はエンジニアさんが推進してくださいました 🙌

 

2. テスト失敗時の運用をドキュメント化

E2Eテストの性質上、テストを安定させることは難しいため、たびたび失敗してしまいます。
失敗したときに困らないよう、テスト失敗時のフローをドキュメントにまとめています。*3
現在は以下のフローで運用しています。

  1. テスト失敗を検知
  2. 1次対応（調査・修正）
    1. Autify側の不調で失敗していた場合
      • 再実行を行う
    2. 修正が必要だが、すぐ直せる場合
      • 対応チケットを作成（推奨）*4
      • 修正を行い、再実行を行う
    3. 原因不明 or 修正が必要だが、すぐ直せない場合
      • 対応チケットを作成
      • Slackの実行結果確認スレッドに起票したチケットのリンクを貼る
  3. 2次対応（原因不明 or 修正が必要だが、すぐ直せない場合）
    • 失敗しているシナリオをテストプランから外す
    • チケットをスプリントに積み、優先的に対応する
      • 基本は本番リリース前に修正する
    • 朝会等で事象を共有する
  4. 3次対応（修正）
    • 原因を特定し、修正する
    • 修正したシナリオをテストプランに戻す

一方で、ドキュメントにまとめてはいるものの、Slackでコミュニケーションを取りながら対応について話す場合もあります。

この運用により失敗の検知後、翌日以降も同じシナリオが失敗することを防ぐことができました。

なお、ドキュメント化は失敗時だけでなく、運用全般で行っています。
ドキュメント化することでメンテナンスコストはかかりますが、属人化してしまうより... と作成しました。

Autifyの運用をまとめたドキュメント

 

3. E2Eテストのシナリオをスプレッドシートで管理

E2Eテストケースの管理って悩みますよね...
理想はE2Eテスト管理ツール内で完結することだと思っているのですが、実際は手動テストを併用して実行するため難しいです。

現在担当しているプロジェクトでは、主要機能テストケースをスプレッドシートで作成しています。
そのテスト項目書に自動テストの項目として「シナリオID」「対応するチケット」「優先度」を追加しています。
テスト結果記載欄は「自動」というステータスにしています。

テスト項目書のイメージ

テスト項目書で一元化することで、どの程度自動化されているかも把握できるようにしています。
また、優先度を設定することで、優先度の高いものから自動化を進めることができています。

一方で、このテスト項目書の管理がQCチームのメンバーに属人化しているという課題があります。
どの程度自動化されているかは見える化できているので、この課題については引き続き改善策を考えていきます。

また、今後はテスト管理ツールへの移行も考えていきたいです...！
テスト管理ツールを導入しているプロジェクトはあるので、参考にさせていただく予定です。


さいごに

何か新しい取り組みを行う時、初めは属人化してしまってもよいと個人的には思っています。
ただ、運用が波に乗って来た際に今のままでよいのかな？と立ち止まり考えることが大事だと考えています。
いつか属人化していることでボトルネックになってしまい、誰かが困ってしまうかもしれません。
それは幸せなことではないかもしれないので、運用を見直すことも時には必要ですね♪
こちらの記事でE2Eテスト管理運用のお役に少しでも立てれば幸いです！


アンドパッドでは、一緒に働く仲間を募集中です！
ぜひ採用サイトをご覧ください。

engineer.andpad.co.jp

 

*1:組織名称や役割をQC、テスト関連タスクや開発工程をQAと分類しています

*2:今後メンバーの増減によっては曜日固定ではなく日替わりで担当者をローテーションすることも考えられます

*3:ドキュメント管理はConfluenceを使用しています

*4:チケット管理はJIRAを使用しています