テスト自動化失敗から再挑戦しチームにオーナーシップを委譲した話/STAC2024 macho

Transcript

1. テスト自動化失敗から再挑戦し、
 チームにオーナーシップを委譲した話
 2024/12/07 macho（kyohei kasuya）
 
 ソフトウェアテスト自動化カンファレンス2024
 


2. 自己紹介
 
 macho (kyohei kasuya)
 　　　　　　　　
 ▫ 所属・職種
 株式会社estie(不動産テック)・QAエンジニア
 


   ▫ 経歴
 製造業 → 不動産営業 → QAエンジニア
 2021年にIT業界及びQA未経験で現職に入社。
 担当プロダクトではアジャイル開発チームのメンバー
 として品質保証を主導しながら横断的な品質活動にも挑戦 中。
 
 ▫ 趣味
 筋トレ
 


3. 今回話すこと
 自分の興味関心がきっかけで一人でテスト自動化を進めた結 果、開発チームの運用に乗せることができず失敗した反省を活 かしてもう一度チームを巻き込み自動化に再挑戦した際に行っ た取り組みについて話します。
 
 
 ※ 本セッションでのテスト自動化は主にE2Eレベルのブラウザベースで実施す るリグレッションテストのことを対象としています


   


4. 1. テスト自動化初挑戦🔰
 ◦ ノーコード編
 ◦ Cypress編
 ◦ 失敗編
 2. 失敗からの再挑戦🔥


   3. 再挑戦の結果
 4. 学び
 5. 今後について
 目次


5. 
 その前に...
 
 みなさんの所属する開発チームではE2Eテストの自動化に取 り組んでいますか？
 


6. 　　　　
 QAも自動化も未経験の当時の私...
 
 テスト自動化ってなんかカッコ良い！
 リグレッションテスト毎回自動でやってくれるの？
 すごい！やるしかないっしょ！！


7. • 私の入社した時点で既にイケてるノーコードのテスト自動 化ツールが導入済みだった
 • すぐに始めることができたためそのツールを使って自動化 を進める
 
 その結果...
 1. テスト自動化初挑戦🔰


   
 ノーコード編


8. • 当時の契約内容による制約(主に実行回数制限)で思うよ うに自動化がスケールしない
 • ノーコードとはいえコーディングが必要な場面がちょくちょ くある
 • モチベーション的にせっかくなら１からコードを書きたい
 1. テスト自動化初挑戦🔰


   
 ノーコード編


9. よし、シナリオ数や実行回数制限がない自分でコーディングし てテストが作れるオープンソースの自動化ツールに挑戦して みよう！
 
 よく耳にする「Cypress」ってやつを使ってみるか！
 1. テスト自動化初挑戦🔰
 
 　　　　　　　　　　


10. やったこと
 
 1. ノーコード時代のシナリオをCypressで作り直す
 2. 制約により不足していたメインシナリオを追加
 3. 楽しくなって次々テストシナリオを追加
 
 その結果...


    
 1. テスト自動化初挑戦🔰
 
 Cypress編


11. • テスト作り放題・回し放題！
 • 自分で書いたコードが実行されてテストが動くのテンション 上がる！
 • テストをCIに組み込んだからこれからは楽ができるぞ！
 
 実際運用してみると...
 1.

    テスト自動化初挑戦🔰
 
 Cypress編
 浮かれる私

12. もちろん一筋縄ではいかず次々に見えてくる課題...
 
 • 日々発生するテスト失敗通知の確認
 • 頻発する偽陽性のテスト修正
 • 機能開発による既存テストの修正
 • 新規機能開発時のテスト追加


    
 
 
 1. テスト自動化初挑戦🔰
 
 
 失敗編


13. 
 これ全部一人でやるの厳しいな...
 しのぎつつ、徐々にチームに移譲していこう！
 
 その結果...
 
 
 1. テスト自動化初挑戦🔰
 


    失敗編


14. • 一向に改善しない偽陽性
 • 一向に進まないチームへのオーナーシップ移譲
 • 一向に減らない自動化にかける自分の作業時間
 
 1. テスト自動化初挑戦🔰
 


    失敗編


15. 
 
 と、自動化に消耗してきていたタイミングで転機が！
 1. テスト自動化初挑戦🔰
 
 失敗編


16. 2. 失敗からの再挑戦🔥
 　
 • プロダクトでフロントエンドのリライトが決定
 • 今のテストコードを大幅に修正する必要ができる...
 
 
 


    • 今回の自動化を失敗と認めて１からやり直そう！
 • まずは失敗の原因を振り返ろう！


17. • 一向に改善しない偽陽性 
 • 一向に進まないチームへのオーナーシップ移譲
 • 一向に減らない自動化にかける自分の作業時間
 2. 失敗からの再挑戦🔥
 


    前回の失敗を振り返る（再掲）
 
 1. 一向に改善しない偽陽性
 2. 一向に進まないチームへのオーナーシップ移譲
 3. 一向に減らない自動化にかける自分の作業時間
 


18. 2. 失敗からの再挑戦🔥
 
 　
 「計画性」無しに「一人で」進めたのが原因だと内省
 今回は計画的に早いタイミングからチームを巻き込んで進めよう！


19. 振り返り①
 
 • よく聞くツールだからという安直な理由で選定
 • プロダクトの特性とツール相性が把握できておらず途中で 困りごとが発生する
 • 自分の独断で決定したためみんなでやる感が薄かった
 2.

    失敗からの再挑戦🔥
 
 課題1：一向に改善しない偽陽性


20. 対策：ツールの選定から巻き込む
 
 • いくつかのツールを比較しDesign Docを作成
 • 開発部門に広く意見を募りツールを決定
 
 「部門で合意をとる✨」
 


    2. 失敗からの再挑戦🔥
 
 課題1：一向に改善しない偽陽性


21. 振り返り②
 
 • 片っ端から自動化するぜ！で進めた
 • 一人でシナリオ設計しチームのチェックを依頼せずに実装 を進めた
 • そのためテストが安定する前にシナリオのボリュームをが 増えてFlakyな状態な常態化してしまってた


    2. 失敗からの再挑戦🔥
 
 課題1：一向に改善しない偽陽性


22. 対策：テストボリュームのを増やしすぎないことを意識したテスト設 計
 
 • 重要な機能やケースにシナリオを絞る方針に変更
 ◦ 利用頻度が少ない or 一時的に使えなくなっても困らない機能は自動 化対象から外しテストボリュームを削減


    • チームメンバーと同期レビューを実施
 ◦ PdMのビジネス視点を取り入れ機能ごとの重要度を考慮
 ◦ エンジニアの技術やコード視点でのテストの過不足を考慮
 
 「チームで合意をとる✨」
 2. 失敗からの再挑戦🔥
 
 課題1：一向に改善しない偽陽性


23. 振り返り
 
 • 最終的な運用イメージをチームにしっかり合意を取らない まま進めた
 ◦ QAのリソース的に導入が完了したらチームメンバーに 引き継ぎたかった
 • そのため導入完了後も自分が一人で運用をする流れに


    
 2. 失敗からの再挑戦🔥
 
 課題2：一向に進まないオーナーシップ移譲


24. 対策：最終的な運用イメージを事前にシェア
 
 • 実装前に自分の頭の中の運用イメージを明確にシェア
 ◦ QAが抜けても運用できる状態が理想
 ◦ E2Eテストはみんなの持ち物
 ◦ 日々のテスト追加もテスト修正もみんなでやる


    
 「チームで合意をとる✨」
 
 2. 失敗からの再挑戦🔥
 
 課題2：一向に進まないオーナーシップ移譲


25. 振り返り
 
 • テスト書くの楽しい！で一人で書き進めてしまった
 • その結果、自分以外のメンバーにツールのナレッジ貯まら ずみんなが書ける状態でなかった
 
 2. 失敗からの再挑戦🔥


    
 課題3：一向に減らない自動化にかける自分の作業時間


26. 対策：エンジニアとの作業分担
 
 • 自分が先陣を切りつつそこで貯まったナレッジをもとにコーディングガ イド的なドキュメントを作成
 • 運用開始前から実装チケットをエンジニアにも少しずつ持ってもらい、 運用開始時にメンバーにも一定のナレッジが貯まった状態を作る
 • テストが失敗したら変更を加えた担当がテストを確認するルール


    
 「自分ごととして認識してもらう✨」
 
 
 2. 失敗からの再挑戦🔥
 
 課題3：一向に減らない自動化にかける自分の作業時間


27. 
 
 テストが運用に乗りオーナーシップを
 チームに移譲できた🎉
 
 3. 再挑戦の結果
 
 


28. 
 
 • テストシナリオ追加時のレビュー
 • テスト修正に苦戦していそうなタイミングでのヘルプ
 
 以前よりも自動化に使う時間が減った
 3. 再挑戦の結果


    
 最近私が関与しているタイミングは主にこれだけ
 


29. 機能追加・テスト追加修正後、一時的にテストがFlakyになるタ イミングが発生する
 
 
 
 現状Flakyテストをゼロにすることは現状難しいが、
 テストの失敗にチームが無関心になることは絶対に避けた い！！
 
 3.

    再挑戦の結果
 
 
 とはいえ運用後に問題が起こらなかったわけではなく...


30. • シナリオにPriorityをつけ絶対に落ちてはいけないテスト (P1)とそれ以外に分類
 ◦ P1：絶対に落ちてはいけないシナリオ
 ◦ それ以外：落ちている状態はよくないが厳密にリリース のブロッカーにはしない
 • チームメンバーみんなでそれぞれのシナリオにPriorityを

    つける議論を実施しCIのJob自体も分割
 
 3. 再挑戦の結果
 
 
 とはいえ運用後に問題が起こらなかったわけではなく...
 Flakyテストへの対策


31. その結果...
 
 • Flakyテストが全滅したわけではないが少なくともP1シナリ オの失敗は減った
 • 日々のテスト失敗通知に関心を持ちつつも消耗しない状 態を維持できている
 3. 再挑戦の結果


    
 
 falkyテストへの対応
 Flakyテストへの対策


32. 
 計画性 (無しに) を持って 
 (一人で) みんなで取り組む！
 
 4. 学び


    
 


33. • estieにはたくさんのプロダクトが存在する
 • 一つのプロダクトだけ自動化できていても十分でない
 • チームメンバーで運用ができる状態にすることが大切
 
 
 
 チームメンバーで運用可能なE2Eテストの導入を横展開中


    5. 今後について
 
 　


34. 各チームの負荷を考えスモールスタートにCore User Scenariosを各プロダクト毎に定義し、そのシナリオだけを自 動化しCIに組み込むことを始めている
 
 ※Core User Scenariosとは
 estie社内で定義している「顧客価値につながるプロダクトのコアとなるような 機能」を軸に作成したシナリオグループを指します


    5. 今後について
 
 この導入〜権限委譲を横展開していく
 


35. 　
 
 
 
 気軽にカジュアル面談しましょう！ https://hrmos.co/pages/estie/jobs/991001_casual_interview ご清聴ありがとうございました！
 
 macho (kyohei

    kasuya)