test-analyze

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（test-analysis.md の雛形）。
• mini サマリ雛形: 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 の構成で 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 に従う。対象ドメインに 詳しくない人へ短時間で説明できる状態を目指し、見出しは「何を確認するか」「何が怖いか」の ような問いの形にする。先行する 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）: テスト条件とテストベース（要求・リスク）の対応関係。