TestSprite は PRD や製品要件からテストを生成できますか？
Zeshi Du
はい。そして、これは TestSprite のアプローチがコード由来のテスト生成とは意味のある違いを生み出す場面の一つです。
PRD からテストが生成される場合、テストの目標は製品が何をすべきかに基づいて定められます。現在の実装がたまたま生成する結果ではありません。この違いが、テストスイートがバグを検出するか、それともバグを組み込んでしまうかを決定します。
コード由来テストの問題点
ほとんどのテスト生成ツールはコードから始めます。実装を読み取り、関数が返す値をトレースし、コンポーネントがレンダリングする内容を検査し、コードが現在行っていることに基づいてアサーションを生成します。
このアプローチには、AI コーディングエージェントが関与する場合に最も明確に現れる特定の障害モードがあります。
AI コーディングエージェントがある機能を生成します。その機能には微妙なバグがあります。割引計算が税抜き小計に適用されていますが、PRD では税込み後に適用すべきと規定されています。コードは内部的に一貫しています。すべての関数は設計通りに動作しています。コード由来のテストは実装を読み取り、税抜き割引ロジックを確認し、税抜き前に割引が適用されているというアサーションを記述します。テストは合格します。バグは正しい動作として組み込まれてしまいます。
誰かが PRD を読んで実装がそれと一致していないことに気づかない限り、テストスイートはそのバグに永久に同意し続けます。
PRD 駆動のテスト生成はこれを防ぎます。テストの目標が PRD に基づいている場合、テストは割引が税込み後に適用されるべきであることを認識しています。税抜き前に適用する実装は、正しくテストを失敗させます。
TestSprite が PRD を解析する方法
PRD または仕様書が利用可能な場合、TestSprite はそれを解析し、含まれる要件から構造化されたインテントモデルを構築します。
そのモデルは製品が何をすべきかを捕捉します。ユーザーが完了できるべきフロー、それらのフローが生み出すべき結果、システムが許可すべきことと許可すべきでないこと。このモデルがテスト生成のアンカーとなります。
そのアンカーをもとに、TestSprite の探索エージェントは実際に動作するアプリケーションを訪問し、実際のユーザーと同様にナビゲートします。コードが正しく実行されることを検証するだけではありません。製品が PRD に記述された内容を提供しているかどうかを検証します。
他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。
探索において PRD が規定した内容と製品が提供する内容との間に乖離が見つかった場合、その乖離は失敗として浮上します。コードレベルのアサーションエラーではありません。動作上のギャップです。製品は X を行うべきところ、代わりに Y を行っています。
「PRD 駆動」がテストケースに意味するもの
PRD から導出されたテストは、実装の詳細ではなく、製品のインテントという観点でユーザーのアクションと製品の結果を記述します。
コードから導出されたテストはこのようにアサートするかもしれません。「チェックアウト関数がステータスコード 200 と注文 ID を含むレスポンスボディを返す。」
PRD から導出されたテストはこのように述べます。「ユーザーが有効な支払い方法でチェックアウトを完了したとき、正しい注文合計を示す注文確認画面が表示され、ユーザーの注文履歴に新しい注文が反映されるべきである。」
これらは異なるテストです。前者は関数が正しく実行されれば合格します。後者は、PRD が規定した体験を製品がエンドツーエンドで実際のアプリケーション上で提供した場合にのみ合格します。
後者のテストは、実際のユーザーが体験する障害をより捕捉しやすくなっています。また、より耐久性があります。実装がリファクタリングされても製品の動作が変わらない場合、コード由来のテストは壊れて更新が必要になりますが、PRD 由来のテストはチェックしている結果が変わっていないため引き続き合格します。
生成開始前のプランクロージャープレビュー
TestSprite が PRD からテストを生成する前に、プランクロージャープレビューを表示します。これは、どのテストプランが他のプランに依存しているか、何がカバーされるかを明確に示すマップです。
これにより、エンジニアはテスト生成が始まる前に提案されたカバレッジをレビューできます。どの PRD 要件がどのテストシナリオに変換されているかを確認できます。現在のテスト実行に関係のないシナリオを選択解除できます。本当に必要なものが欠けている場合にのみ警告が表示されます。
何がカバーされるかはチームが管理します。要件からテストケースへの変換はエージェントが担います。
シナリオ：PRD 駆動テストが実装の乖離を検出する
製品チームがサブスクリプション管理機能の PRD を作成します。要件には以下が含まれます。
- ユーザーはいつでもプランをアップグレードできる
- ユーザーはプランをダウングレードできるが、請求サイクルの終了時のみ可能である
- ダウングレード時には、変更の発効タイミングを説明する確認モーダルを表示する必要がある
- ダウングレード後、現在のプランは請求サイクルが終了するまで有効であり続ける必要がある
開発者はClaude Codeを使用してこの機能を実装する。コードは社内レビューを通過し、実装から生成されたテストにより、ダウングレードAPIの呼び出しが成功すること、および確認モーダルが表示されることが検証される。
TestSpriteはPRDを解析し、記載された要件に基づいたテストを生成する。
エージェントは、実際にダウングレードを行うユーザーと同様にダウングレードフローをナビゲートする。ダウングレードを開始し、確認モーダルを読み、ダウングレードを確定し、アカウント設定を確認する。
モーダルが表示された。ダウングレードが確定された。エージェントは次に確認する：アカウント設定ページには、現在アクティブなプランとして何が表示されているか？
アカウント設定には、請求サイクル終了まで有効であるべき現在のプランではなく、ダウングレード後のプランが即座にアクティブなプランとして表示されている。実装はダウングレードの処理自体は正しく行ったが、請求サイクルが終了するまでは現在のプランをアクティブとして表示すべきところ、表示プランを即座に更新してしまっている。
PRDには明確に記載されていた：現在のプランは請求サイクルが終了するまで有効であり続ける。コードから導出されたテストは、ダウングレードAPIが正しいステータスを返すことを検証した。しかし、アカウント設定が要件を正しく反映しているかどうかは一切検証されていなかった。
失敗の詳細は構造化された形式でClaude Codeのターミナルに返される。コーディングエージェントはアカウント設定の表示ロジックが正しいフィールドを参照していないことを特定し、修正を適用する。エージェントがフローを再実行すると、アカウント設定には現在のプランが正しくアクティブとして表示されるようになった。
PRDが存在しない場合の対応
多くのチーム、特に小規模なチームや初期段階のチームには、正式なPRDが存在しない。あるのは機能のアイデア、Slackのスレッド、そしてデザインモックだけだ。
PRDが存在しない場合でも、TestSpriteは止まらない。MCP Serverはコードベース自体から製品の意図をリバースエンジニアリングする。ルート定義、APIコントラクト、コンポーネント構造、命名規則を、製品が何を実現するために設計されたかを示す根拠として扱う。
これにより得られるインテントモデルは、明示的なPRDから導出されたものと比べると精度は低くなるが、それでもテストの目標を現在の実装が生み出す結果ではなく、推測された製品の意図に基づいて定めることができる。コードから導出されたテストが「正しい動作」として組み込んでしまうバグを、引き続き検出できる。
PRD主導の完全な精度を求めるチームには、機能を実装する前に軽量なPRDを書くという習慣が有効だ。数文の要件を記述するだけでも、TestSpriteが正しい成果を検証するテストを生成するための基準点を与えることができる。
まとめ
TestSpriteはPRDや製品要件からテストを生成できる。PRDから生成されたテストは実装の詳細ではなく製品の意図に基づいているため、コードから導出されたテストが正しい動作として組み込んでしまうバグを検出できる。
プロセスはシンプルだ：PRDを提供し、Plan-Closure Previewでカバレッジを確認し、探索エージェントがライブアプリケーションをナビゲートして、製品が要件通りの成果を提供しているかを検証する。
PRDが存在しない場合、TestSpriteはコードベースから意図を推測し、その推測に基づいてテストを生成する。カバレッジの精度は下がるが、それでも実装ではなく意図に基づいて構築される。
AIコーディングエージェントが要件に基づいて機能を実装しているチームにとって、PRD主導のテストは、実装が求められたものを実際に提供しているかを確認するための検証手段となる。
今すぐTestSpriteでPRDからのテスト生成を始めよう。