このブログは「Automated Tests Are "Green" But Your UI Is Broken: How to Balance Feature Testing and Visual Testing in QA」を翻訳・一部加筆したものです。
ソフトウェア品質保証（QA）の分野において、GUIテストほど議論を呼ぶ（そして混乱を招く）テーマはほとんどありません。特に、機能テストとGUI（グラフィカルユーザーインターフェース）テストの間の微妙だが、しかし重要な違いが、その核心を成しています。
グラフィカルユーザーインターフェース（GUI）のテストとは、具体的に何を意味するのでしょうか？機能の確認、レイアウトのチェック、またはその両方なのでしょうか？
この記事では、我々世界中のチームがSquishなどのツールを活用して自動化されたGUIテストを改善するお手伝いをしてきた数年間の経験から得た知見を共有します。その過程で、機能テストとビジュアルテストのギャップを埋める方法、そしてそれがユーザーと製品にとってなぜ重要なのかを解説します。
私は幸運にも、世界中のチームと協力し、特にGUIテストにおいてテスト自動化を強化するお手伝いをしてきました。その際、Squishのようなツールを活用してきました。最初に気づいたことの一つは、「GUIテスト」という言葉は人によって異なる意味を持つということです。
ほとんどのQAエンジニアにとって、GUIテストは主に、インターフェースを通じてアクセス可能な機能が期待通りに動作することを確認する作業を指します。これは、ユーザー操作をシミュレートする作業です：ボタンをクリックする、テキストを入力する、結果を確認する、など。しかし、この機能への焦点が、もう一つの重要な次元を軽視する原因となります。つまりアプリケーションがユーザーにどのように見え、感じられるかということです。
「GUIテストの皮肉と言えるかもしれません：私たちはしばしばGUI自体をテストするのではなく、その背後にある機能をテストしているのです。」
これは重要な点です。なぜなら、エンドユーザーは機能と単にインタラクションするだけでなく、アプリケーションを視覚的に体験するからです。ボタンが正しく配置されていない、テキストが重なっている、またはレイアウトが不一致であるといった問題は、機能に問題がなくてもユーザーの信頼を損なう可能性があります。
この例を説明するために、架空のアプリケーションであるAlpaca Trackerを紹介します。このアプリケーションは、ユーザーがアルパカを登録し、カメラで監視し、毎日の更新を受け取ることができるものです。私たちは、アルパカの登録機能が正常に動作することを確認するためにGUIテストを開発しました。このためのシンプルなGherkinシナリオは次のようなものになります：
Given アルパカ・トラッカーが実行中です
When ユーザーが登録ダイアログを開きます
And アルパカの名前を入力し、登録をクリックします
Then 新しいアルパカがリストに表示されます
このフローを自動化し、コードを書き、テストを実行し、すべてが問題なく通過しました。ユーザーは満足していました…しかしある日、バグ報告が寄せられました。
結果的に、登録機能自体は正常に動作していたものの、登録ダイアログのレイアウトが破損していたことが判明しました。ボタンが重なっていたり、配置が間違っていたりしました。新規ユーザーにとっては混乱を招く可能性があり、経験豊富なユーザーにとっては「何かおかしい」と感じるほどで、アプリケーションのテストが適切に行われたかどうか疑問に思うほどでした。
ここが重要なポイントです：当社の自動テストは、インターフェースの機能性は確認しましたが、視覚的な正確性は確認していませんでした。要素にアクセスでき、機能が正常に動作していれば、テストは合格していました。しかし、ユーザーは機能性だけでなく、見た目、使いやすさ、完成度にも注目しています。
「当社のシナリオは依然として正常に動作していましたが、ユーザーは依然としてバグを報告していました。これは必ずしも矛盾ではありません。これは、私たちが検証対象として選択した範囲とのギャップです。」
このようなレイアウトのバグは致命的な問題ではないかもしれませんが、ユーザーの信頼を徐々に損なう可能性があります。
この問題の核心には、次のようなギャップが存在しています：
機能テスト: 機能は意図したとおりに動作しますか？
GUIテスト: アプリケーションはグラフィカルユーザーインターフェース経由で正常に動作しますか？
レイアウト/ビジュアルテスト: アプリケーションは適切に表示されていますか？
ほとんどのチームは最初の2つに重点を置き、3つ目を軽視しがちです。これは、レイアウトが頻繁に変更されるため、視覚的なテストは脆弱で、時間がかかり、維持が難しいと見なされるからです。
「レイアウトテストは極めて重要であり、非常に頻繁に見落とされています。」
しかし、レイアウトのテストを一切行わない場合、ユーザー体験を損なうバグにさらされるリスクが残ります。
このギャップを埋めるため、チームに過度な負担をかけずに取り組むための3つのアプローチをご紹介します：
既存のテストステップを拡張（非表示の視覚的チェック） |
機能テストに明示的な視覚的チェックを追加する |
専用のビジュアルテストシナリオを作成する（推奨） |
現在のGUIテストのステップを強化し、隠れたレイアウトの検証を含めるようにしてください。
|
既存のテストシナリオに視覚的な検証を明示的に追加し、それらを可視化されたステップとして組み込んでください。 |
レイアウトの検証を、機能ではなく外観に焦点を当てた専用のテストシナリオに分割します。 |
| ✅ Pros: 新しいテストを書く必要はありません。 ❌ Cons: 検証が非表示になり、テストレポートがごちゃごちゃになります。重複したチェックのリスクがあります。 |
✅ Pros: 明確で読みやすいテストケース；オンデマンド検証 ❌ Cons: 機能的な問題と視覚的な問題が相互に干渉し、互いにブロックし合う可能性があります。 |
✅ Pros: 単一責任原則；明確な報告体系；メンテナンスが容易
❌ Cons: 全体的なテスト実行時間を延長します。初期設定作業が必要です。
|
この3つ目のアプローチは、アプリケーションが実行する機能とその見た目を明確に分離し、テスト戦略の堅牢性を高めます。
Squish のようなツールを使用すれば、これらの視覚的なチェックを実装する方法は複数あります：
画像検証ポイント: 迅速なPNG比較（安定したビジュアルに最適）。
スクリーンショット検証ポイント: 誤検出を回避するための柔軟な領域マスク機能。
ビジュアル検証ポイント: 構造、プロパティ、およびビジュアルを含む、オブジェクトレベルの詳細な検証。
より複雑なケース（特に多言語アプリケーションにおけるテキストの切り詰め問題）では、OCR（光学文字認識）を統合することで、ラベルやテキストフィールドが切り詰められたり隠れたりすることなく正しく表示されるようにできます。
一部の人々は、ビジュアルのバグは重要ではないと主張するかもしれません。実際、多くの場合、その主張は正しいでしょう。例えば、Chrome、Windows、Outlookのような主要なアプリケーションは、UIのバグを抱えたままリリースされ、現在も使用されています。しかし、医療、航空、金融システムのような高リスクな環境では、誤解を招くまたは機能しないUIは、現実の世界に深刻な影響を及ぼす可能性があります。
「もし私が重大な手術を受けているなら、私のバイタルサインを監視するソフトウェアが、それらを間違った場所に表示したり、誤った位置のボタンで隠したりするのを望みません。」
結局のところ、信頼が最も重要です。そして、信頼は機能的な信頼性だけでなく、洗練されたユーザーフレンドリーなインターフェースを通じて築かれます。
GUIテストは、機能に焦点を当てることが多く、インターフェース自体には十分な注意が払われない傾向があります。
ビジュアルとレイアウトのテストは頻繁に見落とされがちですが、ユーザー信頼の確保に不可欠です。
機能テストとビジュアルテストの戦略を組み合わせることで、このギャップを埋めることができます。
専用のビジュアルテストケースを使用することは、実践的で効果的なアプローチです。
重要な点を確実にテストしましょう。機能とデザインの両方をテストすることが重要です。なぜなら、アプリケーションの見た目も、その動作と同じくらい重要だからです。
-
GUI自動化を初めて始める場合でも、成熟したテスト戦略をさらに磨き上げる場合でも、Squishは必要な柔軟性と深さを提供し、機能的な正確性と視覚的な精度とのギャップを埋めることができます。
アプリケーションが常に正常に動作し、見た目と操作感が適切であることを確認する方法
について学びましょう。
次のビデオから基調講演をご覧いただき、QAチームが機能テストとビジュアルテストのギャップを埋める方法をご確認ください。
また、テストカバレッジの向上とUI品質の維持を、不要な複雑さを追加せずに実現するための実践的なガイドラインを入手してください。