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
テスト自動化失敗から再挑戦しチームにオーナーシップを委譲した話/STAC2024 macho
Search
macho
December 07, 2024
Programming
1
1.5k
テスト自動化失敗から再挑戦しチームにオーナーシップを委譲した話/STAC2024 macho
macho
December 07, 2024
Tweet
Share
More Decks by macho
See All by macho
Core User Scenarios
ma_cho29
0
49
Other Decks in Programming
See All in Programming
サーバーゆる勉強会 DBMS の仕組み編
kj455
1
290
20241217 競争力強化とビジネス価値創出への挑戦:モノタロウのシステムモダナイズ、開発組織の進化と今後の展望
monotaro
PRO
0
260
Go の GC の不得意な部分を克服したい
taiyow
3
1k
Асинхронность неизбежна: как мы проектировали сервис уведомлений
lamodatech
0
1.3k
オニオンアーキテクチャを使って、 Unityと.NETでコードを共有する
soi013
0
360
Swiftコンパイラ超入門+async関数の仕組み
shiz
0
160
return文におけるstd::moveについて
onihusube
1
1.4k
.NETでOBS Studio操作してみたけど…… / Operating OBS Studio by .NET
skasweb
0
120
混沌とした例外処理とエラー監視に秩序をもたらす
morihirok
9
1.4k
php-conference-japan-2024
tasuku43
0
420
Stackless и stackful? Корутины и асинхронность в Go
lamodatech
0
1.3k
歴史と現在から考えるスケーラブルなソフトウェア開発のプラクティス
i10416
0
290
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
67
4.5k
RailsConf 2023
tenderlove
29
970
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2.1k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Designing for humans not robots
tammielis
250
25k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Transcript
テスト自動化失敗から再挑戦し、 チームにオーナーシップを委譲した話 2024/12/07 macho(kyohei kasuya) ソフトウェアテスト自動化カンファレンス2024
自己紹介 macho (kyohei kasuya) ▫ 所属・職種 株式会社estie(不動産テック)・QAエンジニア
▫ 経歴 製造業 → 不動産営業 → QAエンジニア 2021年にIT業界及びQA未経験で現職に入社。 担当プロダクトではアジャイル開発チームのメンバー として品質保証を主導しながら横断的な品質活動にも挑戦 中。 ▫ 趣味 筋トレ
今回話すこと 自分の興味関心がきっかけで一人でテスト自動化を進めた結 果、開発チームの運用に乗せることができず失敗した反省を活 かしてもう一度チームを巻き込み自動化に再挑戦した際に行っ た取り組みについて話します。 ※ 本セッションでのテスト自動化は主にE2Eレベルのブラウザベースで実施す るリグレッションテストのことを対象としています
1. テスト自動化初挑戦🔰 ◦ ノーコード編 ◦ Cypress編 ◦ 失敗編 2. 失敗からの再挑戦🔥
3. 再挑戦の結果 4. 学び 5. 今後について 目次
その前に... みなさんの所属する開発チームではE2Eテストの自動化に取 り組んでいますか?
QAも自動化も未経験の当時の私... テスト自動化ってなんかカッコ良い! リグレッションテスト毎回自動でやってくれるの? すごい!やるしかないっしょ!!
• 私の入社した時点で既にイケてるノーコードのテスト自動 化ツールが導入済みだった • すぐに始めることができたためそのツールを使って自動化 を進める その結果... 1. テスト自動化初挑戦🔰
ノーコード編
• 当時の契約内容による制約(主に実行回数制限)で思うよ うに自動化がスケールしない • ノーコードとはいえコーディングが必要な場面がちょくちょ くある • モチベーション的にせっかくなら1からコードを書きたい 1. テスト自動化初挑戦🔰
ノーコード編
よし、シナリオ数や実行回数制限がない自分でコーディングし てテストが作れるオープンソースの自動化ツールに挑戦して みよう! よく耳にする「Cypress」ってやつを使ってみるか! 1. テスト自動化初挑戦🔰
やったこと 1. ノーコード時代のシナリオをCypressで作り直す 2. 制約により不足していたメインシナリオを追加 3. 楽しくなって次々テストシナリオを追加 その結果...
1. テスト自動化初挑戦🔰 Cypress編
• テスト作り放題・回し放題! • 自分で書いたコードが実行されてテストが動くのテンション 上がる! • テストをCIに組み込んだからこれからは楽ができるぞ! 実際運用してみると... 1.
テスト自動化初挑戦🔰 Cypress編 浮かれる私
もちろん一筋縄ではいかず次々に見えてくる課題... • 日々発生するテスト失敗通知の確認 • 頻発する偽陽性のテスト修正 • 機能開発による既存テストの修正 • 新規機能開発時のテスト追加
1. テスト自動化初挑戦🔰 失敗編
これ全部一人でやるの厳しいな... しのぎつつ、徐々にチームに移譲していこう! その結果... 1. テスト自動化初挑戦🔰
失敗編
• 一向に改善しない偽陽性 • 一向に進まないチームへのオーナーシップ移譲 • 一向に減らない自動化にかける自分の作業時間 1. テスト自動化初挑戦🔰
失敗編
と、自動化に消耗してきていたタイミングで転機が! 1. テスト自動化初挑戦🔰 失敗編
2. 失敗からの再挑戦🔥 • プロダクトでフロントエンドのリライトが決定 • 今のテストコードを大幅に修正する必要ができる...
• 今回の自動化を失敗と認めて1からやり直そう! • まずは失敗の原因を振り返ろう!
• 一向に改善しない偽陽性 • 一向に進まないチームへのオーナーシップ移譲 • 一向に減らない自動化にかける自分の作業時間 2. 失敗からの再挑戦🔥
前回の失敗を振り返る(再掲) 1. 一向に改善しない偽陽性 2. 一向に進まないチームへのオーナーシップ移譲 3. 一向に減らない自動化にかける自分の作業時間
2. 失敗からの再挑戦🔥 「計画性」無しに「一人で」進めたのが原因だと内省 今回は計画的に早いタイミングからチームを巻き込んで進めよう!
振り返り① • よく聞くツールだからという安直な理由で選定 • プロダクトの特性とツール相性が把握できておらず途中で 困りごとが発生する • 自分の独断で決定したためみんなでやる感が薄かった 2.
失敗からの再挑戦🔥 課題1:一向に改善しない偽陽性
対策:ツールの選定から巻き込む • いくつかのツールを比較しDesign Docを作成 • 開発部門に広く意見を募りツールを決定 「部門で合意をとる✨」
2. 失敗からの再挑戦🔥 課題1:一向に改善しない偽陽性
振り返り② • 片っ端から自動化するぜ!で進めた • 一人でシナリオ設計しチームのチェックを依頼せずに実装 を進めた • そのためテストが安定する前にシナリオのボリュームをが 増えてFlakyな状態な常態化してしまってた
2. 失敗からの再挑戦🔥 課題1:一向に改善しない偽陽性
対策:テストボリュームのを増やしすぎないことを意識したテスト設 計 • 重要な機能やケースにシナリオを絞る方針に変更 ◦ 利用頻度が少ない or 一時的に使えなくなっても困らない機能は自動 化対象から外しテストボリュームを削減
• チームメンバーと同期レビューを実施 ◦ PdMのビジネス視点を取り入れ機能ごとの重要度を考慮 ◦ エンジニアの技術やコード視点でのテストの過不足を考慮 「チームで合意をとる✨」 2. 失敗からの再挑戦🔥 課題1:一向に改善しない偽陽性
振り返り • 最終的な運用イメージをチームにしっかり合意を取らない まま進めた ◦ QAのリソース的に導入が完了したらチームメンバーに 引き継ぎたかった • そのため導入完了後も自分が一人で運用をする流れに
2. 失敗からの再挑戦🔥 課題2:一向に進まないオーナーシップ移譲
対策:最終的な運用イメージを事前にシェア • 実装前に自分の頭の中の運用イメージを明確にシェア ◦ QAが抜けても運用できる状態が理想 ◦ E2Eテストはみんなの持ち物 ◦ 日々のテスト追加もテスト修正もみんなでやる
「チームで合意をとる✨」 2. 失敗からの再挑戦🔥 課題2:一向に進まないオーナーシップ移譲
振り返り • テスト書くの楽しい!で一人で書き進めてしまった • その結果、自分以外のメンバーにツールのナレッジ貯まら ずみんなが書ける状態でなかった 2. 失敗からの再挑戦🔥
課題3:一向に減らない自動化にかける自分の作業時間
対策:エンジニアとの作業分担 • 自分が先陣を切りつつそこで貯まったナレッジをもとにコーディングガ イド的なドキュメントを作成 • 運用開始前から実装チケットをエンジニアにも少しずつ持ってもらい、 運用開始時にメンバーにも一定のナレッジが貯まった状態を作る • テストが失敗したら変更を加えた担当がテストを確認するルール
「自分ごととして認識してもらう✨」 2. 失敗からの再挑戦🔥 課題3:一向に減らない自動化にかける自分の作業時間
テストが運用に乗りオーナーシップを チームに移譲できた🎉 3. 再挑戦の結果
• テストシナリオ追加時のレビュー • テスト修正に苦戦していそうなタイミングでのヘルプ 以前よりも自動化に使う時間が減った 3. 再挑戦の結果
最近私が関与しているタイミングは主にこれだけ
機能追加・テスト追加修正後、一時的にテストがFlakyになるタ イミングが発生する 現状Flakyテストをゼロにすることは現状難しいが、 テストの失敗にチームが無関心になることは絶対に避けた い!! 3.
再挑戦の結果 とはいえ運用後に問題が起こらなかったわけではなく...
• シナリオにPriorityをつけ絶対に落ちてはいけないテスト (P1)とそれ以外に分類 ◦ P1:絶対に落ちてはいけないシナリオ ◦ それ以外:落ちている状態はよくないが厳密にリリース のブロッカーにはしない • チームメンバーみんなでそれぞれのシナリオにPriorityを
つける議論を実施しCIのJob自体も分割 3. 再挑戦の結果 とはいえ運用後に問題が起こらなかったわけではなく... Flakyテストへの対策
その結果... • Flakyテストが全滅したわけではないが少なくともP1シナリ オの失敗は減った • 日々のテスト失敗通知に関心を持ちつつも消耗しない状 態を維持できている 3. 再挑戦の結果
falkyテストへの対応 Flakyテストへの対策
計画性 (無しに) を持って (一人で) みんなで取り組む! 4. 学び
• estieにはたくさんのプロダクトが存在する • 一つのプロダクトだけ自動化できていても十分でない • チームメンバーで運用ができる状態にすることが大切 チームメンバーで運用可能なE2Eテストの導入を横展開中
5. 今後について
各チームの負荷を考えスモールスタートにCore User Scenariosを各プロダクト毎に定義し、そのシナリオだけを自 動化しCIに組み込むことを始めている ※Core User Scenariosとは estie社内で定義している「顧客価値につながるプロダクトのコアとなるような 機能」を軸に作成したシナリオグループを指します
5. 今後について この導入〜権限委譲を横展開していく
気軽にカジュアル面談しましょう! https://hrmos.co/pages/estie/jobs/991001_casual_interview ご清聴ありがとうございました! macho (kyohei
kasuya)