VRT(ビジュアルリグレッションテスト)の導入タイミングを考察する
はじめに
みなさんはビジュアルリグレッションテスト(以下 VRT)を導入するタイミングをどのように考えていますか？
筆者も VRT を導入しようと考えた中で、気づけば導入せずにそのままアプリケーションがリリースされ、運用保守に入って導入するタイミングを逃した経験があります。
本記事では、軽く VRT の概要と導入しなかった場合に発生する問題を解説し、どのタイミングで導入するのが適切かを考察します。
VRT とは
Storybook の公式では下記のように記載されています。
Visual tests catch bugs in UI appearance. They work by taking screenshots of every story and comparing them to previous versions to identify visual changes. This is ideal for verifying layout, color, size, contrast, and any other visual aspect of your UI.
ビジュアル・テストは、UI の外観のバグを発見する。 すべてのストーリーのスクリーンショットを撮り、以前のバージョンと比較することで、視覚的な変更を特定します。 これは、レイアウト、色、サイズ、コントラストなど、UI のあらゆるビジュアル面の検証に最適です。
簡潔に話すと、UI の screenshot をとり、前回の screenshot と比較することで、UI の変更を検知するテストです。
なぜ VRT を導入した方がいいのか
VRT を導入しなかった場合に、どのような課題が発生するかを考えてみます。
- 大規模プロジェクトでリファクタリングを行う際、UI に依存関係がある場合、すべての UI 変更を手動で確認するのは非常に困難です。VRT がなければ、意図しない UI の変更を見落とす可能性が高くなり、プロジェクト全体の品質に悪影響を与えるリスクが生じます。
- MUI、Mantine、Chakra UI などの UI ライブラリに破壊的変更が加わった際、VRT がないとその変更が引き起こす UI の崩れに気づかず、そのままリリースされる可能性があります。結果として、ユーザーに対して重大なバグが発生し、ユーザー体験を損なうリスクが高まります。
最悪の場合、売上の減少や信頼の低下につながる可能性があります。
VRT の導入タイミング
では、本題に入ります。
プロジェクトの規模によって導入タイミングは変わると思いますが、客観的に見たメリットとデメリットを挙げつつ、私自身の経験も交えながら解説していきます。
プロジェクト初期
メリット
- 早期に基準となる UI のスクリーンショットを取得できるため、以降の変更点を明確に把握できる
デメリット
- 初期段階では仕様変更が多発し UI の変更が多いため、テストの更新やメンテナンスが煩雑になる可能性がありテストの有効性が保障できない
- セットアップやテスト環境の構築に時間とリソースが必要
- UI の変更が多いため、CI の実行時間が増えたり、コストが嵩む可能性があり費用対効果が薄くなる
私もこれまでに複数の 0→1 プロジェクトを経験しましたが、初期段階から VRT を導入できたことは一度もありません。導入を試みたことはありますが、機能開発や技術選定に追われ、どうしても優先順位が下がってしまいました。また、仕様変更による CI の実行時間の延長や、flaky テストの発生によって、追加の工数がかかるリスクもあります。
プロジェクト中盤
メリット
- 主要な機能が揃ってくるため、VRT による不具合検出がプロジェクト全体の品質向上に直結しテストの有効性が高くなる
デメリット
- すでに開発された部分に対してテストを追加する必要があり、手間がかかる
- VRT を導入していなかったため、それまでに発生した UI の問題を見逃している可能性がある
過去に一度だけ、プロジェクトの中盤あたりで VRT を導入した経験があります。この時期は機能開発の真っ只中で、初めから VRT の準備をしていたわけではなかったため、機能開発の合間に導入することになり、正直かなり大変でした。さらに、プロジェクトの中盤とはいえ仕様変更が頻繁にあり、VRT のテスト効果を実感できる場面は限られていました。
プロジェクト終盤
リリース直前に大量のテストを作成・実行するのは現実的ではなく、それよりも大事なことがいっぱいあります。諦めましょう。もし、余裕があればこのタイミングで導入することをお勧めします。本番前のデグレを未然に防ぐことができるからです。
プロジェクトリリース後
メリット
- UI と機能が確定しているため、テスト結果の信頼性が高まり、品質確認を強化できる。
デメリット
- 事前にある程度 VRT の選定をしていないと、導入工数がかかったり設計によっては導入が大変なパターンもある
プロジェクトリリース後に VRT を導入したことが何度かあります。しかし、事前に VRT の技術選定をしていなかったため、導入に時間がかかり、その間にデグレが発生してしまいました。また、Chromatic などを導入する場合は、対象のコンポーネントを Storybook に登録しないといけないのでさらに時間を費やすことになります。
toC サービスと toB サービスの導入優先度
結論から言うと、どちらにも導入できるのであれば導入した方が良いと思います。その中でも、優先度としては toC サービスの方が高いと感じています。
toC サービスでは、CVR に影響が出てきます。もし、UI の崩れやデザインの不整合が発生し、ユーザーが「このアプリは使いにくいな」と感じた場合、ユーザーの離脱が起こり、CVR が減少してしまいます。
一方、toB では、UI の見た目よりも業務効率が重視されることが多いです。そのため、業務に大きな支障がない限り、致命的な問題とはみなされない場合が多いです。
ただし、UI のデグレが業務プロセスを妨げる場合、生産性の低下やミスの増加につながる可能性があるため、注意は必要です。
まとめ
VRT の導入タイミングについて考察してきましたが、プロジェクトリリース直後に導入することで、リリース済みのアプリを基準にキャプチャ比較ができるため、効果的だと思いました。ただし、リリース直後から VRT の技術選定を行うと、予想以上に工数がかかる場合があります。そのため、事前に VRT の技術選定や必要な工数を確保しておくことで、スムーズに導入できるのではないかと思います。
終わりに
フロントエンドの品質改善に関するお仕事を募集しています。テスト導入からリファクタリング、パフォーマンス改善まで幅広く対応可能です。経歴などの詳細は以下のサイトにまとめておりますので、ご興味のある方は、Twitter の DM などでお気軽にご連絡ください。
Discussion