# Test Execute

> ISTQB/JSTQB のテスト実行（test execution）活動を支援するスキル。test-implement が具体化したテストを実行し、結果を記録し、失敗を欠陥候補として整理して test-execution-log.md にまとめる。自動テストならランナーを実行し結果を解釈、手動テストなら利用者の実施結果を聞き取って記録する。失敗は欠陥候補として整理し、外部 issue 化は提案に留める。「テストを実行して結果を記録して」「テスト実行ログを作って」「失敗を欠陥として整理して」「手動テストの結果を記録して」と依頼されたときに使う。ワークフローの test-targeted（修正範囲にテストランナーを絞り込んで実行するだけ）とは別物で、こちらは ISTQB プロセスとしての実行・記録・欠陥候補整理を成果物 test-execution-log.md に残す。単発のテスト作成依頼…

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

## Install

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

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

## About

# 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`](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`](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 テスト: 対象を変えていないのに結果が安定しない、信頼できないテスト。

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