ビジュアルリグレッションテスト導入での学び

はじめに

こんにちは、atama plusでQAをしているAchanです。
atama plus Advent Calendar 2024の12月12日の記事です。
昨年弊社QA @ikegagagamiが紹介しました「開発プロセスでPlaywrightを活用して自動化を進めている話」でチャレンジ中でしたビジュアルリグレッションテストでの失敗や成果などをご紹介出来ればと思います。

Playwrightでビジュアルリグレッションテストを導入してみたいといった方の参考になれば幸いです。

本記事では以下の構成でご紹介していきます！

• ビジュアルリグレッションテスト導入の経緯
• 検出すべき不具合が検知されなかった問題への対処
• これから
• 最後に

ビジュアルリグレッションテスト導入の経緯

atama plusではIonic Frameworkを用いて、学習アプリの開発を行っています。定期的にionic のバージョンアップに追従していますが、アップデート作業中は新規機能開発を停止していました。

その理由は、新規機能開発とアップデート作業のコンフリクトを避ける為でした。
ですが、手動にて全画面を確認し不具合箇所の洗い出しや修正作業を行っていた為、開発再開までのリードタイムが長くプロダクト進化の足枷になっていました。

そこで、より早くアップデートによる差分を検知する為に、ビジュアルリグレッションテストの導入が検討されました。

ビジュアルリグレッションテスト導入のファーストステップ

前述の通りまず目的としては、アップデートによる差分の検知が目的でした。
その為、各画面でスクリーンショットを取るようにしていました。

await expect(page).toHaveScreenshot('ホーム画面.png', { fullPage: true });

差分検知が目的の為、総画素数に対する異なる画素の割合の許容値設定 maxDiffPixelRatio を0%(完全一致)にして実施していました。

playwright.config.ts

import { defineConfig } from '@playwright/test';
export default defineConfig({
  expect: {
    toHaveScreenshot: { maxDiffPixelRatio : 0},
  },
});

アップデートによる差分を洗い出すことができ、不具合が発生しているコンポーネントの特徴や優先度・許容判断などの材料として活用することが出来ました。

また、手動で確認を行っていたころは新規機能開発を1か月ほど停止していましたが、導入してからは2週間程度の停止期間で新規機能開発が再開できるようになりました。

検出すべき不具合が検知されなかった問題への対処

ionicのバージョンアップでの活用を終え、定期リリースでのリリーステストでもビジュアルリグレッションテストを導入することとなりました。

そこで課題となったのは、maxDiffPixelRatio の値をどの値に設定すべきかという問題でした。

0％した場合、可変箇所の差分や許容してもよい微細な差分まで検出してしまう為、Failするテストが多く保守運用の負担が大きくなりコストバランスが悪い状態になると考えました。

ionicアップデート中で得た検知状況や許容判断を活用し、maxDiffPixelRatio の初期値 5％とすることにしました。アップデート作業では5%でも十分検知可能と考えていた為です。

検知すべき不具合が検知されなかった問題

しかし、リリーステストで度々検知すべき表示崩れが検知されずにPassしてしまうことがありました。

直接的原因は、至極当然ですがmaxDiffPixelRatio 5%を超えない変更だった為でしたが、
根本的な原因は、差分検知したい適切な領域ごとにスクリーンショットを取る設定にしていなかったためでした。

具体的にはフルスクリーンモードでスクショを取っていたことで画面内の差分が発生しやすいエリアとほぼ余白で差分が発生しない箇所を混在させてスクリーンショットを取っていた為、差分が出にくい取り方自体が問題でありました。

問題への対処

そこでまず画面単位ごとにスクショを取っていたのをやめ、画面内に設置している各コンポーネント領域ごとに細分化してスクショを作成するように変更しました。

続いて、可変エリアについても適切にマスクするようにしました。

// メッセージコンポーネントのスクショを取る(H2の可変エリアをマスクする)
const messageComponent= this.page.locator('message');
await expect(messageCompornet).toHaveScreenshot('メッセージコンポーネント.png', { mask: [messageComponent.getByRole('heading')] });

上記対処により、必要な箇所のみ精緻な差分比較が出来るようになり、maxDiffPixelRatio を実質的に下げつつ検知すべき不具合が検知される状況に改善しました。

これから

現時点ではChromeをメインにテスト実施をしていますが、保守運用コストを掛けずに複数のブラウザや画面サイズでのビジュアルリグレッションテスト導入ができないか模索しています。

具体的には、ブラウザやレスポンシブUIによるDOM構造が変化する為、ロケータ指定を変える必要があります。組み合わせが増えるたびにページクラスの定義が煩雑になってしまうことが保守運用上の課題になっています。

また、CI/CDへの組み込みもできないか検討を進めています。

現在の課題としては、CIではPlaywrightが提供しているdocker imageを利用しておりOSがローカル開発環境と異なります。手間なくキャプチャーを保守していく方法がないか模索しています。

最後に

本記事ではビジュアルリグレッションテストでの実例についてご紹介しました。
この記事がビジュアルリグレッションテストを導入したい方の参考になれば幸いです！

明日は、itoちゃんの「Playwrightを導入した話」です。お楽しみに！