replica-test

replica-test

replica/recon.md のフローを読み取ります。replica/test-plan.md、replica/bugs.md、およびプロジェクト内のエンドツーエンドテスト（e2e/）を作成します。このフォルダーには、テンプレートとして test-plan.md、bug-report.md、e2e.example.spec.ts があります。

ルール

テストするのはクローンであり、オリジナルではありません。 オリジナルアプリのサーバーに負荷テストやファジング、スクリプトによる操作、過剰なアクセスを行わないでください。通常のユーザーとして手動でオリジナルを使い、動作を確認するのは問題ありません。

ステップ 1：計画

偵察マップにあるすべてのフロー F01、F02... について、次の項目を記述します。

• 正常系：手順と、最後にユーザーに表示される内容。
• 該当するエッジケース。すべてのフローで次のリストを確認してください。 入力が空、入力が非常に長い、絵文字とアクセント記号、2 つのタブを同時に使用、送信をダブルクリック、フローの途中で戻るボタンを押す、フローの途中で更新、ネットワークが遅い、オフライン、セッションの期限切れ、別のユーザーのデータ（表示されてはいけません）、タイムゾーンと夏時間、モバイル幅、キーボードのみ、スクリーンリーダーのラベル。
• 異常系：パスワードが間違っている、カードが拒否される（Stripe テストカード 4000 0000 0000 0002）、権限が拒否される、レコードが削除されている。

各ケースに番号を付けます：F01-H1、F01-E3、F01-N2。

ステップ 2：自動化できるものを自動化する

Playwright を使い、シードデータを用意したローカル開発サーバーに対して、フローごとに 1 つの spec を作成します。セレクターにはロールとラベルを使い（getByRole('button', { name: 'Book' })）、CSS クラスは使わないでください。e2e.example.spec.ts を参照してください。

npm i -D @playwright/test && npx playwright install chromium
npx playwright test

すべての spec に、コンソールエラーが発生した場合の失敗、5xx レスポンスを受信した場合の失敗、および各画面での axe アクセシビリティスキャン（@axe-core/playwright）を追加します。

ステップ 3：残りを実際に操作する

自動化できないもの（メールの到着、実際のプロバイダーを使った OAuth、決済のエンドツーエンドテスト、視覚的な不具合）は、手動で確認します。ブラウザツールが使える場合は、それを使ってローカルのクローンを操作し、各ステップのスクリーンショットを撮ります。そうでない場合は、ユーザーにチェックリストを渡し、回答を待ちます。

ステップ 4：バグを報告する

すべてのバグを bug-report.md の書式で replica/bugs.md に記録します。ID、重要度、正確な手順、期待される結果、実際の結果、証拠を含めてください。重要度は次のとおりです。

	意味
S1	データ損失、セキュリティ上の欠陥、決済の誤り、主要なフローがブロックされる
S2	機能が壊れており、回避策がない
S3	回避策がある不具合、または目に見える誤り
S4	見た目だけの問題

再現できたものだけを報告してください。「問題の可能性あり」は、別の「要確認」リストに記載します。

ステップ 5：修正ループ

まず S1 と S2 を修正します。修正ごとに、先に失敗するテストを書き、修正して、テストが成功することを確認し、そのテストを残します。各修正バッチの後に、スイート全体を再実行します。修正した各バグについて、修正したコミットを bugs.md に記載します。

成果物

test-plan.md、spec、bugs.md、およびサマリー（実行したケース数、成功数、失敗数、重要度別のバグ数、これまでに修正したバグ）。未解決の S1 がある状態でリリースしてはいけません。次へ：/replica-diff