TestSpriteはどのようなテストレポートを提供しますか?
テストレポートの価値は、読んだ後に何ができるかにあります。
「47行目でアサーションXがfalseと評価されました」と伝えるレポートは、有用な情報を得るまでに調査が必要です。一方、「ユーザーが割引コードを適用後にチェックアウトを完了しようとしたところ、注文確認ページが表示されませんでした」と伝えるレポートは、何を修正すべきかを直接示しています。
TestSpriteのレポートは後者のモデルに基づいて構築されています。すべての結果はプロダクトレイヤーの言葉で説明されます。実行されたユーザーアクション、プロダクトが本来提供すべきだったもの、そして実際に起きたこと。このフレームにより、開発者がテスト出力をプロダクトの問題に翻訳することなく、レポートをそのままアクションに結びつけられます。
IDE内レポート:コーディングエージェントのための構造化障害情報
TestSpriteのセッションがTestSprite MCP Server経由でCursor、Claude Code、Windsurf、またはVS Code内で実行されると、結果はIDEのチャットインターフェースに返されます。
他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。
エージェントはライブアプリケーションをナビゲートして実際のプロダクト動作を観察しているため、障害レポートは実際のプロダクト動作を記述します。関数の戻り値やアサーションの不一致ではありません。実行されたユーザーアクション、期待されたプロダクトの結果、そして実際の結果です。
この形式は、IDE内のAIコーディングエージェントのために特別に設計されています。Claude CodeやCursorが「エージェントが請求セクションに移動し、プランのアップグレードを開始したが、アップグレードが確定した後もアカウント設定ページは引き続き無料プランを表示していた」という障害の説明を受け取ると、コーディングエージェントは問題を特定し、同じセッション内で修正案を提案するのに十分なコンテキストを持ちます。
それがループを完結させるレポートです。開発者が読んでから対応するレポートではありません。コーディングエージェントが直接対応するレポートです。
Webポータルダッシュボード:経時的な品質トレンド
TestSprite Webポータルは、セッション、プロジェクト、チームメンバーをまたいだテスト履歴の永続的なビューを提供します。
各テスト実行は、テストされたフロー、合格したもの、失敗したもの、障害の説明の内容を含む完全な結果セットとともにログに記録されます。実行履歴により、チームはセッション間で結果を比較し、経時的な品質トレンドを追跡できます。
スケジュール実行の「前回との変更点」列には、現在の実行と直前の実行の間でステータスが変化したテストが一目でわかるように表示されます。2週間合格し続けていて突然失敗したテストは、継続的に緑のテストとすぐに区別できます。この区別は調査のトリアージにおいて重要です。突然の失敗こそが注目に値するものです。
複数のプロジェクトを管理するチームには、Webポータルがすべてのプロジェクトを横断した統合ビューを提供します。品質トレンド、実行履歴、テストプランの管理がプロジェクトごとおよびアグリゲートで利用できます。
PRコメント:差分と並んだカバレッジ
プルリクエストに対してGitHub Actionsインテグレーション経由でテストが実行されると、結果はレビュー開始前にPRコメントとして投稿されます。
レビュアーは差分と並んでテストカバレッジを確認できます。別のツールではなく、コード変更が存在するプルリクエスト内で直接確認できます。
PRコメントには、テストされたフロー、合格したもの、失敗したものが表示されます。障害の説明は同じプロダクトレイヤーのフレームを使用します。ナビゲートされた内容、期待された内容、実際に起きたこと。レビュアーは独自に調査することなく、障害の説明を読んで何が壊れたかを理解できます。
プルリクエストがClaude CodeやCursorセッションのアウトプットを含むことが多いAIネイティブなチームにとって、これはすべてのPRが承認される前にプロダクトレイヤーのカバレッジを持つことを意味します。差分はコードの変更点を示します。TestSpriteのコメントは、コードの変更がユーザーにとって何かを壊していないかを示します。
障害メール:ダッシュボードなしの朝のサマリー
スケジュールされたリグレッションに対して、TestSpriteは失敗した各テストの原因をAIが作成した説明とともにインラインで含む障害メールを送信します。
朝にメールを確認するエンジニアは、何が壊れたかを把握するためにダッシュボードにログインする必要がありません。メールには障害の説明と推定原因が記載されています。夜間実行で3件の障害が検出された場合、メールにはそれぞれの内容が記載されているため、ノートパソコンを開く前にトリアージを行えます。
これは「Smarter Schedules」の一部です。リアルタイムでダッシュボードを監視する人がいない無人実行向けに設計されたレポートレイヤーです。Webポータルの「前回との比較」列と、障害メール内のインライン原因説明を組み合わせることで、朝のレビュー時に何に対応が必要で何が不要かを判断するのに十分なコンテキストが得られます。
バックエンドテストレポート:具体的かつ観測可能
Backend Testing 2.0で生成されたバックエンドAPIテストの障害レポートには、特定の構造があります。
APIコントラクトが壊れた場合、レポートはどのエンドポイントで、どのフィールドが変更され、以前に観測されたレスポンスに何が含まれていて、現在のレスポンスに何が含まれているかを特定します。障害は具体的に示されます。「テストが失敗した」ではなく、「エンドポイントがこれまでuserIdを返していたのに、現在はtxIdを返すようになり、後続のテストステップが古いフィールド名を渡し続けていた」という形で記録されます。
CRUDライフサイクルの障害では、シーケンスのどのステップが失敗し、前のステップからどのデータが取得されていたかをレポートが示します。createコールが予期しない形式のIDを返し、その影響で後続のupdateコールが失敗した場合、レポートは両者を関連付けます。createステップが取得したID、updateステップが期待していた形式、実際に届いた値がそれぞれ明示されます。
この具体性により、レポートを読んだ開発者はどこを確認すべきかを正確に把握できます。ログを追跡する必要も、シーケンスを手作業で再構成する必要もありません。
資格情報の期限切れや依存関係が利用できないためにテストを実行できない場合、誤解を招く赤い障害表示ではなく、「Blocked(ブロック)」ステータスとわかりやすい説明が表示されます。朝のレビューで「製品が壊れた」のか「テスト環境に問題があった」のかを、調査なしに区別できます。
シナリオ:バグを修正した1つの障害説明
開発者がCursorを使用してアプリケーションのユーザープロフィールセクションを更新します。そのセッションで表示名の保存・取得方法が変更されます。プッシュ前に、開発者はCursor内からTestSpriteを起動します。
エージェントは、実際のユーザーがアカウントを更新するときと同じようにユーザープロフィールセクションをナビゲートします。表示名を更新して変更を保存し、アカウント概要ページに移動して変更が反映されていることを確認します。
障害レポートがCursorのチャットに届きます:
エージェントはユーザープロフィール設定に移動しました。表示名フィールドを「Alex Rivera」に更新しました。保存アクションは成功メッセージとともに完了しました。その後、エージェントはアカウント概要ページに移動しました。アカウント概要には、更新後の「Alex Rivera」ではなく、以前の表示名「Alex」が表示されていました。
製品はプロフィール設定で表示名を正しく保存しました。アカウント概要は、プロフィール保存時に更新されなかった別のキャッシュ値を参照しています。
Cursorのコーディングエージェントがこの説明を受け取ります。アカウント概要が参照するキャッシュを特定し、プロフィール保存ハンドラーがそれを無効化すべき箇所を見つけ、同じセッション内で修正を提案します。開発者はそれを適用し、TestSpriteを再度実行して確認します。
1つの障害説明。調査なしにバグを修正するための十分なコンテキスト。レポートはその役割を果たしました。
まとめ
TestSpriteのテストレポートには4つの形式があります。コーディングエージェントによる即時対応のためのIDE内構造化障害説明、品質トレンドと実行履歴のためのWebポータルダッシュボード、diffと並んだレビュー時のカバレッジのためのPRコメント、そして夜間リグレッションのトリアージのための障害メールです。
いずれも同じ基本フォーマットを共有しています。どのユーザー操作が行われ、製品が何を提供すべきで、実際に何が起きたかという製品レイヤーでの説明です。このフレームワークがレポートを実用的なものにしています。読み手がIDEセッション内のコーディングエージェントであっても、朝のスタンドアップ前にメールを確認している開発者であっても同様です。
今すぐAI IDEから、TestSpriteで実用的なテストレポートの生成を始めましょう。