Appraiseでビジュアルテストを自動化する

ルックアンドフィールが成功の鍵を握るアプリケーションの開発においては、自動化されたビジュアルテストが有効な場合がある。GitHub上でMITライセンスで公開されているオープンソースツールのAppraiseは、“例示による仕様”というアプローチを採用することにより、視覚検査によってWebページの変更を検証し、承認する作業を支援する。

Appraiseを開発したGojko Adzic氏がEuropean Testing Conference 2018で、“Painless Visual Testing”と題した基調講演を行った。InfoQは氏にインタビューして、ビジュアルテストが難しい理由と、Appraiseについて話を聞いた。

InfoQ: 視覚的な部分をテストする際に、テスタが直面することの多い問題はどのようなものなでしょうか？

Gojko Adzic: アプリケーションの視覚的な面のテストには、これまでは目視と人による判断が必要でした。この点がビジュアルテストをコストと時間の掛かるものにしているのです。適切なカバレッジを得るには、十分な経験を積むことが重要になります。

視覚的な面においては、正しさの表現が難しいことも少なくありません。項目のサイズや位置やスタイルなど、特定のチェックを細々と設計することは可能ですが、画面全体の構成が間違っていたり、奇妙であったり、ひどいものである場合もあります。何かが欠けていればすぐに気付きますが、期待する結果の表現が難しいため、これまでは自動化があまり役に立たない分野でした。

期待する結果が明確で決定論的であったとしても、視覚部分をテストするにはアプリケーションスタック全体を構築し、配置しなければなりません。そのようなテストは必然的に、不安定で時間を要するものになります。

InfoQ: そのような問題に、テスタはどのように取り組んでいるのでしょう？

Adzic: 一般的な解決策は、ユーザインターフェース以下は可能な限り自動化して、その他の目視が必要な部分に手作業を集中する、という方法です。ユーザインターフェースの自動化は遅くて不安定な傾向があるため、ソフトウェアチームは、機能をルックアンドフィールから切り離して、テストをできる限りビジュアルインターフェースよりも下位に押し込もうとします。これがMike Cohn氏が最初に発表した、いわゆるテスト自動化ピラミッドで、今日のテスト自動化におけるベストプラクティスとされるものを語る上で、非常に参考になっています。

この方法は、ユーザインターフェースが真の差別要因ではないような、ビジネスアプリケーションや企業ソフトウェアでは良好に作用するのですが、ルックアンドフィールが成功の鍵となるアプリケーションを開発中のチームには、依然として多くのタスクがあります。そのようなタスクをうまく処理できるテクニックやプラクティスを備えたチームは多くはありません。技術的な面では、アプリケーションの視覚的な面をチェックするツールは数多くありますが、その方程式から人を外すことはやはり不可能なのです。

MindMupを開発している時、私たちはこの問題で本当に苦労しました。このアプリケーションは一般ユーザ向けで、ユーザベースの大部分を学齢期の子供たちが占めているため、視覚面とルックアンドフィールはエクスペリエンス全体において極めて重要です。このアプリケーションを小さなチームで開発し、サポートし、メンテナンスしているのです。コードベースが拡大するにつれ、視覚面のテストに必要な時間が増加し、新たな機能の開発を遅らせる要因になりました。私たちは多数の自動テストを用意していて、アプリケーションの視覚面についても、DOM要素をチェックするブラウザ内テストを使って大部分をテストしていたのですが、これらのテストはメンテナンスが非常に難しかったのです。

例えば、フォントやマージンといったマインドマップ表示の共通部分を少し変更するだけで、数百件のテストにブレークが発生します。これらのテストケースはそれぞれが決定論的で、時間と電卓を使えば新たな期待状態を簡単に見つけられるのですが、私たちとしては、テストケースの修正よりも製品の改善に時間を使いたいのです。関係する部分を抽象化して、実際の視覚的なルックアンドフィールに依存しないようにユニットテストを縮小することはもちろん可能ですが、このアプローチでは問題が発生しないという確証はほとんど得られないので、最終的な結果を視覚面で見直さなければならず、多くの時間が必要になります。

実際には、その他のテストも不安定であったため、主要なルックアンドフィール部分をすべて検証するために、数十件のマインドマップを作成した上で、それらを手作業でロードして、表示が正常であることを検証しなければなりませんでした。視覚上の問題がなければ、フェールしているコード指向テストの実際の結果を何らかの形でコピーして、それを新たな期待値として宣言していました。

このような状況のため、このプロセスをもっとスピードアップできないだろうか、可能ならば視覚的なレビューの実施を支援する自動化パイプラインを設計して、もっと迅速かつ効果的に作業できないものだろうか、と考えるようになりました。人手によるこのような作業の置き換えを目的とした自動化テストの設計に意味がないことは分かっていましたが、その作業を支援する何らかの自動化が設計できれば、それだけでも素晴らしいことです。

目視チェックは見栄えがOKかどうかの判断には優れていますが、すべての情報を収集するプロセスに人が関わる必要はありません。ですから私たちは、最終的な判断以外の部分を自動化する作業に着手しました。アプリケーションをセットアップしてさまざまな視覚的テストケースを試すという、単調な作業を肩代わりして、承認のためにその結果を提示するツールを開発したのです。これによって、それまでより多くのケースをレビューできるようになりました。一度に多数の項目をチェックできるようなマップを数多く用意する代わりに、個々の側面についてのテスト -- 視覚的なユニットテストのようなもの -- を設計して、自動化されたテストによって違いを提示させることが可能になったのです。

InfoQ: Appraiseとは何ですか?

Adzic: Appraiseは、私たちがMindMupのために開発したツールです。同じ問題を抱えている人たちにも同じアプローチが適用できるように、オープンソースとして公開しました。

Appraiseは例示による仕様(specification by example)を採用しているのですが、それをビジュアルに適用しています。具体的な例を選び、自動化レイヤにプッシュして実行可能な仕様を生成し、非表示のChromeを使ってスクリーンショットクリップを取得して、期待される結果と比較します。この種の一般的なツールとは異なり、期待した結果と実際の結果の差異が正しくない場合には、Appraiseは承認テストのアプローチを採用しています。すべての差異を表示し、それを人がレビューして、差異が正しいものかを判断します。そうであれば、その結果を承認します。

フェールしたテストを承認することで、実際の結果が次のテストの期待する結果になります。これによって、テストのメンテナンスがはるかに容易になります。SVGの位置を何時間もかけて再計算する代わりに、ボタンを押すだけで、新しいスクリーンショットが新たな期待値になるのです。ですから、効果的なテスト設計とオートメーションという、例示によるテストを行なうツールでは一般的なメリットに加えて､テストのメンテナンスが簡単になるという、承認テストの特徴的なメリットも享受できます。つまり、数多くのテストケースを素早く実行し、簡単に管理できるのです。

Appraiseは、Webページや視覚的レイアウトやブラウザコンポーネントの変更を、視覚的なインスペクションを通じて短時間に確認し、承認するために役立ちます。AppraiseはxUnitスタイルのコードではなく、ビジュアルな言語を使って視覚的なルックアンドフィールの承認/回帰テストを自動化するように設計されているので、デザイナやテスタ、UX専門家、プロダクトマネージャによるクロスファンクショナルなグループがテストで協力することができます。

さらに、“例示による仕様”アプローチを採用したAppraiseでは、保守と検証の容易な開発用ドキュメントを、視覚的な例から簡単に作ることができます。実行可能な仕様フォーマットとしてMarkdownを使用しているので、GitHub上の“生きたドキュメント”や静的なHTMLサイトとして簡単に公開することが可能です。

AppraiseはMITでライセンスされ、コードはGitHubにホストされています。現在の状態はアルファ版レベルです。つまり、MindMupのルックアンドフィールをテストするという私たちのユースケースでは非常に有用ですが、他の製品やチームワークフローで使用するには相応の対応作業が必要だ、ということです。現在はChrome上で動作するJavaScriptに限定されていますが、他のブラウザや実行ランタイム用に拡張するのは難しくないと思います。

InfoQ: Appraiseを使ってどのようにビジュアルテストを行なうのですか？

Adzic: このツールはテスタではなく、クロスファンクショナルなチームをおもな対象としています。まずは手書きやワイヤフレーム、グラフィックツールによるものなどのスケッチを使用した視覚的な例から始めることで、関連する例や境界値、エッジケースなどについて適切な議論を行なうことができます。こうした議論こそがBDDの本当の価値であり、“例示による仕様”の真骨頂なのです。

これらのスケッチをMarkdown文書化して実行可能な仕様を作成することで、半自動テストが出来上がります。それに従って開発者が機能を実装し、FitNesseのフィクスチャやCucumberのステップと同じようなテストフィクスチャを作成して、例をアプリケーションにリンクします。

次にAppraiseがアプリケーションを実行し、スクリーンショットを取り込んでクリップし、期待されるビジュアルと比較します。すべてが一致すれば何も言うことはありませんが、何らかの相違があれば、それを表示して承認が求められます。手書きのスケッチの場合、最初のテストは当然失敗するでしょうが、相違点の比較が極めて簡単になっているので、UXデザイナなり製品の専門家がレビューして正しいものを承認することができます — これが次の実行時のベースラインになるのです。間違った部分については、Chromeの一般的な開発ツールを使って簡単に調査することができるので、開発者がそれを修正します。

Appraiseはこのように、クロスファンクショナルな会話をサポートし、相違点の発見とレビューを簡単にできるようにデザインされています。

これ以外のビジュアルテスト用のツールとして、Applitools Eyesがある。このツールでは、人の目と脳を模倣する人工知能を使用する。最新リリースに関する詳しい情報は、“Applitools Expands Application Visual Management Capabilities”で見ることができる。

その他、開発中のビジュアルテスト用としては、ChromaticやScreenerといったものもある。