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
リグレッションテストが多くて困っていた私が試行錯誤しながらPlaywrightに行き着くまでの話
Search
caz
June 12, 2025
0
39
リグレッションテストが多くて困っていた私が試行錯誤しながらPlaywrightに行き着くまでの話
以下のイベントで投影したスライドになります。
https://autifyjapan.connpass.com/event/357817/
caz
June 12, 2025
Tweet
Share
More Decks by caz
See All by caz
WACATE2025夏_テストプロセスに沿ってテストやってみよう
caz
1
260
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Embracing the Ebb and Flow
colly
86
4.7k
What's in a price? How to price your products and services
michaelherold
246
12k
The Invisible Side of Design
smashingmag
300
51k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Agile that works and the tools we love
rasmusluckow
329
21k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Code Review Best Practice
trishagee
69
18k
Transcript
None
アジェンダ 1. 自動化に至った経緯 2. ローコードツールの導入 3. 自動化の課題 4. 自動化の課題をどう対処したか 5.
Playwrightの導入 6. 最後に
自動化に至った経緯 • リグレッションテストが大変になってきた
開発スタイル スプリント開始後のカンバン ↓ 未着手 進行中 QAによるテスト待ち Done バックログ 1 バックログ
2 バックログ 3
開発スタイル スプリント開始後のカンバン ↓ 未着手 進行中 QAによるテスト待ち Done バックログ 1 バックログ
2 バックログ 3 エンジニアが実装着手
開発スタイル スプリント開始後のカンバン ↓ 未着手 進行中 QAによるテスト待ち Done バックログ 1 バックログ
2 バックログ 3 バックログごとに立ち上がっている プレビュー環境でテスト開始
開発スタイル スプリント開始後のカンバン ↓ 未着手 進行中 QAによるテスト待ち Done バックログ 1 バックログ
2 バックログ 3 不具合が見つからなかった場合、ス テージング環境にマージ
開発スタイル スプリント開始後のカンバン ↓ 未着手 進行中 QAによるテスト待ち Done バックログ 1 バックログ
2 バックログ 3 すべてマージされたら ステージング環境で リグレッションテスト開始
開発スタイル スプリント開始後のカンバン ↓ 未着手 進行中 QAによるテスト待ち Done バックログ 1 バックログ
2 バックログ 3 すべてマージされたら ステージング環境で リグレッションテスト開始 過去にリリースされたバックログ のリグレッションテストも含めると 数が膨大に
自動化ツールを勧められ触ってみるが ... 「書き方すぐに覚えられるかな ...」 「というか、どうやって環境構築すればいいの?」 「どうやって実行するの?」 学習コストが高く見送りに ...
自動化ツールを勧められ触ってみるが ... 「書き方すぐに覚えられるかな ...」 「というか、どうやって環境構築すればいいの?」 「どうやって実行するの?」 学習コストが高く見送りに ... ちなみに、この時勧められたツールは Gauge
でした
ローコードツールの mabl を導入 主な選定理由 • エンジニアライクな設計で組織のカルチャーにマッチした ◦ コードを書いて使うことも想定されている ◦ 処理を共通化したり変数を使える
◦ インターフェースが英語
自動化の課題 ①「何をどこまでテストできているのかわからなくなる」
自動化の課題 ①「何をどこまでテストできているのかわからなくなる」 • 「ついでに」で 1つの自動化シナリオに複数のテストを含めていた ◦ メインとなるユーザストーリー単位の自動テストに加えて、開発者から要望のあった ”実装した箇 所がちゃんと動作するか(例:ある UIを操作した時に別の
UIの見た目が変化するか) ”のテストも 自動化したり、ユーザストーリー単位の自動テストに「ついでに」含めていた • バックログごとに作っていたテストをそのまま自動化していた
自動化の課題 ②「メンテナンスが追いつかなくなる」
自動化の課題 ②「メンテナンスが追いつかなくなる」 • 修正に時間がかかる ◦ ①の問題によりどれがメンテナンスする価値のあるテストなのか迷ってしまう ◦ 修正作業以外に、テストがコケた箇所まで処理が進むのを待つ時間、修正後、ちゃんと動くかを 確認する時間が発生する
やったこと その1 • 責務の分担(自動 E2Eテストでカバーしようとしていた責任範囲を削る) ◦ 色々なテストを QAが自動化することで開発者を喜ばせたかったが、プロダクトのこと考えると開 発者と協力してプロダクトの品質と向き合う(一緒にテストを作る)方が良いと考えた
やったこと その2 • バックログごとに作っていたテストから、自動化用のテストを作った ◦ 詳細は次ページ
自動化用のテストを作る バックログ 1 バックログ 2 バックログ 3 今までは... バックログ 1
用のテスト バックログ 2 用のテスト バックログ 3 用のテスト
自動化用のテストを作る バックログ 1 バックログ 2 バックログ 3 今までは... バックログ 1
用のテスト バックログ 2 用のテスト バックログ 3 用のテスト 自動化 自動化 自動化
自動化用のテストを作る バックログ 1 バックログ 2 バックログ 3 今までは... バックログ 1
用のテスト バックログ 2 用のテスト バックログ 3 用のテスト 自動化 自動化 自動化 重複あり
自動化用のテストを作る バックログ 1 バックログ 2 バックログ 3 今までは... バックログ 1
用のテスト バックログ 2 用のテスト バックログ 3 用のテスト 自動化 自動化 自動化 重複あり
自動化用のテストを作る バックログ 1 バックログ 2 バックログ 3 新しいやり方 バックログ 1
用のテスト バックログ 2 用のテスト バックログ 3 用のテスト
自動化用のテストを作る バックログ 1 バックログ 2 バックログ 3 バックログ 1 用のテスト
バックログ 2 用のテスト バックログ 3 用のテスト 自動化用のテスト 新しいやり方 自動化用のテスト
自動化用のテストを作る 新しいやり方 バックログ 1 バックログ 2 バックログ 3 バックログ 1
用のテスト バックログ 2 用のテスト バックログ 3 用のテスト 自動化用のテスト 自動化用のテスト 自動化 自動化
やったこと その3 • 重要な自動テストのメンテナンスに集中し、新規の自動テスト作成の優先度を下 げた
①「何をどこまでテストできているのかわからなくなる」 → 責務を狭めたり、自動化用のテストを自動化することで、自動テストの目的や粒度 が揃い見通しがよくなった 結果
②「メンテナンスが追いつかなくなる」 → 不要な処理や自動テスト自体を削減でき、メンテナンスにかかる時間や労力を削 減できた → 新規の自動化に使っていた工数を、重要な機能に対する自動テストのメンテナン スに当てることで追いつかなさを軽減した 結果
課題を乗り越えたものの ... • 機能の増加に対して自動テストが思ったよりも増えていかない ◦ 「機能の増加に合わせてリグレッションテストも増えていく」という期待してい た結果が得られない ▪ 期待していた効果が得られないと費用対効果が気になってくる •
社内でコストカットの動きが出てくる
課題を乗り越えたものの ... • 機能の増加に対して自動テストが思ったよりも増えていかない ◦ 「機能の増加に合わせてリグレッションテストも増えていく」という期待してい た結果が得られない ▪ 期待していた効果が得られないと費用対効果が気になってくる •
社内でコストカットの動きが出てくる ツール乗り換えの機運が高まる
ツールの移行 • Playwright が候補に挙がる ◦ AIを使えばコードを書くのはそこまで難しくなさそう ◦ リファレンスも多い
ツールの移行 • Playwright が候補に挙がる ◦ AIを使えばコードを書くのはそこまで難しくなさそう ◦ リファレンスも多い ◦ 懸念
▪ どんなテストが作られているのか理解しづらいという過去の経験
Page Object Model (POM) を知る POM未適用
Page Object Model (POM) を知る 1. ログインページにアクセスして ... POM未適用
Page Object Model (POM) を知る 1. ログインページにアクセスして ... 2. メールアドレスを入力して
... 3. POM未適用
Page Object Model (POM) を知る 1. ログインページにアクセスして ... 2. メールアドレスを入力して
... 3. パスワードを入力して ... POM未適用
Page Object Model (POM) を知る 1. ログインページにアクセスして ... 2. メールアドレスを入力して
... 3. パスワードを入力して ... 4. Submit ボタンを押して ... POM未適用
Page Object Model (POM) を知る 1. ログインページにアクセスして ... 2. メールアドレスを入力して
... 3. パスワードを入力して ... 4. Submit ボタンを押して... 5. ログイン後の画面に遷移している か確認 POM未適用
Page Object Model (POM) を知る 1. ログインページにアクセスして ... 2. メールアドレスを入力して
... 3. パスワードを入力して ... 4. Submit ボタンを押して... 5. ログイン後の画面に遷移しているか 確認 6. ログイン後の画面に「ようこそ」とい うメッセージが表示されているか確 認 POM未適用
Page Object Model (POM) を知る 1. ログインページにアクセスして ... 2. メールアドレスを入力して
... 3. パスワードを入力して ... 4. Submit ボタンを押して... 5. ログイン後の画面に遷移している か確認 6. ログイン後の画面に「ようこそ」とい うメッセージが表示されているか確 認 テストの観点はここ POM未適用
Page Object Model (POM) を知る 1. ログインページにアクセスして ... 2. メールアドレスを入力して
... 3. パスワードを入力して ... 4. Submit ボタンを押して ... 5. ログイン後の画面に遷移しているか 確認 6. ログイン後の画面に「ようこそ」という メッセージが表示されているか確認 こちらはテストの準備のような 処理(どんなテストなのかを知る上 でノイズになる記述) POM未適用
Page Object Model (POM) を知る POM未適用 POM適用後 テストしたい観点の記述は同じ
Page Object Model (POM) を知る POM未適用 POM適用後 テストの準備のための記述がスッキリする(ノイズが減らせる)
剛柔 POM という型(剛)を用いて、欲しいテストコードを柔軟に AI に生成してもらうことで、 可読性を保ちつつ、自動テストを増やしていく
剛柔 POM という型(剛)を用いて、欲しいテストコードを柔軟に AI に生成してもらうことで、 可読性を保ちつつ、自動テストを増やしていく →メールやソーシャルログインの操作以外のテストはスムーズに移行できた
さらに • 普段コードを書かない人もメンテナンスや実行できるようにする必要があったの で... ◦ GitHubAction を使ってボタンを押すだけで誰でもテストを実行できるように した ◦ Qaseと連携させて、テストがこけた時に動画付きで記録が残るようにした
今でも使ってもらえてるみたい
以上、Playwrightに行き着くまでの過程でした
最後に 「Playwright と生成AI だけでテスト自動化なんとかなりそうじゃん」 と思った方へ
万能なアプローチではないです • メールを使ったテストなど、ローコードのツールを使う方が実装がとても楽なるも のもあります ◦ Playwright とローコードツールを目的に合わせて両方運用している会社さ んのお話もよく聞きます • 解決の仕方は
AI に聞けば分かりますが、何を解決した方がいいかは専門的な 知識や経験が必要です
ありがとうございました 🎉