# Test Analyze

> ISTQB/JSTQB のテスト分析（test analysis）活動を支援するスキル。テストベース（仕様・設計・コード・リスク）を分析して「何をテストすべきか」= テスト条件（test condition）を識別し、test-plan のプロダクトリスク評価があればそれを入力に優先度を付けた test-analysis.md を作る。「何をテストすべきか洗い出して」「テスト条件を整理して」「テスト観点を出して」「テスト分析して」と依頼されたときに使う。テストケースの導出（test-design）は対象外。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-analyze <テスト対象名> で明示的に呼び出されたときのみ使用する。

- **Type:** Skill
- **Install:** `agentstack add skill-yasunori0418-skills-test-analyze`
- **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-analyze

## Install

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

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

## About

# test-analyze: テスト分析（テスト条件の識別）

ISTQB/JSTQB のテストプロセス 7 活動のうち **テスト分析（test analysis）** を担う単機能スキル。
テストベース（test basis: 仕様・設計・コード・リスク等）を分析して **「何をテストすべきか」=
テスト条件（test condition）** を識別・優先度付けし、`test-analysis.md` を 1 本作る。

このスキルは **テスト条件の識別だけ** を行う。テストケースの導出（test-design）・実装・実行・
レポートは各専用スキルの担当で、ここでは呼び出さない。**単発のテスト作成依頼（単にユニット
テストを 1 つ書きたいだけ）は対象外** — その場合は通常のコーディング支援で対応する。
「テスト条件（何を確認するか）」を出すのがゴールで、**具体的なテストケース（入力値・期待結果）
の設計はしない**（それは `/test-design`）。

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

testing-skills 全 8 スキル共通の原則。型は test-plan が確立する参照実装に揃える。

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

- 成果物の既定パスは **`docs/test//test-analysis.md`**。
- **プロジェクト側（`CLAUDE.md` / `AGENTS.md` 等）に成果物の配置規約があればそちらを優先する**。
  着手前にリポジトリを調べ、既存の `docs/` 構成やテストドキュメントの慣習に合わせる。
- 前工程 test-plan の成果物 **`docs/test//test-plan.md`** が規約パスにあれば
  **入力として読む**（プロダクトリスク評価をテスト条件の優先度付けに使う）。PRD・仕様書・
  設計ドキュメントも規約パスにあれば入力として読む。
- **test-plan.md が無くても代作しない**。リスク評価が無い場合は、先に
  **`/test-plan ` の実行を提案** するに留め、テスト条件の識別は仕様・コード
  ベースで進める（リスク優先度は付けられない旨を明記）。

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

- **事実はリポジトリ調査で埋める**。テスト対象のコード・仕様・依存関係・既存テストの有無・
  入出力・状態遷移などは、利用者に訊く前に自分で調べる。
- **利用者にしか決められない判断だけ** を `AskUserQuestion` で確認する。test-analyze では
  主に **テスト条件の優先度・網羅範囲・除外してよい条件** がこれに当たる（推奨案を先頭に添えて訊く）。
- 流れは **調査 → ドラフト提示 → 承認 → 規約パスへ書き込み**。承認前に確定ファイルを書かない。

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

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

### 4. 単機能の堅持

- test-analyze は **テスト条件の成果物だけ** を作る。他スキルを呼び出さず、相互参照もしない。
- 後続工程が必要なら、成果物末尾で **次に `/test-design` を実行することを提案** するに留める
  （代わりにテストケースを設計しない）。

### 5. Progressive disclosure

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

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

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

## 手順

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

- 引数 `` があればそれを対象名とする。無ければ利用者に一言で確認する
  （例: 「決済 API」「ユーザー登録フロー」）。対象名は成果物パス
  `docs/test//` のディレクトリ名にも使う（英数字・ハイフンへ正規化）。

### 手順 1: テストベースの収集（事実収集）

原則 2 に従い、以下を **自分で調べる**（利用者に訊かない）:

- **前工程成果物**: `docs/test//test-plan.md`（プロダクトリスク評価・
  テストアプローチ・スコープ）。あれば優先度付けの主根拠にする（原則 1）。
- **仕様・設計**: `docs/`・README・PRD・設計書・型定義・API スキーマ・受け入れ条件。
- **テスト対象のコード**: 入出力・分岐・状態・境界・依存・エラー処理。
- **既存テスト**: 何が既にテスト済みか（重複を避け、抜けを見つける）。
- **配置規約**: `CLAUDE.md` / `AGENTS.md` の成果物配置ルール（原則 1）。

### 手順 2: テスト条件の識別

テストベースから **テスト条件（test condition）= テストで検証すべき項目・観点** を洗い出す。
「どんな入力値でどう振る舞うべきか」の抽象レベルで挙げる（具体値の設計は test-design）。

識別の切り口（テスト対象に応じて使い分ける。全てを埋める必要はない）:

- **機能要求**: 各機能が満たすべき振る舞い・受け入れ条件。
- **入力の区分**: 正常系・異常系・境界・同値クラスに分かれる観点。
- **状態・遷移**: 状態を持つ対象の状態と遷移、禁止遷移。
- **例外・エラー処理**: 失敗経路・タイムアウト・リトライ・ロールバック。
- **非機能**: 性能・セキュリティ・並行性・データ整合性（対象範囲内のもの）。
- **相互作用・依存**: 外部システム・境界インターフェイス・副作用。

各テスト条件には **一意な ID（TC-01 等）** と **対応するテストベース（要求 / コード箇所 /
リスク #）へのトレーサビリティ** を付ける。

**粒度ガード（テスト設計へ踏み込まない）**。次の書き方はテストケース設計（`/test-design`）への
踏み込みなので避ける:

1. **同値クラスの列挙**: 入力区分ごとに 1 行ずつ期待挙動を書く（「未設定→X」「空文字→X」…）のは
   同値分割（設計技法）の適用結果。「判定の全区分が仕様どおり解釈されること」の 1 条件に畳む。
2. **期待結果の埋め込み**: 「◯◯が△△で出力される」のような期待結果文はケース記述。
   「仕様 §X の互換 N 項目を満たすこと」のように仕様参照で束ねる。
3. **検証手段の混入**: golden master 比較・比較対象システムとの値一致など「どう確認するか」は
   テスト条件ではなくテスト計画側のアプローチ。条件一覧から外す。

目安は **機能領域ごとに 1 条件・全体で 10 件前後**（あくまで目安。大規模対象で超えるときは
理由を添える）。細分化した区分・期待値は捨てず、`/test-design` のケース導出素材として
次工程への引き継ぎに回す。

### 手順 3: 優先度付け

- test-plan のプロダクトリスク評価があれば、それを **主根拠** に各テスト条件へ優先度
  （高/中/低）を付ける（高リスク領域のテスト条件を高優先度に）。
- test-plan が無い場合は、仕様の重要度・変更頻度・影響範囲から暫定優先度を付け、
  **リスク評価が無い旨と `/test-plan` の実行提案を明記** する（原則 1）。
- 優先度・網羅範囲・除外してよい条件の判断が利用者依存なら、ここで
  `AskUserQuestion`（推奨案先頭）で確認する。

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

- [`references/template.md`](references/template.md) の構成で `test-analysis.md` のドラフトを
  作り、**本文で提示して承認を得る**（原則 2）。
- 承認後、規約パス（既定 `docs/test//test-analysis.md`、プロジェクト規約が
  あれば優先）へ書き込む。
- 手順 1〜3 で見つけた対象・仕様・テスタビリティの問題は「改善提案」セクションに記載（原則 3）。
- 末尾で **次工程 `/test-design ` の実行を提案** する（原則 4）。自分では進めない。

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

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

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

テスト分析の終了条件（exit criteria）は以下。**利用者に「終わりか」と訊かれる前に、
スキル側で判定して宣言する**:

1. テスト条件が一意な ID とテストベースへのトレーサビリティつきで識別済みで、
   粒度ガードを満たしている（手順 2）。
2. 全テスト条件に優先度が付き、承認済み（手順 3）。
3. 承認済みの `test-analysis.md` が規約パスへ書き込み済み（手順 4）。
4. 改善提案が空（各提案が仕様反映・対応先確定のいずれかで解消済み）。
5. test-review ゲート: `/test-review  analyze` の判定が「通過」または
   「条件付き通過」（記録 `test-review-analyze.md`）になっている、もしくは利用者がゲートの
   スキップを明示している。未実施なら完了宣言せず、利用者へ実行を促す
   （test-review は明示起動のみで、本スキルからは起動できない）。
6. mini サマリ作成済み（手順 5）。

- 全て満たしたら **「テスト分析は完了」と明言** し、`/test-design ` の提案で
  閉じる（原則 4）。
- 満たしていない項目があれば、何が残っているかを列挙して先へ進めない。

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

- テスト分析（test analysis）: テストベースを分析して「何をテストすべきか」を識別する活動。
- テストベース（test basis）: テスト条件を導く基となる情報（仕様・設計・コード・リスク等）。
- テスト条件（test condition）: テストで検証すべき項目・観点（具体値ではない抽象レベル）。
- テスト観点: テスト条件の実務で通りの良い呼称（本スキルでは同義）。日本語の「条件」は前提条件・
  if 条件を連想させるため、成果物の見出しは「テスト観点一覧（テスト条件）」の併記形式にする。
- トレーサビリティ（traceability）: テスト条件とテストベース（要求・リスク）の対応関係。

## 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-analyze
- 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%.