同一のプロダクト要件からUIテストとAPIテストを生成する方法
Zeshi Du
ほとんどのチームは1つの機能に対して1つのPRDを書き、テストが実施される場合でも、誰かがそれをUIテストに変換し、別の人、または別の日の同じ人がAPIテストに変換します。これら2つの変換は、別々に行われ、場合によっては異なる人が同じドキュメントを参照しながら互いに参照し合わないため、しばしば乖離が生じます。
ここでは、AIテストケースジェネレーターが1つのPRDから両方を直接生成し、設計上同期が保たれる方法を紹介します。
別々の変換がずれていく理由
PRDは要件を1度だけ記述します。「ユーザーはプロフィール写真を更新できる」というように。UIテストを書く人はその文を読み、アップロードボタン、ファイルピッカー、プレビュー状態について考えます。APIテストを書く人は同じ文を読み、アップロードエンドポイント、ファイルサイズ制限、ストレージのレスポンスについて考えます。
どちらも合理的な解釈ですが、各レイヤーが処理すべき具体的なエッジケースについて、たとえばサイズオーバーのファイルに何が起こるか、またはAPIがアップロードを拒否した場合にUIが表示すべきエラー状態について、両者が一致することを強制するものは何もありません。この乖離は時間とともに拡大します。PRDが小さく更新され（「ドラッグ＆ドロップアップロードもサポートする」）、UIテストスイートは更新されてもAPIテストスイートは更新されないということが起こりがちです。これが、TestSpriteのPRD駆動生成が解消するために設計された具体的な乖離です。
TestSpriteが1つのソースから両方を生成する方法
“他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。”
TestSpriteは要件ドキュメントから正規化された内部PRDを構築し、元のテキストを2回独立して読み解くのではなく、その同じ正規化されたソースからUIとAPIのテストケースを生成します。MCPサーバーを通じて、これは1回のパスで行われ、互いに比較されることのない2つの別々のプロセスとしてではなく実行されます。
実践的な手順
エージェントにPRDを一度指定します。正式な仕様書であれ、簡単なドキュメントであれ、この単一のアップロードが両方のレイヤーのソースになります。
インタラクションとエラー状態をカバーするUIテストケースを生成させます。写真アップロード機能であれば、ファイルピッカー、プレビュー、そして拒否されたアップロード時にユーザーが見る状態が含まれます。
エンドポイントの実際のコントラクトをカバーするAPIテストケースを、実際に観測された動作に基づいて生成します。UIテストが期待する内容からアップロードエンドポイントの戻り値を推測するのではなく、TestSpriteのバックエンドテストは実際のレスポンス、実際のステータスコード、実際のエラーペイロードを観測し、そこからアサーションを生成します。また、サイズ制限の要件をUIのエラー処理動作から推測するのではなく、APIに対して直接検証するのもここです。
生成された2つのスイートを、PRDに対して個別にチェックするだけでなく、互いにクロスチェックします。UIテストがサイズオーバーのアップロードに対して特定のエラーメッセージを期待し、APIテストが実際のレスポンスで異なる文言のエラーを観測した場合、その不一致は、UIが実際のバックエンドのエラーを正しく表示できずにサイレントに失敗するという本物のバグになる前に捉える価値があります。
要件が変更されるたびに両方を再実行します。両方のスイートが同じ正規化されたPRDにトレースされているため、新機能のカバレッジを追加したり既存のものを更新したりする場合（たとえばファイルサイズ制限を10MBに引き上げる）、2つの別々の場所を手動で覚えて更新する必要なく、その制限を参照するUIテストとAPIテストの両方を再生成またはフラグ付けするはずです。
最も重要な場面
このアプローチは、UIとAPIが具体的な内容で本当に一致する必要がある機能、つまりバリデーションルール、エラーメッセージ、ユーザーが実際に遭遇するエッジケースの動作において、最も明確な効果を発揮します。バックエンドのロジックがほとんどない静的ページのように、UIとAPIが些細な形でしか接続されていない場合は重要性が低いため、レイヤー間のコントラクトに実際にリスクがある箇所に最も注意を払う価値があります。
同じ論理は、そもそも最も精密に書くべき要件にも適用されます。曖昧な要件は両方のレイヤーで曖昧なテストを生成し、その2つの曖昧なテストは、本当に具体的な要件から生成された精密なペアよりも、偶然に互いと一致する可能性が高くなります。これは信頼すべき偶然ではありません。
現在のテストがすでにズレていないかを素早く確認する方法
UIテストとAPIテストを別々に維持している場合は、まだ同期が取れていると仮定する前に、簡単な監査を行う価値があります。両方のレイヤーに関わる2〜3つの要件を選び、各テストスイートがチェックするエラーメッセージ、フィールド名、エッジケースが、PRD単独に対してだけでなく、互いに実際に一致しているかどうかを確認してください。しばらく運用されているプロジェクトでは、要件変更後に一方のスイートは更新されたが他方は更新されていないという状況がよく見られます。
正式な引き継ぎプロセスがないチームでの実態
小規模チームでは、フロントエンドとバックエンドのテストスイートを同期させるための文書化されたプロセスが存在しないことが多いです。そのようなプロセスは通常、調整のための明示的なコントラクトが必要なフロントエンドとバックエンドの独立したサブチームを持つ大企業に存在します。小規模チームでは、その同じ規律の非公式版は単純にこれです。一人の人物が要件の実装を更新する際には、それに紐付いたUIテストとAPIテストの両方が依然として意味をなすかどうかも必ず確認するということです。
共有ソースから両方を生成することで、締め切りのプレッシャー下で忘れがちなその規律の部分を自動化できますが、要件の変更をデフォルトで両方のレイヤーに影響するものとして扱うという根本的な習慣は、ツールがメカニクスを処理するようになった後も維持する価値があります。これは、優れたQAエンジニアがレビュープロセスを通じて強制していたのと同じ習慣を、より早い段階でオーバーヘッドを減らして適用したものです。
まとめ
2つの独立して維持された解釈からではなく、同じ要件ドキュメントからUIテストとAPIテストを生成することで、フロントエンドチームとバックエンドチームが同じ機能をそれぞれどのように理解するかの間に忍び込む乖離を解消できます。
TestSpriteは、あなたが書いたPRDであれ、コードベースから直接推論されたPRDであれ、単一の正規化されたPRDから両方のレイヤーを生成します。ご自身のPRDで無料でお試しいただき、現在のUIとAPIのカバレッジがすでに互いに一致しているかどうかを確認してください。切り替える前にその簡単な監査を実行することが、統一されたワークフローが何を捉えていたかを確認する最も明確な方法であることが多いです。