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
自動テストのコストと向き合ってみた
Search
SmartHR 品質保証部
October 07, 2025
Technology
1
250
自動テストのコストと向き合ってみた
2025年10月7日 LAPRAS社主催「QA LT Night」登壇資料
登壇者:豊島
connpass
https://lapras.connpass.com/event/368463/
SmartHR 品質保証部
October 07, 2025
Tweet
Share
More Decks by SmartHR 品質保証部
See All by SmartHR 品質保証部
LLMを搭載したプロダクトの品質保証の模索と学び
qa
1
1.9k
年末調整プロダクトの内部品質改善活動について
qa
0
31
スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
qa
1
99
SmartHRの品質保証部の 今とこれから
qa
1
310
E2E自動テストのFlakyに対処しようと思ってAPIでArrangeしてみたの
qa
0
2.1k
E2E自動テストのロケータの使い分けを考えてみたの
qa
0
1.2k
品質保証本部カジュアル面談資料(2025/10/1更新)
qa
1
29k
Other Decks in Technology
See All in Technology
Dify on AWS 環境構築手順
yosse95ai
0
170
AI連携の新常識! 話題のMCPをはじめて学ぶ!
makoakiba
0
150
AIエージェントによる業務効率化への飽くなき挑戦-AWS上の実開発事例から学んだ効果、現実そしてギャップ-
nasuvitz
5
1.4k
ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう
sansantech
PRO
1
540
.NET 10のBlazorの期待の新機能
htkym
0
150
デザインとエンジニアリングの架け橋を目指す OPTiMのデザインシステム「nucleus」の軌跡と広げ方
optim
0
120
SREのキャリアから経営に近づく - Enterprise Risk Managementを基に -
shonansurvivors
0
270
AIの個性を理解し、指揮する
shoota
3
450
Amazon Athena で JSON・Parquet・Iceberg のデータを検索し、性能を比較してみた
shigeruoda
1
200
東京大学「Agile-X」のFPGA AIデザインハッカソンを制したソニーのAI最適化
sony
0
150
入院医療費算定業務をAIで支援する:包括医療費支払い制度とDPCコーディング (公開版)
hagino3000
0
120
激動の時代を爆速リチーミングで乗り越えろ
sansantech
PRO
1
170
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Mobile First: as difficult as doing things right
swwweet
225
10k
Thoughts on Productivity
jonyablonski
71
4.9k
What's in a price? How to price your products and services
michaelherold
246
12k
The Cult of Friendly URLs
andyhume
79
6.6k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
658
61k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
930
Product Roadmaps are Hard
iamctodd
PRO
55
11k
How GitHub (no longer) Works
holman
315
140k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
116
20k
Transcript
© SmartHR, Inc. ⾃動テストの コストと向き合ってみた 豊島 誠之 SmartHR 技術統括本部 品質保証本部
タレントマネジメントユニット 2025/10/7 QA LT Night 〜品質を追求するプロたちの集い〜 画像を置換
豊島 誠之(toyosea) 経歴 • 事業会社でのフロントエンドエンジニアやOpsのキャリアを経て、 QAエンジニアへキャリアチェンジ • 2025年3⽉にSmartHR⼊社後、タレントマネジメント領域のプロダ クトのQAを担当しており、現在はチームメンバーのSETスキルの底 上げにも取り組んでいる。
• 趣味で⾳楽を作ってます。Apple MusicやSpotifyで「toyosea」と 検索してみてください ⾃⼰紹介
本⽇のテーマ • 「⾃動テストを増やすとコストが上がる、 でもバグの混⼊のリスクは抑えたい...!」 • 「この両者のバランスを良い感じにするに はどうすればよいのか?」 3
4
5
タレントマネジメントユニットとは 特徴 • 実働4名体制 (チーフ1名 + メンバー3名) • 1名ずつ1~2個のプロダクトに関わる •
QAとしての関わり⽅はプロダクトの品質課題によって変えていきま す 6
タレントマネジメントユニットとは (宣伝)ユニットのチームビルディング施策のブログ 7
本⽇お話すること 1. 問い 2. 現状分析 3. 戦略 4. 実践 5.
成果 6. まとめ
問い
• 「⾃動テストを増やすとコストが上がる、 でもバグの混⼊のリスクは抑えたい...!」 • 「この両者のバランスを良い感じにするに はどうすればよいのか?」 問い 10
問い 11 ⽤語のすりあわせ • ⾃動テストとは ◦ E2Eテストだけを指しません ◦ Unit, Integration,
E2Eテストを包括した前提で 話します
問い 12 ⽤語のすりあわせ • コストとは ◦ ⾃動テストのメンテナンスコスト ◦ CIのクレジット消費量の⾦銭的なコスト
現状分析 13 和⽥卓⼈⽒ 「テストサイズで再考する「テストピラミッド」 Googleが提唱する効率的な⾃動テスト戦略」より引⽤
問い 14 技術スタックのすりあわせ • ⾔語‧サービス ◦ Backend: RSpec ◦ Frontend:
vitest, Storybook ◦ E2E: Playwright, System Spec ◦ CI: CircleCI
現状分析
現状分析 16 担当プロダクト • ⾃動テスト(Unit) ▪ Backend • 指定した閾値までカバレッジが達しているかをチェックするCI のジョブがあり、カバレッジは⾼く保てている状況
▪ Frontend • Formatterなどの共通で使う関数で単体テストが書かれている 状況 • ビジネスロジックに関する単体テストはあまり書かれていない 状況
現状分析 17 担当プロダクト • ⾃動テスト(Integration) ◦ Backend ▪ APIテストも指定した閾値にカバレッジが達しているかを チェックするCIのジョブがあり、カバレッジは⾼く保ててい
る状況 ◦ Frontend ▪ Storybookでのコンポーネントテストやヴィジュアルリグレッ ションテストが書かれている状況
現状分析 18 担当プロダクト • ⾃動テスト(E2E) ◦ 主要機能のCRUD操作や⼀部イレギュラーな操作のテス トが書かれている状況 ◦ PlaywrightとRailsのSystem
Specが混在している状況 ◦ Flakyテストが多くなりテストの信頼性が落ちている状 況
現状分析 19 担当プロダクト • コスト ◦ CI ▪ 作業ブランチにPushするたびにCIでE2Eテストが実⾏されて いた
▪ SmartHRの多数のプロダクトの中で2番⽬にクレジット消費量 が多くなっていた ▪ E2EのFlakyテストが放置されたままの状況になっていた • メンテナンスコストが多くなり⼿に負えなくなっていた • 「テストが落ちているけどきっと⼤丈夫だろう」という状況 • CIのSuccess Rate (成功率) は70%前後だった
現状分析 20 まとめ • Unit, Integrationレベルのコストに関する課題はなさそう ◦ ただし⾃動テストとしてFrontendのビジネスロジックに関する単体 テストが不⾜している課題はある •
E2Eテストの数はあるがテスト結果の信頼性が低い状態の ためテストの意味が損なわれつつある • テストの意味が損なわれつつあるにも関わらず、CIのクレ ジット消費量にコストがかかっている状況
現状分析 21 このままだとどうなってしまう? • E2Eテストの信頼性が低いまま運⽤されてしまう • ⾃動テストによる恩恵を最⼤限受けられないままCI の⾦銭的なコストを払い続けることになる
戦略
戦略 23 ⾃動テスト • E2Eテストを作りすぎない ◦ 新規機能に関して⾃動テスト戦略を⽴てる ◦ Critical User
Journey相当のテストに絞る • E2E → Integration, Unitテストにサイズダウンできるものは移⾏す る • E2Eテストの信頼性の回復 ◦ Flakyテストの削減 ※Critical User Journey ビジネスの観点から重要とされる部分にフォーカスしたカスタマージャーニーのこと
戦略 24 コスト • テスト実⾏タイミングの⾒直し ◦ 作業ブランチにPushするたびにE2Eテストを実⾏ しなきゃダメなんだっけ?という問い
実践
実践 1. E2Eテストを作りすぎない • ⾃動テスト戦略を⽴てる ◦ 新規機能開発時に⽴案 ◦ テストレベルごとになにを守るか?の⾔語化 26
実践 1. E2Eテストを作りすぎない • テストレベルごとになにを守るか?の例(Unitテスト) ◦ RSpec ▪ 〇〇機能の計算処理 ▪
権限の閲覧範囲外のデータが⾒えないこと ◦ vitest ▪ 各種フォームのバリデーションの振る舞い ▪ データ表記にまつわる振る舞い • 例) 数値に3桁カンマ区切りがあるか • 例) nullの場合〇〇のように表⽰させるか 27
実践 1. E2Eテストを作りすぎない • テストレベルごとになにを守るか?の例(E2E) ◦ Critical User Journey相当のシナリオの動作の担保 ▪
例 • 〇〇設定で〇〇を追加できる • 〇〇が計算できる 28
実践 2. E2E → Integration, Unitテストにサイズダウ ンできるものは移⾏する • System Specで担保していたものをPlaywright
に移⾏する中でE2Eで担保しなくていいものは Integration, Unitテストで担保した 29
実践 2. E2E → Integration, Unitテストにサイズダウ ンできるものは移⾏する • 移⾏するかサイズダウンするかの判断基準 ◦
Playwrightに移⾏ ▪ Critical User Journey相当のシナリオかどうか ◦ サイズダウン ▪ バリデーション関連のテスト ▪ 細かい仕様の振る舞いを確認するテスト 30
実践 3. E2Eテストの信頼性の回復に向けた動き • 「テストが落ちているけどきっと⼤丈夫だ ろう」からの脱却 ◦ Flakyテストを1個ずつ直す 31
実践 3. E2Eテストの信頼性の回復に向けた動き • Flakyテストの具体例 ◦ await⽂の漏れ ◦ 時間差で出てくる要素が取得できずエラー ◦
ステータスが「処理中」の場合を考慮していな かったためエラー 32
実践 4. テスト実⾏タイミングの⾒直し • E2Eテストの実⾏タイミングを⾒直す ◦ 現状:作業ブランチにPushされた時 ◦ 変更案: ▪
masterブランチにマージ後 ▪ リリースフローで実⾏ ▪ Dailyで定時実⾏ 33
実践 4. テスト実⾏タイミングの⾒直し • E2Eテストの実⾏タイミングを⾒直す ◦ 現状:作業ブランチにPushされた時 ◦ 変更案: ▪
masterブランチにマージ後 ← 採⽤ ▪ リリースフローで実⾏ ▪ Dailyで定時実⾏ 34
実践 4. テスト実⾏タイミングの⾒直し • Dynamic Configurationの導⼊ ◦ CircleCIの機能 ◦ E2Eディレクトリ配下に変更差分があったときのみ
作業ブランチでのCIでE2Eテストを実⾏する 35
実践 4. テスト実⾏タイミングの⾒直し • Dynamic Configurationにさらなる適正化 ◦ フロントエンドに関する差分がある場合 ▪ フロントエンドのテストを実⾏する
▪ バックエンドのテストはSkipする ◦ バックエンドに関する差分がある場合 ▪ バックエンドのテストを実⾏する ▪ フロントエンドのテストはSkipする 36
成果
成果 成果1 • E2EのSuccess Rateが70% → 95%以上に回 復! 38
成果 成果2 • CIのクレジット消費量が以前と⽐べて半減 した! 39
まとめ
まとめ 41 ⾃動テストを増やすとコストが上がる、 でもバグの混⼊のリスクは抑えたい...! 1. 必要な⾃動テストを必要なテストレベルで増やせてい るか ◦ ⾃動テストの戦略の策定 ◦
E2Eテスト偏重をやめる 2. Flakyテストを削減して⾃動テストの信頼性を回復 3. 実⾏タイミングを⾒直すことでコスト削減できないか ◦ 現状の実⾏タイミングが適切なのか?という問い ◦ Dynamic Configurationを活⽤して変更があるときのみ実⾏する
We are Hiring! 会社とプロダクトがスケールアップする中で まだまだ⼈が⾜りていません ⼀緒に活動するメンバーを募集中です カジュアル⾯談お待ちしております〜! 42
ご清聴ありがとうご ざいました! 43