このブログは「Smarter Testing with GenAI: From Exploratory Ideas to Automated Scripts」を翻訳・一部加筆したものです。
探索的テストは、ソフトウェアの品質保証において、常に最も創造的で人間的な要素の1つです。これは、テスターがチェックリストを超えて、ユーザーがアプリケーションとどのように対話するかを真に調査するステップです。テスターは、あらかじめ定義されたテストケースに従うのではなく、質問をしたり、入力を試したり、問題が発生する可能性について批判的に考えたりして、ソフトウェアを探索します。
ソフトウェアテストにおける生成型 AI の台頭により、探索的テストはより効率的かつ強力になってきています。AI は、テスターの直感や経験を置き換えるものではありません。むしろ、テスターと協力して、隠れたバグの発見、ユーザビリティの問題の特定、そして既成概念にとらわれない発想力を強化する役割を果たします。
例えば、生成型 AI は次のようなことができます：
ユーザーストーリーを分析し、エッジケースを提案します
UI スクリーンショットを確認し、混乱を招くレイアウトや位置ずれのあるコンポーネントを指摘します
開発初期段階で見落とされがちな、リスクの高い入力の組み合わせを提案します
テストに 生成 AI を使用することの最大のメリットの 1 つは、テストのアイデアを 自動テストスクリプト に迅速に変換できることです。Gherkin シナリオを記述すると、AI が対応する Python または JavaScript のテストコードを生成します。テスターは、生成されたコードをレビューして改良する必要がありますが、反復的なスクリプトの記述に費やす時間が大幅に削減されます。これにより、テスターはテストロジックの品質や、実際の課題の発見により集中することができます。
視覚テストも、AI が大きな価値をもたらす分野です。従来の視覚チェックは、自動化に時間がかかります。生成型 AI ツールは、スクリーンショットをスキャンして、視覚的な不整合、欠落しているアクセシビリティラベル、意図しない UI の変化などを指摘します。これらの問題は機能に支障をきたすことはありませんが、ユーザーエクスペリエンスを低下させる可能性があります。AI モデルは、視覚認識とコンテキストに基づく推論の両方をプロセスに導入し、単純なアサーションでは見つけられない問題をテスターが発見するのに役立ちます。
これらの進歩にもかかわらず、AI は完璧ではなく、その使用には注意が必要です。生成モデルは常に正確であるとは限りません。誤った仮定をしたり、重要なエッジケースを見逃したりする可能性があります。そのため、人間の監視は依然として不可欠です。テスターは、AI が生成した提案を慎重に検証し、AI を代替手段ではなく協力者として扱う必要があります。
人間のテスターは、AI が生成した洞察を慎重に検証する必要があります。重要なのは、AI を意思決定者ではなく、協力者として扱うことです。
AI を慎重に導入すると、テスト環境のセットアップが迅速化され、テストカバレッジが向上し、より創造的な QA アプローチがサポートされます。これにより、チームは高い品質基準を維持しながら、作業効率を向上させることができます。
AI のメリットを享受するために高度なツールは必要ありません。いくつかの適切なプロンプトを入力するだけで、有用な洞察を得ることができます。次のように質問してみてください：
このログイン機能にはどのようなエッジケースが考えられますか？
このスクリーンショットでは、どの UI 要素が混乱を招く、位置がずれている、または欠落している可能性がありますか？
このバグレポートに基づいて、アプリのどの部分を再テストすべきですか？
このページでネットワークの遅延が高くなった場合に、どのような問題が発生するかをシミュレートしてください。
このバージョンの UI を以前のバージョンと比較してください。視覚的にどのような変更がありますか？
このようなプロンプトにより、AI は新鮮な視点を提供し、盲点を明らかにすることで、あなたの思考をサポートします。
AI を搭載したビジュアルテストツールは、手動テストでは見落としがちな微妙な視覚的な問題を検出できます。以下に挙げる問題は、スクリーンショットの比較、ビジュアル差分、レイアウト分析などを使用して、特に参照用の既知のベースラインバージョンがある場合に、AI が確実に検出できる問題です：
ユーザーストーリーの分析とエッジケースの提案
スクリーンショットの検査によるレイアウトの不整合や混乱を招く要素の指摘
リスクの高い入力の組み合わせによるテストシナリオのシミュレーション
バグレポートを実行可能なテストケースに要約
Gherkin シナリオの提案とベースレベルのテストコードへの変換
生成型 AI が探索的テストおよび視覚的テストにおいてどのように機能するかを説明するために、UI の正確性と使いやすさが重要な 2 つのハイリスク業界、すなわち産業システムと医療機器の事例を見てみましょう。
AIはレイアウトとレンダリングの問題を検出しますが、システム論理や安全性の関連性を検証することはできません。
ダッシュボードにデータが正しく表示されない（例：温度や圧力の測定値が正しいグリッドに表示されない）
モードの切り替え後に UI 要素が消える（例：エンジニアビューとオペレータービューの切り替え）
チャートのレンダリングエラー（例：軸のラベルがずれたり、切り取られたりしている）
多言語インターフェースでレイアウトが崩れる（例：ドイツ語のテキストがボタンからはみ出している）
AIはこれらの問題を検出できますが、テスターは変更が臨床的に意味があるかどうかを必ず確認する必要があります。
アクセシビリティ基準を満たさない低コントラストのテキスト（例：白地に灰色）
破損または欠落しているボタン（例：治療ワークフローに確認ボタンが表示されない）
EMRまたは診断ツールの画面間でフォントと色が一致していない
AI は生産性と創造性を高めますが、特に Qt、Windows、Android、Java、または組み込みシステムで構築された複雑またはドメイン固有のアプリケーションでは、GUI 自動化ツールに取って代わるものではありません。
AI を搭載したビジュアル差分ツールは、UI の退化、色の不一致、間隔の問題、コンポーネントのずれなどを検出するのに優れています。しかし、自動車、航空宇宙、医療などの安全性が重要な業界では、視覚的な検出だけでは不十分です。必要なものは次のとおりです。
ベースライン比較
ドメイン固有の検証
手動によるレビューおよび人間の判断
先ほど述べたように、専門の自動化GUIテストツールは、構造化された視覚的検証とアクセシビリティチェックを、テスト可能で繰り返し実行可能かつ監査可能なフレームワークに組み込みます。これは、AIだけでは保証できないものです。
例えば、Squish 自動化 GUI テストツールを使用すると、Cursor や Claude のような AI アシスタントを活用して、Squish GUI テストスクリプトを効率的に生成、洗練化、実行する以下の ワークフローを実装できます。これにより、完全な制御と信頼性を維持しながら、AI の利点を最大限に活用できます：
スタイルとベストプラクティスガイドを定義する
AIアシスタントに、推奨される規約、保守性基準、およびベストプラクティスをまとめたSquish Rulesドキュメントを提供します。これにより、モデルはチームと一致した高品質なスクリプトを出力するよう促されます。
AIに最新のコンテキストを供給する
インデックスキーの参照先（例：Squish開発者ドキュメント、製品仕様書（例：AUTのUXフローやUIメタデータ）、記録されたスタブスクリプトとオブジェクトマップ）をAIにマッピングします。この検索機能強化されたコンテキストにより、アシスタントは有効なSquish API呼び出しを生成し、UIコンポーネントを正しく参照できます。
Squish モデル コンテキスト プロトコル (MCP) を使用します。
Squish MCP サーバーを活用し、AI アシスタントが Squish テストを直接実行（squishrunner CLI 経由）、結果ログを受信し、同じインタラクション内でスクリプトを反復的に最適化して再実行できるようにします。
テストスクリプトを反復的に生成し実行する
AIに「連絡先を追加するスクリプトを作成する」または「suite_xを実行して失敗を修正する」と指示すると、AIはコードを生成し、MCP経由でSquishに送信し、エラーを分析し、修正案を提案し、再実行を繰り返し、継続的なフィードバックループを確保します。
AIアシスタントを活用して柔軟性を維持する
このアプローチは特定のLLMプロバイダーに依存していないため、アシスタント（例：Cursor、Claude、Copilot）を交換したり、オープンソースモデルを採用したりしても、設定を中断することなく利用できます。
テスト資産の保存と再利用
生成されたSquish スクリプトはあなたの所有物です。これらのスクリプトを生成、維持、またはフレームワーク間で移植することが可能です。ベンダーロックインは存在せず、テストスイートは長期にわたって利用可能です。
このハイブリッドアプローチは、AIの俊敏性とSquishの深さと精度を組み合わせたものです。
生成AIはテストの作成と自動化を加速できますが、信頼性の高い結果を提供するためには構造化が必要です。
1. 実際のシステム環境で検証する
LLMはアプリ動作を誤解釈したり、不正なテストステップを生成する可能性があります。生成AIをSquishのようなテストツールやドメインデータ（例：ログ、UIマップ）と接続することで、出力結果を現実的で関連性の高いものに保つことができます。
2. 再現性を確保する
AIの応答は時間経過とともに変化する可能性があります。追跡可能性と再現性を確保するため、固定されたプロンプト、バージョン管理されたモデル、および人間のレビューを活用してください。
3. RAGを活用して関連性を向上させる
テスト資産、要件、変更履歴、スクリプトを、検索拡張生成（RAG）を介して生成AIに投入することで、テスト提案の精度が向上し、システムとの整合性が確保されます。
要するに、生成AIが最も効果的なのは、QAエコシステムに組み込まれて使用される場合であり、単独で使用される場合ではありません。
生成AIは、ソフトウェアテストツールセットに強力な追加機能を提供します。しかし、それは構造化されたツールベースのテスト自動化の代替品ではありません。適切に使用されると、AIは人間のテスターの創造的かつ分析的な強みを強化し、SquishのようなGUIテストツールは、本格的なテスト自動化に必要な制御性、正確性、プラットフォーム統合を提供します。
GUIテスト自動化、Qtアプリケーションテスト、または探索的テストワークフローに焦点を当てている場合でも、最も効果的な戦略は、AIを活用した洞察とSquishのような信頼性の高いツールを組み合わせることです。
Squish を使用すれば、AIだけでは提供できないものを手に入れることができます：
オブジェクトレベルの UI インタラクション: Squish はピクセルだけを見るのではありません。UI コンポーネントの内部プロパティを介して UI コンポーネントと相互作用します。
Qt、QML、および組み込み UI のサポート：Squish は、従来の自動化ツールや AI だけでは不十分なプラットフォーム向けに特別に設計されています。
安定したテスト実行：Squish のテストケースは、UI の変更があっても再現性が高く、メンテナンスが容易です。
Gherkin とのシームレスな統合：Squish は振る舞い駆動型テスト (BDD) をサポートしており、AI によって生成された Gherkin を構造化された自動化に簡単に変換できます。
こちらをお読みください：
AIアシスタントを活用したSquishテストスクリプト生成の実践ガイド
パネルディスカッション「品質保証における AI の可能性を最大限に引き出す」をご覧ください。AI 実践者による洞察をご紹介します：
Peter Schneider：Qt Group 製品管理部門プリンシパル、
Maaret Pyhäjärvi：CGIF コンサルティング部門ディレクター、
Felix Kortmann：FORVIA HELLA CTO