# Test Design

> ISTQB/JSTQB のテスト設計（test design）活動を支援するスキル。test-analyze が識別したテスト条件から、テスト対象の特性に応じたテスト技法（同値分割・境界値分析・デシジョンテーブル・状態遷移・カバレッジ基準・エラー推測など）を選定提案し、承認された技法で具体的なテストケース（入力値・前提・期待結果）を導出して、設計書 test-design.md（技法選定根拠・カバレッジ）とケース一覧 test-case.md の 2 本を作る。「テストケースを作って」「テストケースを設計して」「どの技法で網羅すべきか提案して」「境界値/デシジョンテーブルでテストを起こして」と依頼されたときに使う。テストコード実装（test-implement）は対象外。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-design <テスト対象名> で明示的…

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

## Install

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

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

## About

# test-design: テスト設計（技法選定 + テストケース導出）

ISTQB/JSTQB のテストプロセス 7 活動のうち **テスト設計（test design）** を担う単機能スキル。
test-analyze が識別した **テスト条件** から、対象特性に応じた **テスト技法（test technique）** を
選定提案し、承認された技法で **具体的なテストケース（入力値・前提・期待結果）** を導出して、
成果物を 2 本作る。**設計判断とケース一覧を 1 ファイルに混在させない**:

- **`test-design.md`（テスト設計書）**: 採用技法と選定根拠・カバレッジ確認・改善提案。
  **技法の選定根拠を必ずこちらに残す**。
- **`test-case.md`（テストケース一覧）**: 前提・入力・期待結果の一覧のみ。技法の根拠は
  `test-design.md` への参照で示す。

このスキルは **テストケースの導出だけ** を行う。テストコード・手順書への具体化（test-implement）・
実行（test-execute）・レポートは各専用スキルの担当で、ここでは呼び出さない。**単発のテスト作成
依頼（単にユニットテストを 1 つ書きたいだけ）は対象外** — その場合は通常のコーディング支援で
対応する。導出するのは **論理的なテストケース（何を・どう入れ・何を期待するか）** で、
**実行可能なコードやデータの実装はしない**（それは `/test-implement`）。

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

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

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

- 成果物の既定パスは **`docs/test//test-design.md`** と
  **同 `test-case.md`** の 2 本。
- **プロジェクト側（`CLAUDE.md` / `AGENTS.md` 等）に成果物の配置規約があればそちらを優先する**。
  着手前にリポジトリを調べ、既存の `docs/` 構成やテストドキュメントの慣習に合わせる。
- 前工程 test-analyze の成果物 **`docs/test//test-analysis.md`**（テスト条件と
  優先度）が規約パスにあれば **入力として読む**。test-plan.md があればリスク根拠も参照する。
- **test-analysis.md が無くても代作しない**。テスト条件が無い場合は、先に
  **`/test-analyze ` の実行を提案** するに留める（自分でテスト条件を網羅識別
  しない。既にテスト条件が本文で提示されているなら、それを対象に設計してよい）。

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

- **事実はリポジトリ調査で埋める**。入力の型・範囲・境界・状態遷移・分岐・仕様上の期待結果は、
  利用者に訊く前にコード・仕様から自分で調べる。
- **利用者にしか決められない判断だけ** を `AskUserQuestion` で確認する。test-design では
  主に **どの技法を採用するか・カバレッジ基準の水準・ケース数の上限** がこれに当たる
  （推奨案を先頭に添えて訊く）。技法選定は「提案 → 承認」を必ず経る。
- 流れは **調査 → 技法提案 → 承認 → ケース導出 → ドラフト提示 → 承認 → 規約パスへ書き込み**。

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

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

### 4. 単機能の堅持

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

### 5. Progressive disclosure

- 本文は簡潔に保ち、テンプレ・技法カタログ・詳細は `references/` に置く。
- テンプレ: [`references/template-design.md`](references/template-design.md)
  （`test-design.md` の雛形）、
  [`references/template-case.md`](references/template-case.md)（`test-case.md` の雛形）。
- mini サマリ雛形: [`references/mini-template-design.md`](references/mini-template-design.md)
  （`mini-test-design.md` の雛形）、
  [`references/mini-template-case.md`](references/mini-template-case.md)
  （`mini-test-case.md` の雛形。いずれも手順 5 で使う）。
- 技法カタログ:
  [`references/techniques-blackbox.md`](references/techniques-blackbox.md)（ブラックボックス技法）、
  [`references/techniques-whitebox-experience.md`](references/techniques-whitebox-experience.md)
  （ホワイトボックス技法・経験ベース技法）。

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

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

## 手順

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

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

### 手順 1: 入力の収集（事実収集）

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

- **前工程成果物**: `docs/test//test-analysis.md`（テスト条件・優先度）。
  無ければ原則 1 に従い `/test-analyze` の実行を提案（本文提示済みなら続行可）。
- **仕様・コード**: 入力の型・値域・境界・分岐条件・状態遷移・期待結果の根拠・エラー処理。
- **テスト実行環境**: テストランナー・既存テストの種別（Unit/Integration 等）・CI への組み込み・
  ローカルで再現できる依存（DB・ストレージ等のコンテナ）・別リポジトリや実機に依存する検証の有無。
  手順 3 の自動/手動区分の判定材料にする。
- **配置規約**: `CLAUDE.md` / `AGENTS.md` の成果物配置ルール（原則 1）。

### 手順 2: テスト技法の選定提案

技法は 3 分類のカタログ（references/）から、**テスト条件の特性に応じて選ぶ**:

- **ブラックボックス技法**（仕様ベース）:
  [`references/techniques-blackbox.md`](references/techniques-blackbox.md)。
  同値分割・境界値分析・デシジョンテーブル・状態遷移・ペアワイズ・ユースケース。
- **ホワイトボックス技法**（構造ベース）+ **経験ベース技法**:
  [`references/techniques-whitebox-experience.md`](references/techniques-whitebox-experience.md)。
  ステートメント/ブランチカバレッジ・エラー推測・探索的テスト・チェックリスト。

選定の当てはめ（例）:

- 連続値・数値範囲がある → 同値分割 + 境界値分析。
- 複数条件の組合せで結果が変わる → デシジョンテーブル。
- 状態を持ち遷移で振る舞いが変わる → 状態遷移。
- 多数のパラメータ組合せ → ペアワイズ。
- コード網羅を保証したい → ステートメント/ブランチカバレッジ。
- 仕様外の壊れ方を突く → エラー推測・探索的テスト。

**採用技法とその根拠（なぜその条件にその技法か）を提示し、承認を得てから導出に進む**
（原則 2）。技法・カバレッジ基準・ケース数上限が利用者依存なら `AskUserQuestion`（推奨案先頭）。

### 手順 3: テストケースの導出

承認された技法で、各テスト条件から **論理的テストケース** を導出する:

- 各ケースに **一意な ID・前提条件・入力（値/操作）・期待結果・対応テスト条件（TC-xx）** を付ける。
- 技法のカバレッジ基準（境界値なら各境界の内外、デシジョンテーブルなら各ルール、ブランチ
  カバレッジなら各分岐の真偽など）を満たすことを意識する。
- 具体値・実行コード・テストデータの **実装はしない**（test-implement の担当）。期待結果は
  仕様・コードから確定できる範囲で書き、確定できないものは改善提案へ回す（原則 3）。
- **各ケースに自動/手動の区分を付ける**。手順 1 で調べたテスト実行環境に基づき、既存の
  テストランナー・CI で機械実行できるケースを「自動」、環境の制約（別リポジトリ・実機・
  目視レビュー依存など）で人手の実行が要るケースを「手動」とする。**判定基準（どの実行手段が
  あるから自動と言えるか）は `test-design.md` に節として残す**。データ準備等に人手が要る
  半自動的な検証手段は、ケースの区分値には出さず設計書の判定基準側に整理する。区分は設計時点の
  判定であり、実装時の食い違いは test-implement が `test-case.md` を更新して正とする。

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

- [`references/template-design.md`](references/template-design.md) の構成で `test-design.md`、
  [`references/template-case.md`](references/template-case.md) の構成で `test-case.md` の
  ドラフトを作り、**本文で提示して承認を得る**（原則 2）。**技法選定根拠のセクションを
  設計書側に必ず含める**。設計判断（技法・カバレッジ・除外）とケース一覧を混在させない。
- 承認後、規約パス（既定 `docs/test//test-design.md` と同 `test-case.md`、
  プロジェクト規約があれば優先）へ書き込む。
- 手順 1〜3 で見つけた対象・仕様・テスタビリティの問題は `test-design.md` の「改善提案」
  セクションに記載（原則 3）。
- 末尾で **次工程 `/test-implement ` の実行を提案** する（原則 4）。自分では進めない。

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

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

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

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

1. テスト技法の選定が承認済み（手順 2）。
2. 入力の全テスト条件（TC-xx）がテストケースでカバーされている（トレーサビリティ確認）。
3. 全ケースに自動/手動の区分が付いている（手順 3）。
4. 改善提案が空（各提案が仕様反映・対応先確定・ケース明記のいずれかで解消済み）。
5. test-review ゲート: `/test-review  design` の判定が「通過」または
   「条件付き通過」（記録 `test-review-design.md`）になっている、もしくは利用者がゲートの
   スキップを明示している。未実施なら完了宣言せず、利用者へ実行を促す
   （test-review は明示起動のみで、本スキルからは起動できない）。
6. mini サマリ作成済み（手順 5）。

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

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

- テスト設計（test design）: テスト条件からテストケースを導出する活動。
- テスト技法（test technique）: テストケースを体系的に導く方法。ブラックボックス（仕様ベース）/
  ホワイトボックス（構造ベース）/ 経験ベースの 3 分類。
- テストケース（test case）: 前提・入力・期待結果の組。ここでは論理的（値の実装前）レベル。
- カバレッジ（coverage）: 技法が定める網羅の度合い（各境界・各ルール・各分岐 等）。

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