自動テストのコストと向き合ってみた

2025年10月7日 LAPRAS社主催「QA LT Night」登壇資料
登壇者：豊島

connpass
https://lapras.connpass.com/event/368463/

Transcript

1. © SmartHR, Inc. ⾃動テストの コストと向き合ってみた 豊島 誠之 SmartHR 技術統括本部 品質保証本部 タレントマネジメントユニット 2025/10/7 QA LT Night 〜品質を追求するプロたちの集い〜 画像を置換
2. 豊島 誠之(toyosea) 経歴 • 事業会社でのフロントエンドエンジニアやOpsのキャリアを経て、 QAエンジニアへキャリアチェンジ • 2025年3⽉にSmartHR⼊社後、タレントマネジメント領域のプロダ クトのQAを担当しており、現在はチームメンバーのSETスキルの底 上げにも取り組んでいる。 • 趣味で⾳楽を作ってます。Apple MusicやSpotifyで「toyosea」と 検索してみてください ⾃⼰紹介
3. 本⽇のテーマ • 「⾃動テストを増やすとコストが上がる、 でもバグの混⼊のリスクは抑えたい...!」 • 「この両者のバランスを良い感じにするに はどうすればよいのか？」 3
6. タレントマネジメントユニットとは 特徴 • 実働4名体制 (チーフ1名 + メンバー3名) • 1名ずつ1~2個のプロダクトに関わる • QAとしての関わり⽅はプロダクトの品質課題によって変えていきま す 6
7. タレントマネジメントユニットとは （宣伝）ユニットのチームビルディング施策のブログ 7
8. 本⽇お話すること 1. 問い 2. 現状分析 3. 戦略 4. 実践 5. 成果 6. まとめ
9. 問い
10. • 「⾃動テストを増やすとコストが上がる、 でもバグの混⼊のリスクは抑えたい...!」 • 「この両者のバランスを良い感じにするに はどうすればよいのか？」 問い 10
11. 問い 11 ⽤語のすりあわせ • ⾃動テストとは ◦ E2Eテストだけを指しません ◦ Unit, Integration, E2Eテストを包括した前提で 話します
12. 問い 12 ⽤語のすりあわせ • コストとは ◦ ⾃動テストのメンテナンスコスト ◦ CIのクレジット消費量の⾦銭的なコスト
13. 現状分析 13 和⽥卓⼈⽒ 「テストサイズで再考する「テストピラミッド」 Googleが提唱する効率的な⾃動テスト戦略」より引⽤
14. 問い 14 技術スタックのすりあわせ • ⾔語‧サービス ◦ Backend: RSpec ◦ Frontend: vitest, Storybook ◦ E2E: Playwright, System Spec ◦ CI: CircleCI
15. 現状分析
16. 現状分析 16 担当プロダクト • ⾃動テスト（Unit） ▪ Backend • 指定した閾値までカバレッジが達しているかをチェックするCI のジョブがあり、カバレッジは⾼く保てている状況 ▪ Frontend • Formatterなどの共通で使う関数で単体テストが書かれている 状況 • ビジネスロジックに関する単体テストはあまり書かれていない 状況
17. 現状分析 17 担当プロダクト • ⾃動テスト（Integration） ◦ Backend ▪ APIテストも指定した閾値にカバレッジが達しているかを チェックするCIのジョブがあり、カバレッジは⾼く保ててい る状況 ◦ Frontend ▪ Storybookでのコンポーネントテストやヴィジュアルリグレッ ションテストが書かれている状況
18. 現状分析 18 担当プロダクト • ⾃動テスト（E2E） ◦ 主要機能のCRUD操作や⼀部イレギュラーな操作のテス トが書かれている状況 ◦ PlaywrightとRailsのSystem Specが混在している状況 ◦ Flakyテストが多くなりテストの信頼性が落ちている状 況
19. 現状分析 19 担当プロダクト • コスト ◦ CI ▪ 作業ブランチにPushするたびにCIでE2Eテストが実⾏されて いた ▪ SmartHRの多数のプロダクトの中で2番⽬にクレジット消費量 が多くなっていた ▪ E2EのFlakyテストが放置されたままの状況になっていた • メンテナンスコストが多くなり⼿に負えなくなっていた • 「テストが落ちているけどきっと⼤丈夫だろう」という状況 • CIのSuccess Rate (成功率) は70%前後だった
20. 現状分析 20 まとめ • Unit, Integrationレベルのコストに関する課題はなさそう ◦ ただし⾃動テストとしてFrontendのビジネスロジックに関する単体 テストが不⾜している課題はある • E2Eテストの数はあるがテスト結果の信頼性が低い状態の ためテストの意味が損なわれつつある • テストの意味が損なわれつつあるにも関わらず、CIのクレ ジット消費量にコストがかかっている状況
21. 現状分析 21 このままだとどうなってしまう？ • E2Eテストの信頼性が低いまま運⽤されてしまう • ⾃動テストによる恩恵を最⼤限受けられないままCI の⾦銭的なコストを払い続けることになる
22. 戦略
23. 戦略 23 ⾃動テスト • E2Eテストを作りすぎない ◦ 新規機能に関して⾃動テスト戦略を⽴てる ◦ Critical User Journey相当のテストに絞る • E2E → Integration, Unitテストにサイズダウンできるものは移⾏す る • E2Eテストの信頼性の回復 ◦ Flakyテストの削減 ※Critical User Journey ビジネスの観点から重要とされる部分にフォーカスしたカスタマージャーニーのこと
24. 戦略 24 コスト • テスト実⾏タイミングの⾒直し ◦ 作業ブランチにPushするたびにE2Eテストを実⾏ しなきゃダメなんだっけ？という問い
25. 実践
26. 実践 1. E2Eテストを作りすぎない • ⾃動テスト戦略を⽴てる ◦ 新規機能開発時に⽴案 ◦ テストレベルごとになにを守るか？の⾔語化 26
27. 実践 1. E2Eテストを作りすぎない • テストレベルごとになにを守るか？の例（Unitテスト） ◦ RSpec ▪ 〇〇機能の計算処理 ▪ 権限の閲覧範囲外のデータが⾒えないこと ◦ vitest ▪ 各種フォームのバリデーションの振る舞い ▪ データ表記にまつわる振る舞い • 例) 数値に3桁カンマ区切りがあるか • 例) nullの場合〇〇のように表⽰させるか 27
28. 実践 1. E2Eテストを作りすぎない • テストレベルごとになにを守るか？の例（E2E） ◦ Critical User Journey相当のシナリオの動作の担保 ▪ 例 • 〇〇設定で〇〇を追加できる • 〇〇が計算できる 28
29. 実践 2. E2E → Integration, Unitテストにサイズダウ ンできるものは移⾏する • System Specで担保していたものをPlaywright に移⾏する中でE2Eで担保しなくていいものは Integration, Unitテストで担保した 29
30. 実践 2. E2E → Integration, Unitテストにサイズダウ ンできるものは移⾏する • 移⾏するかサイズダウンするかの判断基準 ◦ Playwrightに移⾏ ▪ Critical User Journey相当のシナリオかどうか ◦ サイズダウン ▪ バリデーション関連のテスト ▪ 細かい仕様の振る舞いを確認するテスト 30
31. 実践 3. E2Eテストの信頼性の回復に向けた動き • 「テストが落ちているけどきっと⼤丈夫だ ろう」からの脱却 ◦ Flakyテストを1個ずつ直す 31
32. 実践 3. E2Eテストの信頼性の回復に向けた動き • Flakyテストの具体例 ◦ await⽂の漏れ ◦ 時間差で出てくる要素が取得できずエラー ◦ ステータスが「処理中」の場合を考慮していな かったためエラー 32
33. 実践 4. テスト実⾏タイミングの⾒直し • E2Eテストの実⾏タイミングを⾒直す ◦ 現状：作業ブランチにPushされた時 ◦ 変更案： ▪ masterブランチにマージ後 ▪ リリースフローで実⾏ ▪ Dailyで定時実⾏ 33
34. 実践 4. テスト実⾏タイミングの⾒直し • E2Eテストの実⾏タイミングを⾒直す ◦ 現状：作業ブランチにPushされた時 ◦ 変更案： ▪ masterブランチにマージ後 ← 採⽤ ▪ リリースフローで実⾏ ▪ Dailyで定時実⾏ 34
35. 実践 4. テスト実⾏タイミングの⾒直し • Dynamic Configurationの導⼊ ◦ CircleCIの機能 ◦ E2Eディレクトリ配下に変更差分があったときのみ 作業ブランチでのCIでE2Eテストを実⾏する 35
36. 実践 4. テスト実⾏タイミングの⾒直し • Dynamic Configurationにさらなる適正化 ◦ フロントエンドに関する差分がある場合 ▪ フロントエンドのテストを実⾏する ▪ バックエンドのテストはSkipする ◦ バックエンドに関する差分がある場合 ▪ バックエンドのテストを実⾏する ▪ フロントエンドのテストはSkipする 36
37. 成果
38. 成果 成果1 • E2EのSuccess Rateが70% → 95%以上に回 復！ 38
39. 成果 成果2 • CIのクレジット消費量が以前と⽐べて半減 した！ 39
40. まとめ
41. まとめ 41 ⾃動テストを増やすとコストが上がる、 でもバグの混⼊のリスクは抑えたい...! 1. 必要な⾃動テストを必要なテストレベルで増やせてい るか ◦ ⾃動テストの戦略の策定 ◦ E2Eテスト偏重をやめる 2. Flakyテストを削減して⾃動テストの信頼性を回復 3. 実⾏タイミングを⾒直すことでコスト削減できないか ◦ 現状の実⾏タイミングが適切なのか？という問い ◦ Dynamic Configurationを活⽤して変更があるときのみ実⾏する
42. We are Hiring! 会社とプロダクトがスケールアップする中で まだまだ⼈が⾜りていません ⼀緒に活動するメンバーを募集中です カジュアル⾯談お待ちしております〜！ 42
43. ご清聴ありがとうご ざいました! 43