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
210
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
260
Other Decks in Technology
See All in Technology
モダンな現場と従来型の組織——そこに生じる "不整合" を解消してこそチームがパフォーマンスを発揮できる / Team-oriented Organization Design 20250825
mtx2s
5
530
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
1
180
[CVPR2025論文読み会] Linguistics-aware Masked Image Modelingfor Self-supervised Scene Text Recognition
s_aiueo32
0
210
実践アプリケーション設計 ①データモデルとドメインモデル
recruitengineers
PRO
2
220
LLMエージェント時代に適応した開発フロー
hiragram
1
410
Amazon Bedrock AgentCore でプロモーション用動画生成エージェントを開発する
nasuvitz
6
420
Understanding Go GC #coefl_go_jp
bengo4com
0
1.1k
「守る」から「進化させる」セキュリティへ ~AWS re:Inforce 2025参加報告~ / AWS re:Inforce 2025 Participation Report
yuj1osm
1
120
事業価値と Engineering
recruitengineers
PRO
1
200
新規案件の立ち上げ専門チームから見たAI駆動開発の始め方
shuyakinjo
0
110
Android Studio の 新しいAI機能を試してみよう / Try out the new AI features in Android Studio
yanzm
0
270
マイクロモビリティシェアサービスを支える プラットフォームアーキテクチャ
grimoh
1
200
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
[RailsConf 2023] Rails as a piece of cake
palkan
56
5.8k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Optimizing for Happiness
mojombo
379
70k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
The Cult of Friendly URLs
andyhume
79
6.5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.4k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
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