AIはダッシュボードのビジュアル状態をテストできるか？
Zeshi Du
ダッシュボードは、Webアプリケーションの中でも最もテストが困難なサーフェスの一つです。
技術的に複雑だからというわけではありません（実際に複雑なものも多いですが）。その正確性が根本的にビジュアルかつコンテキスト依存であるからです。エラーなくレンダリングされたダッシュボードでも、誤ったデータを表示したり、解決されないローディング状態を示したり、ウィンドウのリサイズ時にチャートが崩れたり、データが存在するのに空の状態を表示したりすることがあります。これらの不具合はいずれも例外をスローしません。スタックトレースも生成しません。プロダクトを使う人が見て、「おかしい」と気づくだけです。
コードレイヤーのテストではそれを検出できません。コンポーネントがレンダリングされた、APIコールがデータを返した、状態変数が正しく更新されたというアサーションは、実際のブラウザセッションで実際のユーザーにとってダッシュボードが正しく表示され、正しく動作しているかどうかを何も教えてくれません。ダッシュボードのビジュアル状態に関するバグが潜むのは、まさにそのギャップです。
ダッシュボードにおける「ビジュアル状態」とは何か
ダッシュボードのビジュアル状態とは、ユーザーが任意の瞬間に目にするUIコンディションの特定の組み合わせです。単に「ダッシュボードがレンダリングされた」ということではありません。どのパネルが表示されているか、データがロード済みかローディング中か、フィルターが適用されているか、選択された時間範囲がチャートに反映されているか、ロールベースのパネルが適切なユーザーに表示され、他のユーザーには非表示になっているか、といった条件の組み合わせです。
これらの条件のそれぞれがビジュアル状態です。そして、ダッシュボードには通常、多くのビジュアル状態があります。
データがまだ存在しない場合の空の状態。データ取得中のローディング状態。データソースが利用できない場合のエラー状態。ユーザーがビューを絞り込んだ場合のフィルタリング状態。特定のパネルが管理者ユーザーにのみ表示されるロール制限状態。ビューポートが狭まりレイアウトがリフローするレスポンシブ状態。ライブデータがストリーミングされチャートが更新されるリアルタイム状態。
ダッシュボードのビジュアル状態をテストするとは、これらの各コンディションが正しいビジュアル結果を生成すること、状態間の遷移が正しく処理されること、そしていかなる状態の組み合わせも壊れた表示や誤解を招く表示を生じさせないことを検証することを意味します。
状態は非常に多岐にわたります。そして、それらを検証する唯一の方法は、実際にコンディションを作り出し、ダッシュボードが何を表示するかを観察することです。
コードレイヤーツールがダッシュボードの実際の表示をテストできない理由
コードレイヤーツールは、コンポーネントツリーを読み取ることでダッシュボードにアプローチします。チャートコンポーネント、フィルターコンポーネント、データ取得ロジックを検出します。そして、それらのコンポーネントが正しいpropsを受け取ること、データ取得関数が正しいパラメータで呼び出されること、選択された時間範囲を追跡する状態変数がフィルター適用時に更新されることを確認するアサーションを生成します。
これらのアサーションは、ダッシュボードのロジックが正しく実装されていることを確認します。しかし、ダッシュボードが実際に何を表示しているかは確認できません。
正しいデータを受け取るチャートコンポーネントでも、データ形式がチャートライブラリの期待と合わない場合、空白でレンダリングされることがあります。状態変数に正しく紐づいたローディングスピナーでも、特定のネットワーク条件下で変数がロード済み状態に遷移しない場合、永遠に表示され続けることがあります。コンポーネントの条件付きレンダリングロジックで正しく非表示にされているパネルでも、ロールチェックが解決される前の初回レンダリング時に一瞬表示されることがあります。
これらはいずれもコードレイヤーのアサーションには現れません。しかし、実際のユーザーがダッシュボードを見たときにはすべて目に入ります。
ビジュアル状態のテストには、ダッシュボードを観察することが必要です。それを記述するコードを読むことではありません。
TestSpirteがダッシュボードのビジュアル状態を観察する方法
TestSpirteは、実際のユーザーと同じようにライブアプリケーションにアクセスして操作することで、ダッシュボードのビジュアル状態をテストします。
他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。
並列探索エージェントの群れがダッシュボードに移動し、初期状態を観察します。何が表示されているか、何がローディング中か、何が存在しないかを確認します。フィルターを操作してビジュアル状態がどのように反応するかを観察します。チャートが更新されるか、アクティブなフィルターインジケーターが表示されるか、時間範囲の選択が表示内容を変えるかどうかを確認します。必要に応じてコンテキストをリサイズし、レスポンシブレイアウトが正しくリフローするか、データが隠れるような崩れ方をしないかを観察します。
ロールベースのダッシュボードでは、エージェントは異なる認証コンテキストで動作します。管理者ロールのエージェントがダッシュボードに移動して表示されているパネルを確認し、閲覧者ロールのエージェントが同じダッシュボードに移動して正しく非表示になっているパネルを確認します。管理者のみに制限されるべきパネルが閲覧者にも表示された場合、それはビジュアル状態の失敗です。常に表示されるべきパネルが特定のロールで欠如している場合も、同様にビジュアル状態の失敗です。
これは、新しいダッシュボード機能を初めてウォークスルーするQAエンジニアのテスト行動です。コンポーネントツリーを調査するのではなく、異なる条件下でダッシュボードを確認し、ロールを切り替え、フィルターを適用し、データのロードを待ち、何かおかしいと感じたときにメモします。
状態遷移は状態そのものと同じくらい重要
ダッシュボードは、各状態が個別に正しくレンダリングされていても、状態間の遷移で失敗することがあります。
ローディング状態は正しく表示される。ロード済み状態も正しく表示される。しかし、ローディングからロード済みへの遷移でレイアウトシフトが発生し、フィルターパネルが表示ビューポート外に押し出されてしまう。データのロードが完了する前に使用していたフィルターにアクセスするには、スクロールが必要になる。
空の状態は正しく表示される。データが現れた瞬間、空の状態パネルは消え、データが入ったダッシュボードに置き換わるはずです。しかし、空の状態が消去される前に一瞬、両方の状態が同時にレンダリングされる。
単一フィルターに対してはフィルタリング状態が正しく表示される。しかし、2つのフィルターが同時に適用されると、一方のフィルターインジケーターは表示されるが、もう一方は表示されないというビジュアル状態になる。両方ともアクティブであるにもかかわらず。
これらは遷移バグです。エージェントが適切なコンディションを作り出し、状態変化の最中と直後に何が起きるかを観察することでのみ検出できます。最終状態がどのように見えるかだけを確認するのでは不十分です。
TestSpirteの探索エージェントは、状態を単独でスナップショットするのではありません。コンディションを作り出し、何が変化するかを観察し、プロダクトが状態間のジャーニーをビジュアル的に正しく処理することを検証します。フィルターが適用されると、エージェントは完全なシーケンスを観察します。ローディングインジケーターが表示され、データが更新され、ローディングインジケーターが消え、フィルターインジケーターがアクティブ状態で表示される。そのシーケンスにギャップがあれば、それはビジュアル状態の失敗です。
データ依存のビジュアル状態には実データが必要
最も重要なダッシュボードのビジュアル状態の多くは、特定のデータコンディション下でのみ現れます。特定のクエリがゼロ件の結果を返したときにのみレンダリングされる空の状態。メトリクスが閾値を超えたときにのみ表示される警告状態。ユーザーが2つの期間を同時に選択したときにのみ有効になる比較ビュー。
コード検査からこれらの状態をテストするには、適切なデータコンディションをモックする必要があります。そのためには、どのコンディションをモックすべきかを事前に把握している必要があり、それにはコード検査が提供できないような探索的な知識が必要です。
TestSpirteのBackend Testing 2.0は、UIレイヤーと同じ方法でデータレイヤーをカバーします。アサーションを行う前に実際の動作を観察するのです。APIデータに依存するダッシュボードのテストプランを生成する前に、エージェントはデータエンドポイントを実際に呼び出し、何が返ってくるかを観察します。実際のレスポンスの形状、実際のフィールド名、実際の空の状態、エラーレスポンス、部分的なデータコンディションを確認します。
ダッシュボードのビジュアル状態がAPIの空の配列の返却に依存している場合、エージェントは実環境でそのコンディションを作り出し、ダッシュボードの反応を観察し、空の状態が期待通りにレンダリングされることを検証します。あるデータソースが利用できないためにAPIが部分的なレスポンスを返す場合、エージェントはダッシュボードがデグレードしたデータをどのように処理するかを観察し、そのビジュアル状態が壊れた表示ではなく情報を提供するものであることを検証します。
実際のレスポンスから取得した動的変数は、マルチステップのデータシナリオを通じて自動的に受け渡されます。データを作成し、ダッシュボードに移動し、作成したデータが表示されることを検証するダッシュボードテストは、作成ステップから検証ステップへ実際のリソースIDを渡します。
AIコーディングの変更後もビジュアル状態カバレッジを最新に保つ
ダッシュボードは頻繁に変更されます。新しいパネルが追加され、フィルターが更新され、ロールベースの表示ルールが調整され、チャートの種類が入れ替わります。CursorやClaude CodeでのAIコーディングセッションでは、1回のセッションで複数のダッシュボードコンポーネントに変更が加えられることがあります。
こうした変更のひとつひとつが、ビジュアル状態のリグレッションを引き起こす可能性があります。レスポンシブレイアウトのルールを更新せずに追加された新しいパネルは、フル幅では正しくレンダリングされても、より狭いビューポートでは他の要素と重なってしまうかもしれません。単一選択では正常に動作していたフィルターの更新も、複数のフィルターを組み合わせると未定義のビジュアル状態を引き起こす可能性があります。
TestSpriteのAuto-Heal Rerunがメンテナンス層を担います。ダッシュボードの更新によってテストが失敗した場合、エージェントはその失敗が本当のビジュアル状態リグレッションなのか、根本的な動作に影響しないレイアウト変更なのかを判断します。フィルターパネルの位置変更、チャートヘッダーのスタイル変更、ロールインジケーターのリデザインなど、テストは誤検知で失敗することなく自動的に適応します。
Claude Code、Cursor、またはWindsurf内のTestSprite MCPサーバーを通じて、ビジュアル状態テストのパイプライン全体をひとつの指示から実行できます。GitHub Actionsインテグレーションを通じて、すべてのプルリクエストでビジュアル状態カバレッジが実行されます。ビジュアル状態のリグレッションを引き起こす変更は、ユーザーに届く前にCIで検出されます。
Auto-Authがロールベースのビジュアル状態テストにおける認証層を担います。AdminとViewerのロールコンテキストは、すべての実行にわたって自動的に維持されます。スケジュールされたリグレッションは、新鮮な認証情報を使ってすべての関連ロールをテストします。
まとめ
AIはダッシュボードのビジュアル状態をテストできます。ただし、それはソースコードが記述する方法ではなく、実際のユーザーが目にする方法でダッシュボードをテストしている場合に限ります。
コード層のツールは、ダッシュボードコンポーネントが正しいデータを受け取っているかを確認できます。しかし、実際のユーザーが直面する条件下でダッシュボードが正しく表示されているかどうかは確認できません。その条件とは、異なるロール、異なるデータ状態、異なるフィルターの組み合わせ、異なるビューポートサイズ、そしてそれらすべての間の遷移です。
TestSpriteは、実際の条件下でライブアプリケーションをナビゲートすることで、ダッシュボードのビジュアル状態を観察します。探索エージェントはフィルターを適用してその応答を観察します。異なるロールコンテキストで動作し、表示ルールが正しいビジュアル結果を生成することを検証します。データ条件を作成し、ダッシュボードがそれらを正しく処理するかを確認します。個々の状態だけでなく、状態遷移も観察します。
AIコーディングの頻繁な変更とともにダッシュボードロジックが進化するAIネイティブなチームにとって、自動的に実行され常に最新の状態を保つビジュアル状態カバレッジは、壊れたダッシュボードをリリース前に検出できるかどうか、あるいはデータを読み取れないユーザーからの報告で初めて気づくかどうかの分かれ目になります。
今日からAI IDEの中でTestSpriteを使って、ダッシュボードのビジュアル状態テストを始めましょう。