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

by OPTiM

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2019-2026 OPTiM Corp. All rights reserved. 5  「継続的」な品質担保のための仕組み ◼CIのJobにビジュアルリグレッションテスト(VRT)と、自動結合・E2EテストのJobを組み込む ⚫MR単位で品質の劣化をチェックする(品質劣化を招くMRは却下、修正を依頼)  「素早く」「容易に」品質担保を行う ◼CI Jobによって自動的にテストが実行される ⚫見た人間は出力されるレポートの結果とCIの結果を見るだけで、一定のレベルの品質を担保可能 ◼目の差分チェック、権限によるUI表示差分のテストなどの細かく時間がかかる & 単純なチェックは人間でなく機械的に判定する ⚫人間は複雑な機能・サービスの振る舞いなどを手動で検証する役割とするアプローチの概要 Playwrightを使ったVRTおよび自動テストで解決

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 2019-2026 OPTiM Corp. All rights reserved. 7  製品の見た目の差分をチェックするテストのこと ◼スクリーンショットを撮り差分を比較する ◼UIの崩れなどの見た目差分を検知できる  コンポーネントの修正時やUIライブラリ系の更新時に特に有効 ◼見た目の差分が発生していないかを広く見ることができる ◼「見た目の差分チェック」は単純作業だが人間が目視でチェックするのはとても大変 <イメージ> ビジュアルリグレッションテスト(VRT)とは？他機能の修正・変更対応 UIライブラリのバージョン更新意図しない「見た目」の差分が出ている ⇨これを検知したい

Slide 8

Slide 8 text

© 2019-2026 OPTiM Corp. All rights reserved. 8  CI Job内でフロントサーバーとフロント側で用意したバックエンドのモックサーバーを起動  Playwrightによるスクリーンショット機能を使ってbaselineとの差分を比較  差分のレポートファイルをS3にアップロード  MRにS3にアップロードされたレポートをコメント  MRがマージされたタイミングでbaselineを更新する VRTのアプローチ

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2019-2026 OPTiM Corp. All rights reserved. 10 モックサーバーを使ってバックエンドからのレスポンスを常に固定する ◼VRTでは見た目にのみ興味があるので、レスポンスはある程度整合性があれば何でも良い ◼ログデータなどデータ自体が安定しないものを含む画面でも、常に表示結果が一定になっているとテストしやすい 差分があってもCIは敢えて落とさない ◼見た目が変わることが正しいMRでCIが落ちることを防ぐ ◼MRコメントにレポートの結果が出るため、差分検出自体はできる VRTのアプローチの工夫点

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© 2019-2026 OPTiM Corp. All rights reserved. 12 結合後の動作を検証する ◼例)認証機能、複数の画面を跨ぐ機能、ログインユーザーの権限に応じた細かい機能差分チェック etc.. ◼実際にシステムを動作させないと確認できない挙動を確認する 単体テストでは確認できない「つながり」の壊れを検出できる 「単純な作業」だが、「時間がかかる」検証作業を自動で行う ◼担当したシステムでは、権限に応じた機能差分が大量にあった Playwrightを使った自動テスト

Slide 13

Slide 13 text

© 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の配置戦略

Slide 14

Slide 14 text

© 2019-2026 OPTiM Corp. All rights reserved. 14  Playwrightのテストコードを書くのは大変 ◼数十単位のテストシナリオのシナリオに則したコードを書くのは辛いし現実的ではない ◼Codegen機能だとテストコードの質の問題や結局人間が操作しなければならない問題がつきまとうテストコードをどう用意するか？ AIによるテストコードの自動生成 ⇨品質・テスト観点書から自動でテストコードを生成する仕組みを導入

Slide 15

Slide 15 text

© 2019-2026 OPTiM Corp. All rights reserved. 15  別リポジトリで管理されている「品質観点」「テスト項目」をsubmoduleとしてインポート ◼ 品質観点、テスト項目はmarkdown & json形式でテンプレート化されている ◼ 観点と項目の作成は人間が行う。テンプレート化をAIが担当  Submoduleからテスト用コードを自動生成 ◼ 実装をある程度参照させる & 実画面をAIに触らせることでAIがテスト項目で指示される操作をPlaywrightのコードに落とし込む ◼ テストコード生成用のskill環境を整備生成AIによるspecの生成

Slide 16

Slide 16 text

© 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による自動テスト実装の流れ

Slide 17

Slide 17 text

© 2019-2026 OPTiM Corp. All rights reserved. 17  テストコードの実装方針を伝えないとAIはBADなテストコードを出力しがち ◼ テストを無理矢理通すためにズルをし始める(=意味のないテストが作られる) ◼ テストの結果が安定しないFlakyなテストコードを書き始める＜BADなテストコードの例＞ ◼ 待機時間を決めうちする ◼ 操作手順や期待値を曖昧にする ◼ DOMやCSSクラスに過度に依存する ◼ 前回のテスト結果に依存するテストコード etc...  Review skillとImplement skillにはバッドプラクティスを回避する仕組みを導入している ◼ few shotの要領で、避けるべきBADなテストコード例を複数記載する ◼ ページ待機の方法やページ内要素の取得方法などのベストプラクティス明示しておく skillでバッドプラクティスを回避する

Slide 18

Slide 18 text

© 2019-2026 OPTiM Corp. All rights reserved. 18 Playwrightによる VRTと自動テストをCIで実施できる仕組みを提供 継続的に品質をチェックする仕組みを整備 AIによって開発が加速した環境で、品質担保の労力を下げることができる仕組みを整備 ◼テストの自動生成・自動実行により実現(容易に検証ができる) 人間が検証作業を丸投げすることはしない ◼あくまで「単純」で「時間がかかる」検証は自動的な仕組みに任せる ◼UXの検証や、複雑性の高い・ハイコンテキストな動作の検証は人間側がやることにも価値がある継続的に、素早く、容易に品質担保できる仕組みを導入まとめ