Slide 1
Slide 1 text
テスト自動化失敗から再挑戦し、
チームにオーナーシップを委譲した話
2024/12/07 macho（kyohei kasuya）
ソフトウェアテスト自動化カンファレンス2024
Slide 2
Slide 2 text
自己紹介
macho (kyohei kasuya)
▫ 所属・職種
株式会社estie(不動産テック)・QAエンジニア
▫ 経歴
製造業 → 不動産営業 → QAエンジニア
2021年にIT業界及びQA未経験で現職に入社。
担当プロダクトではアジャイル開発チームのメンバー
として品質保証を主導しながら横断的な品質活動にも挑戦
中。
▫ 趣味
筋トレ
Slide 3
Slide 3 text
今回話すこと
自分の興味関心がきっかけで一人でテスト自動化を進めた結
果、開発チームの運用に乗せることができず失敗した反省を活
かしてもう一度チームを巻き込み自動化に再挑戦した際に行っ
た取り組みについて話します。
※ 本セッションでのテスト自動化は主にE2Eレベルのブラウザベースで実施す
るリグレッションテストのことを対象としています
Slide 4
Slide 4 text
1. テスト自動化初挑戦🔰
○ ノーコード編
○ Cypress編
○ 失敗編
2. 失敗からの再挑戦🔥
3. 再挑戦の結果
4. 学び
5. 今後について
目次
Slide 5
Slide 5 text
その前に...
みなさんの所属する開発チームではE2Eテストの自動化に取
り組んでいますか？
Slide 6
Slide 6 text
QAも自動化も未経験の当時の私...
テスト自動化ってなんかカッコ良い！
リグレッションテスト毎回自動でやってくれるの？
すごい！やるしかないっしょ！！
Slide 7
Slide 7 text
● 私の入社した時点で既にイケてるノーコードのテスト自動
化ツールが導入済みだった
● すぐに始めることができたためそのツールを使って自動化
を進める
その結果...
1. テスト自動化初挑戦🔰
ノーコード編
Slide 8
Slide 8 text
● 当時の契約内容による制約(主に実行回数制限)で思うよ
うに自動化がスケールしない
● ノーコードとはいえコーディングが必要な場面がちょくちょ
くある
● モチベーション的にせっかくなら１からコードを書きたい
1. テスト自動化初挑戦🔰
ノーコード編
Slide 9
Slide 9 text
よし、シナリオ数や実行回数制限がない自分でコーディングし
てテストが作れるオープンソースの自動化ツールに挑戦して
みよう！
よく耳にする「Cypress」ってやつを使ってみるか！
1. テスト自動化初挑戦🔰
Slide 10
Slide 10 text
やったこと
1. ノーコード時代のシナリオをCypressで作り直す
2. 制約により不足していたメインシナリオを追加
3. 楽しくなって次々テストシナリオを追加
その結果...
1. テスト自動化初挑戦🔰
Cypress編
Slide 11
Slide 11 text
● テスト作り放題・回し放題！
● 自分で書いたコードが実行されてテストが動くのテンション
上がる！
● テストをCIに組み込んだからこれからは楽ができるぞ！
実際運用してみると...
1. テスト自動化初挑戦🔰
Cypress編
浮かれる私
Slide 12
Slide 12 text
もちろん一筋縄ではいかず次々に見えてくる課題...
● 日々発生するテスト失敗通知の確認
● 頻発する偽陽性のテスト修正
● 機能開発による既存テストの修正
● 新規機能開発時のテスト追加
1. テスト自動化初挑戦🔰
失敗編
Slide 13
Slide 13 text
これ全部一人でやるの厳しいな...
しのぎつつ、徐々にチームに移譲していこう！
その結果...
1. テスト自動化初挑戦🔰
失敗編
Slide 14
Slide 14 text
● 一向に改善しない偽陽性
● 一向に進まないチームへのオーナーシップ移譲
● 一向に減らない自動化にかける自分の作業時間
1. テスト自動化初挑戦🔰
失敗編
Slide 15
Slide 15 text
と、自動化に消耗してきていたタイミングで転機が！
1. テスト自動化初挑戦🔰
失敗編
Slide 16
Slide 16 text
2. 失敗からの再挑戦🔥
● プロダクトでフロントエンドのリライトが決定
● 今のテストコードを大幅に修正する必要ができる...
● 今回の自動化を失敗と認めて１からやり直そう！
● まずは失敗の原因を振り返ろう！
Slide 17
Slide 17 text
● 一向に改善しない偽陽性
● 一向に進まないチームへのオーナーシップ移譲
● 一向に減らない自動化にかける自分の作業時間
2. 失敗からの再挑戦🔥
前回の失敗を振り返る（再掲）
1. 一向に改善しない偽陽性
2. 一向に進まないチームへのオーナーシップ移譲
3. 一向に減らない自動化にかける自分の作業時間
Slide 18
Slide 18 text
2. 失敗からの再挑戦🔥
「計画性」無しに「一人で」進めたのが原因だと内省
今回は計画的に早いタイミングからチームを巻き込んで進めよう！
Slide 19
Slide 19 text
振り返り①
● よく聞くツールだからという安直な理由で選定
● プロダクトの特性とツール相性が把握できておらず途中で
困りごとが発生する
● 自分の独断で決定したためみんなでやる感が薄かった
2. 失敗からの再挑戦🔥
課題1：一向に改善しない偽陽性
Slide 20
Slide 20 text
対策：ツールの選定から巻き込む
● いくつかのツールを比較しDesign Docを作成
● 開発部門に広く意見を募りツールを決定
「部門で合意をとる✨」
2. 失敗からの再挑戦🔥
課題1：一向に改善しない偽陽性
Slide 21
Slide 21 text
振り返り②
● 片っ端から自動化するぜ！で進めた
● 一人でシナリオ設計しチームのチェックを依頼せずに実装
を進めた
● そのためテストが安定する前にシナリオのボリュームをが
増えてFlakyな状態な常態化してしまってた
2. 失敗からの再挑戦🔥
課題1：一向に改善しない偽陽性
Slide 22
Slide 22 text
対策：テストボリュームのを増やしすぎないことを意識したテスト設
計
● 重要な機能やケースにシナリオを絞る方針に変更
○ 利用頻度が少ない or 一時的に使えなくなっても困らない機能は自動
化対象から外しテストボリュームを削減
● チームメンバーと同期レビューを実施
○ PdMのビジネス視点を取り入れ機能ごとの重要度を考慮
○ エンジニアの技術やコード視点でのテストの過不足を考慮
「チームで合意をとる✨」
2. 失敗からの再挑戦🔥
課題1：一向に改善しない偽陽性
Slide 23
Slide 23 text
振り返り
● 最終的な運用イメージをチームにしっかり合意を取らない
まま進めた
○ QAのリソース的に導入が完了したらチームメンバーに
引き継ぎたかった
● そのため導入完了後も自分が一人で運用をする流れに
2. 失敗からの再挑戦🔥
課題2：一向に進まないオーナーシップ移譲
Slide 24
Slide 24 text
対策：最終的な運用イメージを事前にシェア
● 実装前に自分の頭の中の運用イメージを明確にシェア
○ QAが抜けても運用できる状態が理想
○ E2Eテストはみんなの持ち物
○ 日々のテスト追加もテスト修正もみんなでやる
「チームで合意をとる✨」
2. 失敗からの再挑戦🔥
課題2：一向に進まないオーナーシップ移譲
Slide 25
Slide 25 text
振り返り
● テスト書くの楽しい！で一人で書き進めてしまった
● その結果、自分以外のメンバーにツールのナレッジ貯まら
ずみんなが書ける状態でなかった
2. 失敗からの再挑戦🔥
課題3：一向に減らない自動化にかける自分の作業時間
Slide 26
Slide 26 text
対策：エンジニアとの作業分担
● 自分が先陣を切りつつそこで貯まったナレッジをもとにコーディングガ
イド的なドキュメントを作成
● 運用開始前から実装チケットをエンジニアにも少しずつ持ってもらい、
運用開始時にメンバーにも一定のナレッジが貯まった状態を作る
● テストが失敗したら変更を加えた担当がテストを確認するルール
「自分ごととして認識してもらう✨」
2. 失敗からの再挑戦🔥
課題3：一向に減らない自動化にかける自分の作業時間
Slide 27
Slide 27 text
テストが運用に乗りオーナーシップを
チームに移譲できた🎉
3. 再挑戦の結果
Slide 28
Slide 28 text
● テストシナリオ追加時のレビュー
● テスト修正に苦戦していそうなタイミングでのヘルプ
以前よりも自動化に使う時間が減った
3. 再挑戦の結果
最近私が関与しているタイミングは主にこれだけ
Slide 29
Slide 29 text
機能追加・テスト追加修正後、一時的にテストがFlakyになるタ
イミングが発生する
現状Flakyテストをゼロにすることは現状難しいが、
テストの失敗にチームが無関心になることは絶対に避けた
い！！
3. 再挑戦の結果
とはいえ運用後に問題が起こらなかったわけではなく...
Slide 30
Slide 30 text
● シナリオにPriorityをつけ絶対に落ちてはいけないテスト
(P1)とそれ以外に分類
○ P1：絶対に落ちてはいけないシナリオ
○ それ以外：落ちている状態はよくないが厳密にリリース
のブロッカーにはしない
● チームメンバーみんなでそれぞれのシナリオにPriorityを
つける議論を実施しCIのJob自体も分割
3. 再挑戦の結果
とはいえ運用後に問題が起こらなかったわけではなく...
Flakyテストへの対策
Slide 31
Slide 31 text
その結果...
● Flakyテストが全滅したわけではないが少なくともP1シナリ
オの失敗は減った
● 日々のテスト失敗通知に関心を持ちつつも消耗しない状
態を維持できている
3. 再挑戦の結果
falkyテストへの対応
Flakyテストへの対策
Slide 32
Slide 32 text
計画性 (無しに) を持って
(一人で) みんなで取り組む！
4. 学び
Slide 33
Slide 33 text
● estieにはたくさんのプロダクトが存在する
● 一つのプロダクトだけ自動化できていても十分でない
● チームメンバーで運用ができる状態にすることが大切
チームメンバーで運用可能なE2Eテストの導入を横展開中
5. 今後について
Slide 34
Slide 34 text
各チームの負荷を考えスモールスタートにCore User
Scenariosを各プロダクト毎に定義し、そのシナリオだけを自
動化しCIに組み込むことを始めている
※Core User Scenariosとは
estie社内で定義している「顧客価値につながるプロダクトのコアとなるような
機能」を軸に作成したシナリオグループを指します
5. 今後について
この導入〜権限委譲を横展開していく
Slide 35
Slide 35 text
気軽にカジュアル面談しましょう！
https://hrmos.co/pages/estie/jobs/991001_casual_interview
ご清聴ありがとうございました！
macho (kyohei kasuya)