test-report: テスト結果評価 + 完了基準判定

ISTQB/JSTQB のテストプロセス 7 活動のうち、テスト完了（test completion）の評価パートを担う 単機能スキル。テスト実行の記録（test-execution-log.md）を集約し、test-plan で定めた 完了基準（exit criteria） と突き合わせて、テストを完了とみなせるかを判定した テスト完了レポート test-summary-report.md を 1 本作る。

このレポートは 完了時の最終評価 にも テスト途中の中間評価（進捗の見える化・ 残作業の把握）にも使える。中間評価では「現時点で完了基準のどこを満たし、どこが未達か」を 示し、続行の判断材料にする。

このスキルは 結果の評価と完了判定だけ を行う。テスト条件の識別（test-analyze）・ ケース設計（test-design）・実装（test-implement）・実行と記録（test-execute）は各専用 スキルの担当で、ここでは呼び出さない。単発のテスト作成依頼（単にユニットテストを 1 つ 書きたいだけ）は対象外 — その場合は通常のコーディング支援で対応する。

このスキルが従う横断原則

testing-skills 全 8 スキル共通の原則。

1. ファイル規約 + 任意入力

• 成果物の既定パスは docs/test/<テスト対象名>/test-summary-report.md。
• プロジェクト側（CLAUDE.md / AGENTS.md 等）に成果物の配置規約があればそちらを優先する。 着手前にリポジトリを調べ、既存の docs/ 構成やテストドキュメントの慣習に合わせる。
• 前工程の成果物 test-execution-log.md（test-execute） と test-plan.md（test-plan） が 規約パスにあれば 入力として読む。実行ログから結果を集約し、計画の完了基準と突き合わせる。
• 前工程の成果物が無ければ代作しない。実行ログが無ければ「先に /test-execute を実行して ください」、計画が無ければ「先に /test-plan を実行してください」と 提案するに留める。

2. 調査優先 + 決定のみ質問

• 事実はリポジトリ調査で埋める。実行結果・件数・失敗内訳・カバレッジ・残欠陥は、 前工程の成果物や CI ログから自分で読み取る。利用者に集計を代行させない。
• 利用者にしか決められない判断だけ を AskUserQuestion で確認する。test-report では 主に 完了基準を満たさないときにリリース可否をどう扱うか（条件付き合格・却下・基準の見直し） が これに当たる（推奨案を先頭に添えて訊く）。
• 流れは 調査 → ドラフト提示 → 承認 → 規約パスへ書き込み。承認前に確定ファイルを書かない。

3. 改善提案と仕様反映（early testing 原則）

• 評価中に見つけた テスト対象・仕様・テスタビリティの問題（実行ログから見える不安定な テスト、観測できていない挙動、完了基準そのものの測定不能さなど）は、成果物の「改善提案」 セクションで 提示 する。
• 起票前に既決事項を照合する。前工程成果物（test-plan / test-analysis / test-design / test-execution-log）とプロジェクトのメモリに同じ問題が既に記録され、対応先（詳細設計送り・ 作業計画送り等）が確定しているものは改善提案に 再掲しない。必要なら「次のステップ」欄の 参照 1 行に留める。改善提案には この工程で新規に見つけた未解決の問題だけ を載せる。
• 仕様の穴は提示で終わらせない。評価の過程で仕様の曖昧さ・矛盾が割れた場合は、利用者の 決定を AskUserQuestion で確認し、決定が出たら その内容を仕様書へ反映する作業まで行う （反映先の仕様書が規約パスにある場合）。不安定なテスト・測定不能な完了基準のような 実装・計画レベルで解決すべき決定は、仕様書ではなく作業計画・メモリ等へ退避する。
• 反映が済んだ提案は「改善提案」セクションから削除する（「反映済み」注記で残さない。 決定の記録は仕様書の改訂履歴が担う）。全提案が解消したらセクションごと削除して番号を詰め、 未解決の提案が残っている間だけセクションを維持する。
• スキル自身がテスト対象のコードを修正しない。評価は欠陥や課題を指摘する工程であり、 この段階での修正実施ではない。

4. 単機能の堅持

• test-report は 評価と完了判定の成果物だけ を作る。他スキルを呼び出さず、相互参照もしない。
• 完了基準が未達で追加テストが必要なら、成果物末尾で 前工程スキル（/test-design で ケース追加、/test-execute で再実行など）の実行を提案 するに留める（自分では進めない）。

5. Progressive disclosure

• 本文は簡潔に保ち、テンプレ・詳細は references/ に置く。
• テンプレ: references/template.md（test-summary-report.md の雛形）。
• mini サマリ雛形: references/mini-template.md （mini-test-summary-report.md の雛形。手順 5 で使う）。

6. 成果物の記述スタイル

• 略号・コードネームを定義なしで使わない（例: 仕様書内の G3 のような社内略号）。 初出で正式名称・意味を併記するか、平易な表現に開く。成果物単体で読み返して意味が 取れることを基準にする。
• スキルの実行記録を成果物に含めない。利用者との Q&A ログ・フェーズ別実行時間などは 対話のテレメトリであって、レビュー対象の内容ではない。利用者との決定事項は本文の該当箇所 （根拠・凡例等）へ埋め込み、実行記録が必要なら scratchpad 等へ分離する。

手順

手順 0: テスト対象の確定

• 引数 <テスト対象名> があればそれを対象名とする。無ければ利用者に一言で確認する。 対象名は成果物パス docs/test/<テスト対象名>/ のディレクトリ名にも使う （英数字・ハイフンへ正規化）。

手順 1: 入力の収集

原則 1・2 に従い、以下を 自分で読む:

• 実行記録 test-execution-log.md: テストケースごとの合否・失敗内訳・欠陥候補・実行日時。 結果の一次ソース。無ければ前工程スキルの実行を提案して止まる（代作しない）。
• 計画 test-plan.md: 特に 開始/完了基準 と プロダクトリスク評価。判定の基準になる。
• 補助データ: CI のテスト結果・カバレッジレポート等が規約パス外にあっても、リポジトリ内に あれば読み取って集計の裏付けにする。

手順 2: 結果の集約と評価

実行ログを集約し、テストの状況を事実として整理する:

• 消化状況: 計画したケース数・実行済み数・未実行数（消化率）。
• 合否内訳: 合格 / 失敗 / ブロック / スキップ の件数と割合。
• 欠陥の状況: 未解決の欠陥候補を 重大度別 に集計（重大欠陥の残存数は判定の要）。
• カバレッジ: 計画で基準にした指標があれば実測値を対置する。
• 高リスク領域の消化: test-plan の高リスク項目がどこまで検証されたかを対応づける （リスクベースの完了判定の核）。

手順 3: 完了基準（exit criteria）判定

test-plan の完了基準を 1 項目ずつ、手順 2 の実測値と突き合わせて 満/未達を明示 する:

• 各基準を「達成 / 未達 / 判定不能（測定できていない）」で判定し、根拠となる数値を添える。
• 総合判定: 全基準達成なら「完了」。未達があれば「未完了」とし、何が不足かを列挙する。
• 中間評価の場合: 「完了」ではなく「現時点の進捗」として、達成済み基準と残りを示す。
• 完了基準を満たさないときのリリース可否（条件付き合格・却下・基準見直し）は利用者判断なので、 必要なら AskUserQuestion（推奨案先頭）で確認する。

手順 4: ドラフト提示 → 承認 → 書き込み

• references/template.md の構成で test-summary-report.md の ドラフトを作り、本文で提示して承認を得る（原則 2）。最終レポートか中間評価かを冒頭で明示する。
• 承認後、規約パス（既定 docs/test/<テスト対象名>/test-summary-report.md、プロジェクト規約が あれば優先）へ書き込む。
• 手順 1〜3 で見つけた問題は「改善提案」セクションに記載（原則 3）。
• 完了基準が未達なら、末尾で 不足を埋める前工程スキルの実行を提案 する（原則 4）。自分では進めない。

手順 5: mini サマリの作成（レビュー収束後）

• 本編 test-summary-report.md への利用者フィードバックが出なくなり、確認が完了したら、 同ディレクトリに初見者向けサマリ mini-test-summary-report.md を作成する。 レビュー中は作らない（フィードバックのたびに本編と同期し直すことになるため、収束後に 一度だけ作る）。
• 構成は references/mini-template.md に従う。対象ドメインに 詳しくない人へ短時間で説明できる状態を目指す。先行する mini-test-plan.md / mini-test-analysis.md / mini-test-design.md があればリスク番号・テスト条件番号を 相互参照で一貫させる。

手順 6: 終了条件の確認と完了宣言

結果評価（このスキルの作業）の終了条件は以下。テスト自体の完了基準（exit criteria）判定とは 別物で、総合判定が「未完了」でも評価工程としては完了と宣言できる。利用者に「終わりか」と 訊かれる前に、スキル側で判定して宣言する:

1. test-plan の全完了基準が「達成 / 未達 / 判定不能」で判定済みで、根拠の数値が添えてある（手順 3）。
2. 総合判定（完了 / 未完了 / 中間評価）が明示済み（手順 3）。
3. 承認済みの test-summary-report.md が規約パスへ書き込み済み（手順 4）。
4. 改善提案が空（各提案が仕様反映・対応先確定のいずれかで解消済み）。
5. test-review ゲート: /test-review <テスト対象名> report の判定が「通過」または 「条件付き通過」（記録 test-review-report.md）になっている、もしくは利用者がゲートの スキップを明示している。未実施なら完了宣言せず、利用者へ実行を促す （test-review は明示起動のみで、本スキルからは起動できない）。
6. mini サマリ作成済み（手順 5）。

• 全て満たしたら 「テスト結果評価は完了」と明言 して閉じる。総合判定が未完了なら、 不足を埋める前工程スキルの提案を添える（原則 4）。
• 満たしていない項目があれば、何が残っているかを列挙して先へ進めない。

用語（JSTQB 訳語 / 初出英語併記）

• テスト完了（test completion）: テスト活動の締めくくり。結果評価・完了レポート作成を含む。
• 完了基準（exit criteria）: テストを完了とみなす判定条件。test-plan で定義される。
• テスト完了レポート（test summary report / test completion report）: 結果評価と完了判定をまとめた成果物。
• 消化率（test execution progress）: 計画したテストのうち実行済みの割合。