test-execute: テスト実行・記録・欠陥候補整理

ISTQB/JSTQB のテストプロセス 7 活動のうち テスト実行（test execution） を担う単機能スキル。 test-implement が具体化したテストを実行・記録し、失敗を欠陥候補として整理した test-execution-log.md を 1 本作る。対象に応じて分岐する:

• 自動テスト → テストランナーを実行し、pass/fail・エラー内容を 解釈 して記録する。
• 手動テスト → 手順書に沿った 利用者の実施結果を聞き取って 記録する（AI が代行実施しない）。

既存の test-targeted（workflow カテゴリ）との違い: test-targeted は「修正範囲に絞って テストランナーをどう呼ぶか」という実行の絞り込み運用ルール。本スキルは ISTQB プロセスとしての 実行結果の記録・解釈と欠陥候補の整理を成果物（test-execution-log.md）に残す ことが目的で、 コマンドの絞り込み自体は関心事ではない。

このスキルは テスト実行・記録・欠陥候補整理だけ を行う。テストの具体化（test-implement）・ 結果の評価と完了基準判定（test-report）は各専用スキルの担当で、ここでは呼び出さない。 失敗の外部 issue 化（GitHub Issue 等の作成）は提案に留め、勝手に起票しない。 単発のテスト作成依頼（単にユニットテストを 1 つ書きたいだけ）は対象外。

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

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

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

• 成果物の既定パスは docs/test/<テスト対象名>/test-execution-log.md。
• プロジェクト側（CLAUDE.md / AGENTS.md 等）に成果物の配置規約があればそちらを優先する。
• 前工程の成果物が規約パスにあれば 入力として読む:
  • 自動 → test-implement が置いたテストコード（実行対象）。
  • 手動 → test-procedures.md（実施する手順書）。
  • あわせて test-case.md / test-plan.md があれば、消化状況や重点度の確認に参照する。
• 実行対象（テストコード / test-procedures.md）が無ければ test-execute を進めず、 /test-implement <テスト対象名> の実行を提案するに留める（前工程を代作しない）。

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

• 事実はリポジトリ調査で埋める。テスト実行コマンド・ランナー・CI での実行方法・ 実行環境の前提は、利用者に訊く前に自分で調べる。
• 利用者にしか決められない判断だけ を AskUserQuestion で確認する。test-execute では 主に 手動テストの実施結果（合否・観測値）・失敗を欠陥候補とみなすかの判断・ 外部 issue 化するかどうか がこれに当たる（推奨案を先頭に添えて訊く）。
• 流れは 調査/実行 → ドラフト提示 → 承認 → 規約パスへ書き込み。承認前に確定ファイルを書かない。

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

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

4. 単機能の堅持

• test-execute は 実行ログの成果物だけ を作る。他スキルを呼び出さず、相互参照もしない。
• 完了基準の判定・完了レポートは次工程。成果物末尾で 次に /test-report を実行することを 提案 するに留める（代わりに評価・判定を進めない）。

5. Progressive disclosure

• 本文は簡潔に保ち、テンプレ・詳細は references/ に置く。
• 実行ログテンプレ: references/template.md（test-execution-log.md の雛形）。

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

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

手順

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

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

手順 1: 実行対象の確認と調査

原則 1・2 に従う:

• 実行対象を確認する: 自動 → test-implement が置いたテストコード、手動 → test-procedures.md。 無ければ /test-implement の実行を提案して停止（代作しない）。
• 実行方法を調査: テスト実行コマンド・ランナー・CI での実行方法・実行環境の前提。

手順 2: 自動/手動の分岐実行

対象の種別に応じて分岐する。両方ある場合は両方実施する。

手順 3a: 自動テストの実行と解釈

• テストランナーを実行する（プロジェクトのコマンドで。重い/長いものは背景実行や timeout 延長で 完走させる）。実行は テスト対象の検証としての本実行（test-implement の構文確認とは別）。
• 結果を解釈する: pass/fail 件数、失敗ケースのエラーメッセージ・スタックトレース・落ちた アサーションを読み、何がどう失敗したか を記録用にまとめる。flaky 疑いは再実行で切り分ける。

手順 3b: 手動テストの結果聞き取り

• AI がテストを代行実施しない。test-procedures.md の各手順について、利用者が実施した 結果（合否・観測した実際値・スクリーンショット等）を聞き取って 記録する（原則 2）。
• 期待結果と実際値の差分を明確にする。合否が曖昧なものは利用者に確認する。

手順 4: 欠陥候補の整理

• 失敗（自動の fail / 手動の期待不一致）を 欠陥候補（defect candidate） として整理する: 再現手順・期待結果・実際結果・影響範囲・重大度の暫定評価。
• 外部 issue 化（GitHub Issue 等）はしない。必要なら「起票を提案」するに留める（原則 4・ external-writes の方針に沿う）。テスト対象コードの修正もしない（原則 3）。

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

• references/template.md の構成で test-execution-log.md のドラフトを作り、 本文で提示して承認を得る（原則 2）。
• 承認後、規約パス（既定 docs/test/<テスト対象名>/test-execution-log.md）へ書き込む。
• 実行中に気づいたテスタビリティ等の問題は「改善提案」に記載（原則 3）。
• 末尾で 次工程 /test-report <テスト対象名> の実行を提案 する（原則 4）。自分では評価しない。

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

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

1. 実行対象の全ケースが実行済みまたは聞き取り済みで、実行できなかったケースは ブロック/スキップの理由がログに明記済み（手順 3a / 3b）。
2. 全ての失敗が欠陥候補として整理済み（再現手順・期待/実際結果・暫定重大度）（手順 4）。
3. 承認済みの test-execution-log.md が規約パスへ書き込み済み（手順 5）。
4. 改善提案が空（各提案が仕様反映・対応先確定のいずれかで解消済み）。
5. test-review ゲート: /test-review <テスト対象名> execute の判定が「通過」または 「条件付き通過」（記録 test-review-execute.md）になっている、もしくは利用者がゲートの スキップを明示している。未実施なら完了宣言せず、利用者へ実行を促す （test-review は明示起動のみで、本スキルからは起動できない）。

• 全て満たしたら 「テスト実行は完了」と明言 し、/test-report <テスト対象名> の提案で 閉じる（原則 4）。欠陥候補が残っていても、記録が済んでいれば実行工程としては完了である （欠陥の評価は次工程）。
• 満たしていない項目があれば、何が残っているかを列挙して先へ進めない。

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

• テスト実行（test execution）: テストを実行し、実際結果を期待結果と比較する活動。
• テスト結果（test result）: 実行で得た pass/fail・観測値の記録。
• 欠陥候補（defect candidate）: 失敗のうち、対象の欠陥である可能性がある事象。確定は評価工程。
• flaky テスト: 対象を変えていないのに結果が安定しない、信頼できないテスト。