test

テスト

重要な振る舞いを証明します。ビルドの成功やソースコードの確認は証明を裏付けることはできますが、どちらもユーザーに見えるフローを証明するものではありません。

プロセス

1. タスク、存在する場合はそのソース仕様、変更されたコード、既存のテスト、リポジトリの指示を確認します。受け入れ基準はタスクまたはレビュー済みの仕様から取得します。その文言と AC-n、REQ-n、INV-n の ID を維持します。コードに合わせて基準を書き換えてはいけません。
2. すべての受け入れ基準、引用された不変条件、影響を受ける失敗経路を ID ごとに証明へ対応付けます。変更された振る舞いと、リファクタリング後も維持すべき振る舞いをテストします。
3. 自動テストで影響を受ける振る舞いを検証できない場合は、その理由を説明し、代わりとなる証拠を示します。
4. 証明が不足している場合は、対象を絞ったテストを追加または更新します。変更された振る舞いが壊れたときに失敗するアサーションにします。
5. テストが文書化された内部契約を対象とする場合を除き、ユーザーまたは呼び出し元が確認できる振る舞いをアサートします。セットアップとアサーションは、シナリオを検証するのに必要な範囲にとどめます。
6. 変更された振る舞いと影響を受けるインターフェースを検証する、最も対象を絞ったチェックを実行します。共有の振る舞いやインターフェースを変更した場合は、より広範なチェックを実行します。
7. ブラウザーで表示される振る舞いを変更した場合は、文書化されたアプリを起動し、実際のブラウザーで必要なフローと影響を受ける失敗ケースを確認します。
   • レイアウトまたはレスポンシブスタイルを変更した場合は、デスクトップとモバイルの両方を確認します。
   • インタラクションを変更した場合は、キーボード操作を確認します。
   • 各フローの実行中に、コンソールエラーと失敗したリクエストを確認します。
   • 証拠を記録します。ソースコードの確認はブラウザーでの証明にはなりません。
8. 各 AC-n、REQ-n、INV-n、またはタスクの基準について、合格、失敗、または未検証として報告します。コマンド、ブラウザーフロー、またはその他の証拠を記載します。

返却内容

各基準を次の形式で報告します。

Criterion: <ID or exact wording>
Result: Pass / Fail / Unverified
Evidence: <command, browser flow, or artifact>
Gap: <what remains unknown, or None>

失敗した基準と未検証の基準を最初に記載します。合格したチェックの下に隠してはいけません。

制約

• 変更を合格させるためにアサーションを弱めてはいけません。
• 無関係な失敗を修正してはいけません。
• 必須のブラウザーツールを利用できない場合、ユーザーが手動での例外を明示的に認めていない限り、そのチェックはブロックされたと報告します。