Claudeのtesting-strategyスキルでコンポーネント別のテスト計画を作る

testing-strategyは、Anthropicが配布するengineeringプラグインに入ったスキルです。「テスト計画を作って」「何のテストが要るか」といった依頼で働き、テストピラミッドを前提に、コンポーネントの種類ごとのテスト種別と、網羅する対象・省く対象を決めた計画を出します。

スキルの定義はごく短く、そのままでは「計画の骨組み」までしか決まりません。この記事では、定義が何を決めていて何を決めていないかを整理し、4種類のコンポーネントを持つ架空のサービスを例に、依頼文の組み立てから既存カバレッジのギャップ洗い出し、計画の固定までを順に扱います。

testing-strategyは何を決めるスキルか

リポジトリ上の定義は、説明文で「テスト戦略とテスト計画を設計する」と述べ、起動のきっかけになる言い回しを列挙しています。how should we test、test strategy for、write tests for、test plan、what tests do we need の5つと、テストの進め方・カバレッジ・テスト構成に関する相談です。

本文は、次の4つの部分でできています。

コンポーネント別の戦略は、定義では次の対応になっています。

省く対象も明記されています。単純なゲッター・セッター、フレームワーク自体のコード、使い捨てのスクリプトです。

engineeringプラグインを入れて呼び出す

導入はマーケットプレイスの登録とプラグインの追加の2行です。プラグインのREADMEが示す手順をそのまま使います。

claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install engineering@knowledge-work-plugins

プラグイン全体のしくみはClaude Codeプラグイン完全ガイドにまとめています。

スラッシュコマンドは用意されていない

engineeringプラグインのコマンド一覧は /standup /review /debug /architecture /incident /deploy-checklist の6つで、テスト用のコマンドはありません。testing-strategyは「スキル」の欄に載っており、Claudeが会話の内容から必要と判断して読み込む使い方が基本です。

Claude Codeでは、プラグインのスキルは /プラグイン名:スキル名 の形で直接呼べます。そのため、読み込みを確実にしたいときは次のように名前空間付きで呼びます。

/engineering:testing-strategy 注文管理サービスのテスト計画を作る

定義の冒頭に引数のヒント欄は無いので、/deploy-checklist auth-service v2.3.0 のような決まった書式はありません。スキルの後ろに続けた文章が、そのまま依頼文になります。

「write tests for」でも起動しうる

注意したいのは、説明文の起動語に write tests for が含まれている点です。「このファイルのテストを書いて」という依頼でもスキルが読み込まれ、テストコードではなく計画が先に出る可能性があります。定義の出力は計画と例示のテストケースで、テストコードの全文生成までは書かれていません。

単体テストをすぐ書かせたいときは、Claude Codeで単体テストを書かせる手順の指示文を使い、「計画は不要。このファイルの単体テストを書く」と明示すると意図がずれにくくなります。

定義が決めていないこと

定義は短いぶん、利用者が補うべき点がいくつもあります。計画の質は、ここを依頼文で埋められるかで決まります。

• カバレッジ目標の数字: 出力に「カバレッジ目標」を含めるとありますが、基準値は書かれていません。80%といった数字を使うかどうかは依頼側で指定します。
• ピラミッドの比率: 図は単体を多く、E2Eを少なくという形を示すだけで、比率は示していません。
• 使うテストツール: JestかVitestか、pytestかは指定がありません。リポジトリの既存構成から読み取らせるか、依頼文に書きます。
• コントラクトテストの要否: 利用側が存在しない内部専用のAPIで、コントラクトテストが過剰になるかは定義だけでは判断できません。
• 既存カバレッジのギャップ: 出力に含めるとされていますが、カバレッジの計測結果を渡さなければ、見えている範囲のテストファイルからの推測になります。

つまり、スキルが与えるのは「何を考えるべきかの型」で、数字や優先順位は含まれません。型に沿って考えさせ、数字は自分で決めて渡す、という分担になります。

依頼文の組み立て方

例として、次の4つのコンポーネントを持つ注文管理サービスを考えます。架空の構成です。

• 注文API(Node.js、外部の2つのチームが呼び出す)
• 夜間の売上集計パイプライン(Python、取り込みから変換まで)
• 管理画面(React)
• Terraformで管理するインフラ(本番と検証の2環境)

依頼文には、構成・既存のテスト状況・制約の3点を入れます。以下は依頼文の一例です。

/engineering:testing-strategy 注文管理サービスのテスト計画を作る。
構成:
- orders-api: Node.js。外部2チームが呼ぶ。契約は OpenAPI で管理
- nightly-sales: Python。CSV取り込み→変換→集計テーブル更新
- admin-ui: React。注文検索と返金操作
- infra: Terraform。prod と staging
既存: orders-api に Jest の単体テストが約200件、他はほぼ無し
制約: CI は 15 分以内。E2E は返金操作の1本だけ許容
出力: コンポーネント別に、テスト種別・網羅する対象・省く対象・目標値・例のテストケース

制約の行がとくに効きます。ピラミッドの考え方だけでは、E2Eを何本まで許容するかは決まりません。「CIは15分以内」「E2Eは1本」と伝えれば、計画はその枠に収まる種別の配分になります。

返ってくる計画に載せたい項目

定義の出力は「何をテストするか」「領域ごとのテスト種別」「カバレッジ目標」「例のテストケース」の4点です。次の表は、上の依頼で計画に載っていてほしい中身の見本です。実際の出力ではなく、確認の物差しとして使います。

見本は、定義の「コンポーネント別の戦略」と上の制約を重ねた形です。計画に冪等性の項目が無ければ、パイプラインの観点が落ちています。その場で「nightly-salesの冪等性テストの例を足して」と追加で頼めば足ります。

既存カバレッジのギャップを見つけさせる

定義は計画に「既存カバレッジのギャップの特定」を含めるとしています。推測で終わらせないために、先に計測結果を作って渡します。

# Node.js(Jest)
npx jest --coverage --coverageReporters=text-summary --coverageReporters=lcov
 
# Python(pytest-cov)
pytest --cov=nightly_sales --cov-report=term-missing

出力を貼るか、レポートのパスを示して次のように頼みます。

上の計画に対して、現状のカバレッジでは何が足りないかを一覧にして。
行カバレッジが高くても、金額計算の境界値や冪等性のように
計画上重要な観点が空いている箇所を優先して挙げる

行カバレッジの数字は、重要な観点が検証されているかを保証しません。計画の「網羅する対象」と突き合わせて、数字が高いのに観点が空いている箇所を探させるほうが、穴の見つけ方として実用的です。穴が見つかったあとにテストを書き足す作業は、単体テストを書かせる手順の流れにそのままつながります。書いたテストが実際に不具合を拾えるかを確かめる段階では、ミューテーションテストが使えます。

計画をリポジトリに固定する

会話の中で出た計画は、セッションが変わると残りません。次の2つの方法で、リポジトリに残して使い回します。

1つ目は、計画をファイルに書き出させる方法です。docs/test-plan.md のような場所に保存し、変更のたびに更新を頼みます。「E2Eは返金操作の1本だけ」といった判断を、PRのレビューで確認できる形にできます。

2つ目は、判断基準を CLAUDE.md に書く方法です。スキルの定義に無い数字や制約を、次のように置いておきます。以下は一例です。

## テスト計画の前提
- CI は 15 分以内に収める。E2E は主要な金銭操作に限り、全体で 3 本まで
- カバレッジ目標は新規コードの行カバレッジ 80%。生成コードと設定ファイルは除外
- API は呼び出し元チームがあるものだけコントラクトテストを書く
- パイプラインは必ず冪等性テストを含める
- 計画は docs/test-plan.md に保存し、変更時に更新する

こうしておくと、スキルが計画を組み立てるとき、リポジトリの方針が前提として読み込まれます。モノレポで領域ごとに流儀が違う場合の書き分けは、モノレポのテスト戦略をSKILL.mdで教える手順が詳しく扱っています。

スキルそのものを自社向けに変えたい場合は、プロジェクトに別名のスキルを置く方法もあります。Claude Codeのドキュメントによれば、プラグインのスキルは名前空間付きで読み込まれるため、同じ名前の個人・プロジェクトのスキルと両方が読み込まれます。書き方はSkillsのSKILL.md解説を参照してください。

使う前に知っておきたい点

常駐コスト

有効にしたプラグインのスキルは、使わないセッションでも名前と説明文が文脈に載ります。testing-strategyの定義には、自動での読み込みを止める設定(disable-model-invocation)がありません。説明文の起動語は広く、テストに少し触れただけの会話でも読み込まれる余地があります。負担になる場合は、プラグインを無効にするか、ユーザー呼び出し専用に切り替えます。同じプラグインのdeploy-checklistを含む導入時の判断は、deploy-checklistの手順でも触れています。

計画とテスト実行は別物

スキルが出すのは計画です。テストを実行する、CIに組み込む、といった作業は定義に含まれていません。E2Eを1本許容する、という判断を実際のCI設定に落とす作業は別に頼みます。

つまずきやすい点

• 計画が一般論に終わる: 構成と制約を渡さず「テスト計画を作って」とだけ頼むと、ピラミッドの説明に近い内容になりがちです。コンポーネント名・言語・既存テストの状況を書きます。
• 目標値が毎回違う: 基準値が定義に無いため、依頼のたびに数字が揺れます。CLAUDE.md に固定します。
• テストを書いてもらうつもりが計画が出た: 起動語に write tests for が含まれるためです。「計画は不要」と明示します。
• ギャップの指摘が曖昧: 計測結果を渡していないと、推測の指摘になります。カバレッジのレポートを先に作ります。

まとめ

testing-strategyは、コンポーネントの種類ごとにテストの型を考えさせる30行ほどのスキルです。数字や優先順位は定義に無く、構成・既存テスト・CIの制約を依頼文で渡し、目標値を CLAUDE.md に固定することで、計画が実用的な精度になります。まずは自分のサービスの構成を4行で書き、制約付きで1回依頼してみて、計画に載らなかった観点を CLAUDE.md に足していく進め方が現実的です。