CIでリグレッションテストを実行し継続的に品質を担保する

2026/07/17 開催「OPTiM Frontend Meetup #1」でのオプティム 遠藤の発表資料です。

https://optim.connpass.com/event/396222/

Transcript

1. © 2019-2026 OPTiM Corp. All rights reserved. © 2019-2026 OPTiM Corp. All rights reserved. CIでリグレッションテストを実 行し継続的に品質を担保する 遠藤 登壇日：2026/07/17
2. © 2019-2026 OPTiM Corp. All rights reserved. 2 自己紹介 遠藤 フロントエンドエンジニア 2年目 (25新卒) プロダクト ◼OPTiM Biz Premium ◼OPTiM サスマネ ◼OPTiM Biz 操作ログ 技術スタック ◼Next.js, Go, Electron etc… 趣味 ◼料理 ◼ゲーム(SF6)
3. © 2019-2026 OPTiM Corp. All rights reserved. 3  はじめに  採用したアプローチの概要説明  ビジュアルリグレッションテスト(VRT)  Playwrightによる自動テスト  まとめ アジェンダ
4. © 2019-2026 OPTiM Corp. All rights reserved. 4 はじめに 昨今、AIの台頭によって尋常ではないペースで開発速度が高まっている 脆弱性対策など製品が依存するライブラリのリリース頻度も高くなっている 手動による品質チェックには限界がある 品質を自動的かつ継続的に担保する仕組みが必要 ⇨CI Jobによる自動テストの仕組みを整備
5. © 2019-2026 OPTiM Corp. All rights reserved. 5  「継続的」な品質担保のための仕組み ◼CIのJobにビジュアルリグレッションテスト(VRT)と、自動結合・E2EテストのJobを組み込む ⚫MR単位で品質の劣化をチェックする(品質劣化を招くMRは却下、修正を依頼)  「素早く」「容易に」品質担保を行う ◼CI Jobによって自動的にテストが実行される ⚫見た人間は出力されるレポートの結果とCIの結果を見るだけで、一定のレベルの品質を担保可能 ◼目の差分チェック、権限によるUI表示差分のテストなどの細かく時間がかかる & 単純なチェックは人間 でなく機械的に判定する ⚫人間は複雑な機能・サービスの振る舞いなどを手動で検証する役割とする アプローチの概要 Playwrightを使ったVRTおよび自動テストで解決
6. 6 © 2019-2026 OPTiM Corp. All rights reserved. ビジュアルリグレッションテスト(VRT)
7. © 2019-2026 OPTiM Corp. All rights reserved. 7  製品の見た目の差分をチェックするテストのこと ◼スクリーンショットを撮り差分を比較する ◼UIの崩れなどの見た目差分を検知できる  コンポーネントの修正時やUIライブラリ系の更新時に特に有効 ◼見た目の差分が発生していないかを広く見ることができる ◼「見た目の差分チェック」は単純作業だが人間が目視でチェックするのはとても大変 <イメージ> ビジュアルリグレッションテスト(VRT)とは？ 他機能の修正・変更対応 UIライブラリのバージョン更新 意図しない「見た目」の差分が出ている ⇨これを検知したい
8. © 2019-2026 OPTiM Corp. All rights reserved. 8  CI Job内でフロントサーバーとフロント側で用意したバックエンドのモックサーバーを起動  Playwrightによるスクリーンショット機能を使ってbaselineとの差分を比較  差分のレポートファイルをS3にアップロード  MRにS3にアップロードされたレポートをコメント  MRがマージされたタイミングでbaselineを更新する VRTのアプローチ
9. © 2019-2026 OPTiM Corp. All rights reserved. 9 デモ 差分が強調表示される！
10. © 2019-2026 OPTiM Corp. All rights reserved. 10 モックサーバーを使ってバックエンドからのレスポンスを常に固定する ◼VRTでは見た目にのみ興味があるので、レスポンスはある程度整合性があれば何でも良い ◼ログデータなどデータ自体が安定しないものを含む画面でも、常に表示結果が一定になってい るとテストしやすい 差分があってもCIは敢えて落とさない ◼見た目が変わることが正しいMRでCIが落ちることを防ぐ ◼MRコメントにレポートの結果が出るため、差分検出自体はできる VRTのアプローチの工夫点
11. 11 © 2019-2026 OPTiM Corp. All rights reserved. Playwrightによる自動テスト
12. © 2019-2026 OPTiM Corp. All rights reserved. 12 結合後の動作を検証する ◼例)認証機能、複数の画面を跨ぐ機能、ログインユーザーの権限に応じた細かい機能差分チェック etc.. ◼実際にシステムを動作させないと確認できない挙動を確認する 単体テストでは確認できない「つながり」の壊れを検出できる 「単純な作業」だが、「時間がかかる」検証作業を自動で行う ◼担当したシステムでは、権限に応じた機能差分が大量にあった Playwrightを使った自動テスト
13. © 2019-2026 OPTiM Corp. All rights reserved. 13 「どこに何を置くか」を最初に決める ディレクトリ 対象 e2e/tests/guest/ 未認証ユーザーの導線（OAuthへの遷移など） e2e/tests/authenticated/ 認証済みの画面・直接アクセス・基本操作 e2e/tests/permissions/ ロール別のアクセス可否・UI状態 e2e/tests/journeys/ 複数ページを跨ぐ回遊シナリオ  ディレクトリ単位で何を担保するテストなのかを分ける ◼ 「権限管理系のみをテストしたい」という要求にも応えることができる ◼ 何のspecのテストが落ちたかで、どこの機能に不具合があるかを把握できる ◼ AIのskillにも各ディレクトリの責務を反映させる specの配置戦略
14. © 2019-2026 OPTiM Corp. All rights reserved. 14  Playwrightのテストコードを書くのは大変 ◼数十単位のテストシナリオのシナリオに則したコードを書くのは辛いし現実的ではない ◼Codegen機能だとテストコードの質の問題や結局人間が操作しなければならない問題がつきまとう テストコードをどう用意するか？ AIによるテストコードの自動生成 ⇨品質・テスト観点書から自動でテストコード を生成する仕組みを導入
15. © 2019-2026 OPTiM Corp. All rights reserved. 15  別リポジトリで管理されている「品質観点」「テスト項目」をsubmoduleとしてインポート ◼ 品質観点、テスト項目はmarkdown & json形式でテンプレート化されている ◼ 観点と項目の作成は人間が行う。テンプレート化をAIが担当  Submoduleからテスト用コードを自動生成 ◼ 実装をある程度参照させる & 実画面をAIに触らせることでAIがテスト項目で指示される操作をPlaywrightのコードに落とし込む ◼ テストコード生成用のskill環境を整備 生成AIによるspecの生成
16. © 2019-2026 OPTiM Corp. All rights reserved. 16  以下の3つのskillを連続的に呼び出すことでテストコードを自動生成している  1. Test-design skill ◼ Submoduleの品質観点・テスト観点を読み出し、TODOコメントだけを書く skill ◼ 次に呼び出すSkillで明確に何をすれば良いかの証跡を残す  2. Test-Implement skill ◼ Playwright-CLI / MCPを使ってTODOコメントにある内容を実際に操作する ◼ 期待値の確認や、実際にどのようなブラウザ操作が必要かを調査する ◼ 調査結果をもとにPlaywrightのコードにAAAパターンで落とし込む  3. Review skill ◼ 事前に定義したバッドプラクティスに抵触するテストコードがないか調査する ◼ Flakyなテストコードや、テストが簡単に通る成功基準が曖昧なテストコードを調査 ◼ 問題があるコードはここで修正する skillによる自動テスト実装の流れ
17. © 2019-2026 OPTiM Corp. All rights reserved. 17  テストコードの実装方針を伝えないとAIはBADなテストコードを出力しがち ◼ テストを無理矢理通すためにズルをし始める(=意味のないテストが作られる) ◼ テストの結果が安定しないFlakyなテストコードを書き始める ＜BADなテストコードの例＞ ◼ 待機時間を決めうちする ◼ 操作手順や期待値を曖昧にする ◼ DOMやCSSクラスに過度に依存する ◼ 前回のテスト結果に依存するテストコード etc...  Review skillとImplement skillにはバッドプラクティスを回避する仕組みを導入している ◼ few shotの要領で、避けるべきBADなテストコード例を複数記載する ◼ ページ待機の方法やページ内要素の取得方法などのベストプラクティス明示しておく skillでバッドプラクティスを回避する
18. © 2019-2026 OPTiM Corp. All rights reserved. 18 Playwrightによる VRTと自動テストをCIで実施できる仕組みを提供 継続的に品質をチェックする仕組みを整備 AIによって開発が加速した環境で、品質担保の労力を下げることができる仕組みを整備 ◼テストの自動生成・自動実行により実現(容易に検証ができる) 人間が検証作業を丸投げすることはしない ◼あくまで「単純」で「時間がかかる」検証は自動的な仕組みに任せる ◼UXの検証や、複雑性の高い・ハイコンテキストな動作の検証は人間側がやることにも価値があ る 継続的に、素早く、容易に品質担保できる仕組みを導入 まとめ
19. © 2019-2026 OPTiM Corp. All rights reserved.