E2E 自動テストの布教に立ち塞がる5つの壁と打ち込んだ楔

Transcript

1. E2E 自動テストの布教に 立ち塞がる5つの壁と 打ち込んだ楔 2024/03/26 株式会社 Magic Moment 矢野 崇 1
2. 背景 • ちょうど一年ほど前に一人目 QAE として join (2023/03/15) • 会社ではE2E 自動テスト (以後「自動テスト」と表記)の 導入をはじめていたタイミング ◦ 週1~2時間ほどで有志メンバーがテストコード作成中 ◦ 使用ツールは Cypress ◦ 実運用まではできていない状態 • 開発メンバーが主体となって自動テストの運用を できるように仕組みを整えはじめた 2
3. 背景2 • 去年末にこれまでの振り返りを兼ねて 弊社アドベントカレンダーの1記事として掲載 ◦ E2E 自動テストの布教に立ち塞がる5つの壁と打ち込んだ楔 • 記事の内容の説明 + 年明けからやってきたことを話します ◦ 自動テストを布教する上での学びや気づきをシェア 3
4. なぜ布教をしていたのか • 一人だけの QAE が自動テストの作成とメンテナンスを行うことは限 界がある • 仮に自動テストは整備できたとしても他のQA活動にリソースを使えな くなってしまう懸念 • 一人の熱量で自動テストを進めてもいずれはシェルフウェアとなって 破綻しがち 開発メンバーが主体となって自動テストを運用できる必要があった 4
5. どのようなプロダクトの自動テストを書いているか Magic Moment Playbook (MMP) 5
6. 1の壁 : 何のための自動テストか分からない • 特定のメンバーの熱量だけで推し進めていくとありがちな風景 ◦ 「なんだか流行っているみたいだし自動テストがあったほうがい いよね？」 ◦ 「アジャイル開発ではなんだか必要みたいだから、よくわからな いけどやらないと！」 ◦ 「なんでこんな大変な思いまでして自動テストするの？」 いずれメンテナンスも実行もされない自動テストへ、、、 6
7. 1の楔 : 自動テストの目的を定める • 自動テストのメンテナンスや整備をするメリットを考える ◦ OSSアップデートを気軽にできるようにする ◦ インフラのアップデートを気軽にできるようにする ◦ リリース後の動作確認作業の負担を減らす ◦ 人が実施するテストの前に自動テストで動作保証 ... ect 目的を定めればなぜ自動テストを整備しているか説明できるし、どのよ うなテストが必要か不要かも判断できるようになる 7
8. ２の壁：どのような自動テストを作成したら良いか分からない • 目的だけ定めてもいきなり具体的なテストコードは書けない • 具体的にどのようなテストが自動実行されれば良いかのイメージが 統一されていない状態 テストコードを書く前に具体的にどのような操作をするのか 明確なテストシナリオのドキュメントが必要となった 8
9. ２の楔 : テストシナリオを自動化の前に作成する • プロダクトにおけるクリティカルユーザージャーニー (CUJ) は何かを ヒアリングし、テストシナリオを作成 • テストシナリオは Notion 上に日本語で書いて管理 • Arrange-Act-Assert (AAA) パターンに沿って、テストの前提条件、 操作、アサーションを分かりやすく記述 9
10. 3の壁 : デザインパターンが分からない • 自動テストのデザインパターンを知っている人が社内にいない • テストコードをデザインパターンで抽象化、構造化する メリットが実際に自動テストを運用した人にしか分かりにくい • キャプチャ＆リプレイからエクスポートしたもの、サンプルコードでは 大抵リニアスクリプトで書かれている メンテナンス性と可読性の高いテストコードを実装できるように デザインパターンとディレクトリ構成を決める必要があった 10
11. ３の楔 : デザインパターンを決める • 実装ガイドラインを策定し、Cypress ディレクトリの　Readme へ記 載 11
12. 4の壁 : テストコードをどう書けば良いか分からない • 実装ガイドラインがあっても、具体的な書き方は イマイチわからないという状態 ◦ 実行を安定させるためのロケータの指定方法 ◦ テストシナリオとアクションの切り分け ある程度テストコードが整備されている状態にする必要があった 12
13. ４の楔 : ナレッジシェア・スキルトランスファーを行う • モチベーションが高めの有志数名でもくもく会を開催 ◦ お互いにコードレビューしてナレッジシェア ◦ 細かい書き方もある程度統一された • 開発メンバーとモブプロを開催 ◦ 複数の開発メンバーが交代しながらドライバーとなって、テスト シナリオからコードを書く一連の作業を行い、 スキルトランスファーしつつ、テストコードを整備 13
14. 5の壁 : テストをどのように運用するのか分からない • 運用において挙がっていた懸念点 ◦ テスト結果を誰が確認するの？ ◦ テストが失敗していたときどうやって確認するの？ ◦ テストの失敗を誰がどのように修正するの？ ◦ テスト追加するときはどうすればいいの？ 14
15. ５の楔 : テスト結果を分かりやすくフィードバック • テスト結果を分かりやすくフィードバック ◦ Slack にテストサマリを通知 • テスト結果のレポートを分かりやすく ◦ Cypress Cloud のテストレポートを利用 ◦ Test Replay 機能で失敗の原因を調査しやすく 誰にでもテスト結果がわかる状態へ 15
16. ５の楔 : 自動テストの運用ガイドラインを策定 • テストの実行方法 • テスト結果をどのように確認するか • テスト失敗時の対応フロー • テスト追加時のフロー • テストコードリファクタ時のフロー 誰にでもテスト実行や 修正時のフローがわかる状態へ 16
17. 直近やっていたこと • テスト自体の信頼性を上げていく活動 ◦ デイリーやリリース後に定期的に実行 ◦ メンテナンスするタイミングを週次で決めて対応 ◦ フレイキーなテストの安定性を向上 徐々に自動テストの目的の通り、OSSやインフラの アップデート時に利用されるようになってきた 17
18. 自動テストの信頼性担保 • 一定期間テストが実行、メンテナンスされない状態が 続いてしまうと起こる問題点 ◦ 失敗の原因がリリース影響によるSUT側の問題か、テスト側の 問題か切り分けが難しい ◦ 切り分けが難しいとメンテナンスに対する障壁が高くなる ◦ メンテナンスされなくなるとテスト自体の結果を誰も信頼できなく なる 定期的な実行でテスト自体をアップデートしたりテストコードを安定化さ せて信頼性を担保する活動が欠かせない 18
19. まとめ • 自動テストの布教 ◦ 自動テストを周囲に布教していくためにナレッジシェアやスキル トランスファーなどの継続的な活動が欠かせない ◦ 誰でも気軽に実行できる仕組み作りは必要 ▪ テスト実行用パイプラインの作成 ▪ テスト用シードデータの準備 19
20. まとめ2 • 自動テストの信頼性担保 ◦ テスト自体の信頼性保つために定期的に自動実行して、 テスト結果を分かりやすくフィードバックする ◦ そしてテスト結果が fail していた時に習慣的にメンテナンスされ るフローを整備することが重要 20