Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
E2E 自動テストの布教に立ち塞がる5つの壁と打ち込んだ楔
Search
ShooU
March 26, 2024
Technology
0
200
E2E 自動テストの布教に立ち塞がる5つの壁と打ち込んだ楔
ShooU
March 26, 2024
Tweet
Share
More Decks by ShooU
See All by ShooU
AI系E2Eテストツール導入後に広がる景色
shoou
0
3.2k
Azure Pipelines 触ってみた
shoou
0
250
Other Decks in Technology
See All in Technology
OPENLOGI Company Profile for engineer
hr01
1
34k
What’s new in Android development tools
yanzm
0
320
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
960
Sansanのデータプロダクトマネジメントのアプローチ
sansantech
PRO
0
160
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
210
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
2
7.8k
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
190
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
3
22k
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
3
9.5k
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
2
150
KubeCon + CloudNativeCon Japan 2025 Recap
ren510dev
1
390
Yahoo!しごとカタログ 新しい境地を創るエンジニア募集!
lycorptech_jp
PRO
0
120
Featured
See All Featured
KATA
mclloyd
30
14k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
510
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Code Review Best Practice
trishagee
69
18k
Agile that works and the tools we love
rasmusluckow
329
21k
Practical Orchestrator
shlominoach
189
11k
Site-Speed That Sticks
csswizardry
10
690
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
970
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
6
300
Transcript
E2E 自動テストの布教に 立ち塞がる5つの壁と 打ち込んだ楔 2024/03/26 株式会社 Magic Moment 矢野 崇
1
背景 • ちょうど一年ほど前に一人目 QAE として join (2023/03/15) • 会社ではE2E 自動テスト
(以後「自動テスト」と表記)の 導入をはじめていたタイミング ◦ 週1~2時間ほどで有志メンバーがテストコード作成中 ◦ 使用ツールは Cypress ◦ 実運用まではできていない状態 • 開発メンバーが主体となって自動テストの運用を できるように仕組みを整えはじめた 2
背景2 • 去年末にこれまでの振り返りを兼ねて 弊社アドベントカレンダーの1記事として掲載 ◦ E2E 自動テストの布教に立ち塞がる5つの壁と打ち込んだ楔 • 記事の内容の説明 +
年明けからやってきたことを話します ◦ 自動テストを布教する上での学びや気づきをシェア 3
なぜ布教をしていたのか • 一人だけの QAE が自動テストの作成とメンテナンスを行うことは限 界がある • 仮に自動テストは整備できたとしても他のQA活動にリソースを使えな くなってしまう懸念 •
一人の熱量で自動テストを進めてもいずれはシェルフウェアとなって 破綻しがち 開発メンバーが主体となって自動テストを運用できる必要があった 4
どのようなプロダクトの自動テストを書いているか Magic Moment Playbook (MMP) 5
1の壁 : 何のための自動テストか分からない • 特定のメンバーの熱量だけで推し進めていくとありがちな風景 ◦ 「なんだか流行っているみたいだし自動テストがあったほうがい いよね?」 ◦ 「アジャイル開発ではなんだか必要みたいだから、よくわからな
いけどやらないと!」 ◦ 「なんでこんな大変な思いまでして自動テストするの?」 いずれメンテナンスも実行もされない自動テストへ、、、 6
1の楔 : 自動テストの目的を定める • 自動テストのメンテナンスや整備をするメリットを考える ◦ OSSアップデートを気軽にできるようにする ◦ インフラのアップデートを気軽にできるようにする ◦
リリース後の動作確認作業の負担を減らす ◦ 人が実施するテストの前に自動テストで動作保証 ... ect 目的を定めればなぜ自動テストを整備しているか説明できるし、どのよ うなテストが必要か不要かも判断できるようになる 7
2の壁:どのような自動テストを作成したら良いか分からない • 目的だけ定めてもいきなり具体的なテストコードは書けない • 具体的にどのようなテストが自動実行されれば良いかのイメージが 統一されていない状態 テストコードを書く前に具体的にどのような操作をするのか 明確なテストシナリオのドキュメントが必要となった 8
2の楔 : テストシナリオを自動化の前に作成する • プロダクトにおけるクリティカルユーザージャーニー (CUJ) は何かを ヒアリングし、テストシナリオを作成 • テストシナリオは
Notion 上に日本語で書いて管理 • Arrange-Act-Assert (AAA) パターンに沿って、テストの前提条件、 操作、アサーションを分かりやすく記述 9
3の壁 : デザインパターンが分からない • 自動テストのデザインパターンを知っている人が社内にいない • テストコードをデザインパターンで抽象化、構造化する メリットが実際に自動テストを運用した人にしか分かりにくい • キャプチャ&リプレイからエクスポートしたもの、サンプルコードでは
大抵リニアスクリプトで書かれている メンテナンス性と可読性の高いテストコードを実装できるように デザインパターンとディレクトリ構成を決める必要があった 10
3の楔 : デザインパターンを決める • 実装ガイドラインを策定し、Cypress ディレクトリの Readme へ記 載 11
4の壁 : テストコードをどう書けば良いか分からない • 実装ガイドラインがあっても、具体的な書き方は イマイチわからないという状態 ◦ 実行を安定させるためのロケータの指定方法 ◦ テストシナリオとアクションの切り分け
ある程度テストコードが整備されている状態にする必要があった 12
4の楔 : ナレッジシェア・スキルトランスファーを行う • モチベーションが高めの有志数名でもくもく会を開催 ◦ お互いにコードレビューしてナレッジシェア ◦ 細かい書き方もある程度統一された •
開発メンバーとモブプロを開催 ◦ 複数の開発メンバーが交代しながらドライバーとなって、テスト シナリオからコードを書く一連の作業を行い、 スキルトランスファーしつつ、テストコードを整備 13
5の壁 : テストをどのように運用するのか分からない • 運用において挙がっていた懸念点 ◦ テスト結果を誰が確認するの? ◦ テストが失敗していたときどうやって確認するの? ◦
テストの失敗を誰がどのように修正するの? ◦ テスト追加するときはどうすればいいの? 14
5の楔 : テスト結果を分かりやすくフィードバック • テスト結果を分かりやすくフィードバック ◦ Slack にテストサマリを通知 • テスト結果のレポートを分かりやすく
◦ Cypress Cloud のテストレポートを利用 ◦ Test Replay 機能で失敗の原因を調査しやすく 誰にでもテスト結果がわかる状態へ 15
5の楔 : 自動テストの運用ガイドラインを策定 • テストの実行方法 • テスト結果をどのように確認するか • テスト失敗時の対応フロー •
テスト追加時のフロー • テストコードリファクタ時のフロー 誰にでもテスト実行や 修正時のフローがわかる状態へ 16
直近やっていたこと • テスト自体の信頼性を上げていく活動 ◦ デイリーやリリース後に定期的に実行 ◦ メンテナンスするタイミングを週次で決めて対応 ◦ フレイキーなテストの安定性を向上 徐々に自動テストの目的の通り、OSSやインフラの
アップデート時に利用されるようになってきた 17
自動テストの信頼性担保 • 一定期間テストが実行、メンテナンスされない状態が 続いてしまうと起こる問題点 ◦ 失敗の原因がリリース影響によるSUT側の問題か、テスト側の 問題か切り分けが難しい ◦ 切り分けが難しいとメンテナンスに対する障壁が高くなる ◦
メンテナンスされなくなるとテスト自体の結果を誰も信頼できなく なる 定期的な実行でテスト自体をアップデートしたりテストコードを安定化さ せて信頼性を担保する活動が欠かせない 18
まとめ • 自動テストの布教 ◦ 自動テストを周囲に布教していくためにナレッジシェアやスキル トランスファーなどの継続的な活動が欠かせない ◦ 誰でも気軽に実行できる仕組み作りは必要 ▪ テスト実行用パイプラインの作成
▪ テスト用シードデータの準備 19
まとめ2 • 自動テストの信頼性担保 ◦ テスト自体の信頼性保つために定期的に自動実行して、 テスト結果を分かりやすくフィードバックする ◦ そしてテスト結果が fail していた時に習慣的にメンテナンスされ
るフローを整備することが重要 20