mablは最近流行りの「ビジュアルテスティング（Visual Testing）」という機能を持っています。機能のテストが「アプリの動き」をチェックするものであれば、ビジュアルテスティングは「アプリの見た目」をチェックを担当してくれます。
ビジュアルテスティング概要
mablは機械学習を使って、テスト対象アプリのビジュアルモデルを構築します。さらに、表示のたびに変わっていいバナーや、動きのあるビデオ、アニメーションといった変わってしまう部分を除いて、見た目が大きく変わった部分だけを検知してくれます。
たくさんの顧客が、本番環境のパフォーマンスモニタリングにもmablを活用しています。mablはmablのクラウド環境（Google Cloud）で動作するため、顧客の本番環境に影響を与えずに実行できるからです。
たとえば、以下のようにビジュアルテスティングを活用できます。
- テスト（Test run）ごとのスクリーンショット比較
- 見た目に差分（以後、Visual Change)があった場合の通知
- 画像を横に並べてVisual Changeの比較
- 意図した変更であればベースライン（ビジュアルベースラインと呼んでいる）となるビジュアルモデルの更新
- ビジュアルベースラインの再構築
mablはテストが作られたり、更新されたり、削除されたりするたびにビジュアルモデルを自動更新します。それゆえに、機能テストを更新しても、Visual Changeをご検知しないようにしています。
mablはVisual Changeを検知してもテストをエラーにしたりせず、Warningとして通知してくれます。見た目の差分はテスト結果から確認でき、Insightsに通知を作成し、重要な変更だけに気がつけるような仕組みになっています。
ビジュアルテスティングは、Test Planごとに設定できます。まぁ、普通に使うのであれば、デフォルトでOnにしておくといい気がします。
ビジュアルエクスプローラーの活用
Explorerメニューからビジュアルエクスプローラーを確認できます。mablが自動取得したスクリーンショットが並んでいるはずです。
画像をクリックすると、特定のスクリーンショットを確認できます。この画面からは以下のような点をチェックできます。
- テスト結果としてのスクリーンショット
- 現在の画面スクリーンショット
- ベースラインとなるスクリーンショット
- スクリーンショットを横に並べて確認（side-by-side）
- ベースラインの再構築
- 動的コンテンツの表示・非表示
Visual changeの検知
Test Planを使ってテスト実行をはじめると、mablは自動的にスクリーンショットを取得していきます。それらは、クリックしたとき、入力したときなどのステップごとに撮影されるため、テスト結果として活用できます。
mablは約10回ぐらいのテスト実行によって、ビジュアルベースラインモデルを構築していきます。
Visual changeは自動検知されます。上記のようにテスト結果に「Visual change detected」と表示され、差分をスクリーンショットで確認できます。
たしかに、検知はしていますが、テストとしては成功になってますねー。
ビジュアルモデルの再構築
ビジュアルモデルの再構築は、ACTIONSの「Rebaseline current step」や「Rebaseline all steps」から実行可能です。
それ以外にも「Deployment Events API 」を活用して、デプロイされるごと（つまり画面が変わる可能性が高いタイミングごと）に再構築するのも手です。Settings > APIs から以下のような設定が可能です。
- Rebaseline visual change models: オンにすると対象のテストごとにモデル構築を行うようになります。
- Set as fixed baseline for visual change models: 「fixed baseline」なので、構築したモデルをベースラインとして設定するかどうかの設定ですかね？ よって全スクリーンショットを撮影し、全差分が見えるようになるみたいです。（原文：this tells mabl to run the targeted tests and create a fixed baseline of the captured screenshots and show you all visual diffs, including dynamic content areas, for consecutive test runs）
見た目の問題をレポートする
JIRAのようなIssueトラッキングシステムと連携できるよとのこと。Slack通知だと流れちゃいますが、こういう連携があれば確認作業の効率化につながりますね。
ビジュアルスモークテスト
ビジュアルスモークテストによって、以下のような確認をmablにまかせられます。
- Visual changeの確認
- リンク切れの確認
- JSエラーの確認
- ネットワーク通信の確認
ビジュアルスモークテストは、他のテストと比較して以下の点が異なります。
- ブラウザごとのVisual changeを検知できます。特定ブラウザによる画面崩れもばっちり
- mablではページを自動クローリングするテストも作成できますが、こちらは特定のページのリンク切れの確認のみです
- Visual changeを確認し、ベースラインを更新、予期せぬ変更がないかどうかを見分けるスマートなワークフローを構築できるはずです
リンク切れはユーザにとって不利益であるのと同時に、Googleなどの検索結果にも影響が出てしまいますが、ビジュアルスモークテストによってそれらを回避できるはずです。
ビジュアルスモークテストは、STGや本番といった環境を超えて、継続的なテスト実行につながっていきます。例えば以下のような事例が考えられます。
- マーケティング用ウェブサイトの主要なページの確認
- トライアル依頼、デモリクエスト、資料のダウンロードといった、広告を通したランディングページの確認
- Webアプリにおけるログイン、ユーザ設定といった機能ページの確認
さらに、以下のような流れで実装まですすめられるはずです。
- Google analyticsなどのページ分析サービスを活用して主要ページを特定する
- それらのページのURL一覧を使って、ビジュアルスモークテストを作成する
- 定期実行する。デプロイごとの実行でも良し
- 結果を確認してOK、NGを判断していく。NGなものにはフラグを立てていく
- 問題があればキャプチャを撮るなどして問題を特定していく
mablだと簡単にビジュアルスモークテストを作成できます。上記のようにテスト作成のメニューから「New visual test」を選択して・・・
確認したいURLを設定するだけで、mablは自動的にステップを構築します。
ビジュアルテストの実行は、「Run test」をクリックするだけです。mablは各URLに移動して以下の確認を行います。
- レスポンスコードが200であること
- スクリーンショットの撮影
- リンク切れやJSエラーの確認
- ネットワーク状況をふまえたDOMのスナップショット取得
Visual changeを活用するには、最低でも2回はテスト実行しなければなりません。URL一覧を更新したら、新しくベースラインを作るために数回の実行が必要になります。
Insights
「Insight」メニューから以下の情報を確認できるようになります。
- Visual changeの検知
- リンク切れ
- JSエラー
これらをSlackなどに通知することも可能です。
ビジュアルスモークテストの実行結果を見ると、すべてのページのサムネイル画像を確認できます。サムネイルをクリックすれば、フルスクリーンショットも確認可能です。
画面上部には、リンク数やリンク切れ数、Visual changeの数が表示されるようになります。
Visual changeがあった画面には、サムネイルに黄色いカメラアイコンが表示されます。side-by-sideで比較表示できますし、以下のようなアクションがとれます。
- Visual changeを受け入れる判断をする（Accept）
- 無視する（Dismiss）
- 修正しなければならないと判断してフラグを立てる
フラグを立てた場合は、リンク切れ数やキャプチャなどをJIRA登録したり、CSVで取得して貼り付けたりできます。
まとめ
ビジュアルテスティングはmabl、というか最近のテスト自動化プラットフォームサービスの主要機能とも言えます。
「画面崩れ検知」は随分昔から続く問題の1つであり、がんばれば実装も可能でしょうが、実装とメンテコストを考えると、サービスを使ったほうが安い時代になってきました。
旅と子育てとアジャイルコーチのブログ「世界」 