Test Design

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 は明示起動のみで、本スキルからは起動できない）。

1. 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
• Source: yasunori0418/skills
• License: MIT

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