Menü
TDD実装・簡素化完了後のテスト品質強化に使用。ACテストだけではカバーできない境界値・エッジケース・異常系・組み合わせを設計・実装し、レビュー前にテストの網羅性を引き上げる。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。
| name | test-quality |
| description | TDD実装・簡素化完了後のテスト品質強化に使用。ACテストだけではカバーできない境界値・エッジケース・異常系・組み合わせを設計・実装し、レビュー前にテストの網羅性を引き上げる。 |
implementer が書いた AC テストの「外側」を埋める。 テストケース設計を実装とは別の責務として分離し、テストの抜け漏れを構造的に防ぐ。
入力: REQ パス（例: requirements/REQ-001/）+ テスト全 GREEN の実装コード + テストコード + requirements.md 全文
出力: 品質テストが追加されたテストスイート（テスト全 GREEN 維持）
原則: AC テストは「仕様を満たすか」を検証する。品質テストは「壊れないか」を検証する。
品質テストなしにレビューに進むな
AC テストが通っている ≠ テストが十分。AC は仕様のハッピーパスと主要な異常系しかカバーしない。
常に:
例外（人間パートナーに確認すること）:
digraph test_quality {
rankdir=TB;
input [label="simplify完了\nテスト全GREEN", shape=ellipse];
analyze [label="カバレッジ分析\n既存テストの棚卸し", shape=box, style=filled, fillcolor="#cce5ff"];
design [label="テストケース設計\n境界値・エッジケース・異常系", shape=box, style=filled, fillcolor="#ccccff"];
review_design [label="人間パートナーに\nテスト計画を提示", shape=box, style=filled, fillcolor="#ffffcc"];
implement [label="テスト実装\n1つずつ追加→実行", shape=box, style=filled, fillcolor="#ccffcc"];
check [label="全テスト\nGREEN?", shape=diamond];
fix [label="テストを修正\nor バグ発見→報告", shape=box, style=filled, fillcolor="#ffcccc"];
done [label="品質テスト完了", shape=ellipse];
input -> analyze;
analyze -> design;
design -> review_design;
review_design -> implement;
implement -> check;
check -> done [label="はい"];
check -> fix [label="いいえ"];
fix -> check [label="修正後"];
}
既存のテストを棚卸しし、何がカバーされていて何が抜けているかを把握する。
| 確認事項 | 観点 |
|---|---|
| AC と FR の対応 | AC-* の Covers: FR-x を追って、全 FR にテストがあるか |
| 正常系 | ハッピーパスがカバーされているか |
| 異常系 | エラーパス（IF 条件）がカバーされているか |
| 境界値 | 入力の境界（0, 1, max, max+1, 空, null）がテストされているか |
| 型・フォーマット | 不正な型、不正なフォーマットの入力がテストされているか |
| 状態遷移 | 状態を持つ場合、遷移の各パスがテストされているか |
| 組み合わせ | 複数の入力・条件の組み合わせがテストされているか |
分析結果に基づき、追加すべきテストケースを設計する。
| 分類 | 説明 | 例 |
|---|---|---|
| 境界値 | 入力の境界とその前後 | 0, 1, -1, MAX_INT, MAX_INT+1 |
| エッジケース | 特殊な入力・状態 | 空文字列, null, undefined, 空配列, 巨大入力 |
| 異常系 | エラーが発生すべき入力 | 不正な型, 範囲外, 権限不足 |
| 組み合わせ | 複数条件の交差 | フラグA=true かつ フラグB=false の場合 |
| 並行性 | 並行アクセスの安全性 | 同時更新, レースコンディション |
| 冪等性 | 同じ操作の繰り返し | 2回目の呼び出しが安全か |
全分類を網羅する必要はない。実装の性質に応じて、該当する分類だけを設計する。
## 追加テストケース
### 境界値
- TQ-1: [入力が0の場合、XXXを返す]
- TQ-2: [入力がMAX_INTの場合、XXXを返す]
### エッジケース
- TQ-3: [空文字列の場合、エラーを返す]
### 異常系
- TQ-4: [不正な型の場合、TypeErrorをスローする]
### 組み合わせ
- TQ-5: [フラグAがtrueかつ入力が空の場合、デフォルト値を使用する]
設計したテストケース一覧を人間パートナーに提示し、承認を得る。
承認されたテストケースを1つずつ実装する。
品質テストで実装のバグが見つかった場合:
| 品質 | 良い | 悪い |
|---|---|---|
| 意図が明確 | テスト名だけで何を検証しているかわかる | testEdgeCase1, testBoundary |
| 独立 | 他のテストに依存しない | 特定の実行順序が必要 |
| 最小限 | 1テスト1振る舞い | 1テストで複数の条件を検証 |
| 再現可能 | 入力と期待出力が明確 | ランダムな入力に依存 |
| 保守可能 | 実装詳細ではなく振る舞いをテスト | 内部状態を直接検証 |
| 言い訳 | 現実 |
|---|---|
| 「ACテストで十分」 | AC はハッピーパスと主要異常系のみ。境界値は別途必要 |
| 「カバレッジ100%だからOK」 | 行カバレッジ100%でもバグは出る。パスカバレッジ・条件カバレッジが重要 |
| 「境界値は自明」 | 自明な境界値でバグが出るのが一番多い |
| 「テストが多すぎると保守が大変」 | 保守が大変なのはテストが多いからではなく、テストが実装詳細に依存しているから |
| 「後でE2Eテストで確認する」 | E2Eテストはフィードバックが遅い。ユニットテストで先に捕まえろ |
以下のどれかに当てはまったら、やり方を見直せ。
既存テスト（AC由来）:
- AC-1: 有効な入力で登録成功
- AC-2: メールアドレスなしでエラー
- AC-3: 既に存在するメールアドレスでエラー
カバレッジ分析:
- 境界値: パスワード長の最小/最大が未テスト
- エッジケース: メールアドレスの不正フォーマットが未テスト
- 異常系: DB接続エラー時の挙動が未テスト
- 組み合わせ: 複数フィールドが同時に不正な場合が未テスト
追加テストケース:
- TQ-1: パスワードが最小長（8文字）の場合、登録成功
- TQ-2: パスワードが最小長-1（7文字）の場合、エラー
- TQ-3: パスワードが最大長（128文字）の場合、登録成功
- TQ-4: メールアドレスが不正フォーマット（@なし）の場合、エラー
- TQ-5: 名前とメールアドレスが両方空の場合、両方のエラーを返す
品質テスト完了前に確認:
| 問題 | 解決策 |
|---|---|
| 何をテストすべかわからない | 境界値分析から始めろ。入力の型ごとに境界を洗い出す |
| テストケースが多すぎる | 優先度をつけて人間パートナーに相談。境界値 > エッジケース > 組み合わせ |
| バグが大量に見つかった | 設計に根本的な問題がある可能性。人間パートナーにエスカレート |
| テストが書きにくい | テストしにくい = 設計が複雑すぎる。TDD に戻って設計を見直す提案をしろ |
| 既存テストの意図がわからない | requirements.md の AC と FR を突き合わせろ。それでもわからなければ人間に聞く |
あなたはこのスキルのプロセスを自分で実行しない。以下のエージェントにディスパッチする。
前提: 対応する REQ を特定する。 ディスパッチ前に、このタスクに対応する requirements/REQ-*/requirements.md を特定しろ。タスクのコンテキスト（plan、直前のステップの出力）に REQ パスが含まれていればそれを使う。見つからなければ requirements/ を確認し、候補を人間パートナーに AskUserQuestion で提示して選択してもらう。推測で REQ を決めるな。必ず人間に確認しろ。
test-runner エージェントをディスパッチしてベースライン取得
test-quality-engineer エージェントをディスパッチする
test-quality-engineer がカバレッジ分析 → テストケース設計 → 人間承認 → 実装を実行するtest-quality-engineer は完了時に 4ステータス（DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED）で報告するtest-runner エージェントをディスパッチして最終確認
あなたが結果を判断する
前提スキル:
必須ルール:
次のステップ:
このスキルを使うスキル: