# Test Report

> ISTQB/JSTQB のテスト完了（test completion）活動のうち、テスト実行結果の評価と完了基準（exit criteria）判定を支援するスキル。テスト実行ログ（test-execution-log.md）と test-plan の完了基準を突き合わせ、完了とみなせるかを判定した test-summary-report.md を作る。テスト完了時の最終レポートにも、テスト途中の中間評価にも使える。「テスト結果をまとめて」「完了基準を満たしたか判定して」「テストレポートを書いて」「今どこまでテストが進んだか評価して」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-report <テスト対象名> で明示的に呼び出されたときのみ使用する。

- **Type:** Skill
- **Install:** `agentstack add skill-yasunori0418-skills-test-report`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [yasunori0418](https://agentstack.voostack.com/s/yasunori0418)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [yasunori0418](https://github.com/yasunori0418)
- **Source:** https://github.com/yasunori0418/skills/tree/main/skills/testing/test-report

## Install

```sh
agentstack add skill-yasunori0418-skills-test-report
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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`](references/template.md)（`test-summary-report.md` の雛形）。
- mini サマリ雛形: [`references/mini-template.md`](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`](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`](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）: 計画したテストのうち実行済みの割合。

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [yasunori0418](https://github.com/yasunori0418)
- **Source:** [yasunori0418/skills](https://github.com/yasunori0418/skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-yasunori0418-skills-test-report
- Seller: https://agentstack.voostack.com/s/yasunori0418
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.