k2works/analyzing-test-strategy
.agents/skills/analyzing-test-strategy/SKILL.md
テストピラミッド設計、テスト種別の定義、カバレッジ目標の設定を含むテスト戦略を策定。「テスト戦略を決めたい」「テスト計画を立てたい」「カバレッジ目標を設定したい」「テストピラミッドを設計したい」「TDD/BDD の方針を決めたい」といった場面で発動する。テスト戦略を先に策定することで、開発中の「何をどこまでテストすべきか」の迷いを排除する。
testing
Updated Apr 16, 2026
$ install --global
skillsauthnpx skillsauth add k2works/getting-started-algorithm analyzing-test-strategyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 30, 2026, 1:25 AM12.0s1 file scanned
SKILL.md
- name:
- analyzing-test-strategy
- description:
- テストピラミッド設計、テスト種別の定義、カバレッジ目標の設定を含むテスト戦略を策定。「テスト戦略を決めたい」「テスト計画を立てたい」「カバレッジ目標を設定したい」「テストピラミッドを設計したい」「TDD/BDD の方針を決めたい」といった場面で発動する。テスト戦略を先に策定することで、開発中の「何をどこまでテストすべきか」の迷いを排除する。
テスト戦略策定
アーキテクチャパターンに適合するテスト形状（ピラミッド型・ダイヤモンド型・逆ピラミッド型）を選択し、テスト戦略を策定する。
テスト戦略はアーキテクチャと表裏一体。レイヤードアーキテクチャならピラミッド型、マイクロサービスならダイヤモンド型が適合しやすい。テスト形状を間違えると、テストの実行時間が爆発するか、品質保証が不十分になる。
参照ドキュメントとテンプレート
| 種類 | パス | 備考 |
|------|------|------|
| ガイド | @docs/reference/テスト戦略ガイド.md | テスト戦略の進め方詳細 |
| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
| 成果物 | docs/design/test_strategy.md | テスト戦略 |
テスト形状の選択
アーキテクチャパターンとシステム特性に基づいてテスト形状を選択する。形状の選択理由を明記せよ。
- ピラミッド型（ユニット重視）: ビジネスロジックが複雑でドメイン層が厚い場合に適する。ユニットテストを土台に高速なフィードバックを得る
- ダイヤモンド型（統合テスト重視）: マイクロサービスや外部連携が多い場合に適する。サービス間の結合点を重点的にテストする
- 逆ピラミッド型（E2E 重視）: UI 中心のアプリケーションやレガシーシステムの保護に適する。ただし実行時間とメンテナンスコストが高いことを認識せよ
テストレベルの定義
各テストレベルの責務を明確に定義する。テストレベル間で検証内容が重複すると、テストスイート全体の実行時間が不必要に増える。
- ユニットテスト: 単一クラス/関数の振る舞いを検証する。外部依存はモックする
- 統合テスト: コンポーネント間の連携を検証する。DB やメッセージキューとの結合を含む
- E2E テスト: ユーザーシナリオに基づいてシステム全体を検証する
- 受け入れテスト: ユーザーストーリーの受入条件を検証する
テスト戦略の策定
具体的な数値目標とツール選定を行う。曖昧な「十分にテストする」ではなく、測定可能な基準を設定せよ。
- カバレッジ目標: テストレベルごとのカバレッジ目標を設定する（例: ユニット 80%、統合 60%）
- テストツールの選定: 技術スタックに適合するテストツールを選定する
- CI/CD との連携: テスト実行のタイミングと失敗時の振る舞いを定義する
トレーサビリティの確保
要件からテストケースまでの追跡を可能にする。「この機能はどのテストで保証されているか」を常に回答可能にせよ。
- 要件とテストケースのマッピング: ユーザーストーリーの受入条件とテストケースを対応づける
作成の進め方
- アーキテクチャドキュメント（バックエンド・フロントエンド）を確認する
- @docs/reference/テスト戦略ガイド.md を読み込む
- テスト形状→テストレベル→カバレッジ目標→ツール選定の順に策定する
docs/design/test_strategy.mdとして出力する
途中から再開する場合
既存の docs/design/test_strategy.md がある場合は、まずその内容を確認する。不足しているテストレベルの定義や更新が必要な部分のみを修正する。
Example:
ユーザー: 「テスト形状はピラミッド型に決めた。カバレッジ目標を設定したい」
回答: 既存の test_strategy.md のテスト形状を確認し、
ピラミッド型に基づいてテストレベルごとのカバレッジ目標を設定する。
ユニット→統合→E2E の順に目標値と測定方法を定義する。
注意事項
- アーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
- テスト戦略はアーキテクチャパターンに適合させる。パターンとの不整合は無駄なテストを生む
- TDD/BDD の適用を検討し、開発プロセスとテスト戦略を一体化する
- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
関連スキル
orchestrating-analysis— 分析フェーズ全体のワークフロー案内analyzing-architecture— テスト形状選択の基盤となるアーキテクチャ設計analyzing-tech-stack— テストツール選定との整合性analyzing-non-functional— 性能テストの基準となる非機能要件
Related Skills
k2works/validating-iteration-plan
tools
VerifiedTrustedCommunity
イテレーション計画と上流設計ドキュメント群（ユーザーストーリー、ドメインモデル、データモデル、UI 設計）との整合性を検証する。「イテレーション計画を検証したい」「計画の整合性をチェックして」「イテレーション計画を作成した」「計画と設計ドキュメントの不整合を確認したい」といった場面で発動する。planning-releases でイテレーション計画を作成した直後にも積極的に使用すること。計画作成後に必ず本検証を実施することで、開発着手前にドキュメント間の不整合を検知・修正できる。
SKILL.mdUpdated Apr 16, 2026
k2works/tracking-progress
tools
VerifiedTrustedCommunity
プロジェクトの開発進捗を多角的に分析しレポートを生成。イテレーション達成度、技術実装状況、品質メトリクスを確認し、計画ドキュメントを自動更新する。「進捗を確認したい」「プロジェクトの状態を知りたい」「イテレーションの達成度を分析したい」「進捗ドキュメントを更新したい」といった場面で発動する。定期的な進捗可視化により、遅延や品質低下を早期に発見しプロジェクトの透明性を確保する。
SKILL.mdUpdated Apr 16, 2026
k2works/syncing-github-project
testing
VerifiedTrustedCommunity
リリース計画を GitHub Project・Issue・Milestone に反映し一元管理。初回の一括同期から差異検出・自動同期まで対応する。「GitHub Project に同期したい」「Issue を作成したい」「計画と GitHub の差異を確認したい」「Milestone を設定したい」といった場面で発動する。計画ドキュメントを Single Source of Truth とし GitHub に自動反映することで、二重管理の手間と不整合を排除する。
SKILL.mdUpdated Apr 16, 2026
k2works/practicing-getting-start-tdd
development
VerifiedTrustedCommunity
テスト駆動開発から始めるプログラミング入門」の対話式チュートリアル。FizzBuzz を題材に TDD の Red-Green-Refactor サイクルを 14 言語で体験する。「TDD を練習したい」「FizzBuzz で TDD を学びたい」「テスト駆動開発の入門をしたい」「Java で TDD を体験したい」「Python で TDD を始めたい」「プログラミング入門チュートリアルをやりたい」「getting-start-tdd をやりたい」「TDD のハンズオンがしたい」「Red-Green-Refactor を体験したい」といった場面で発動する。TDD チュートリアルやプログラミング入門の要望があれば積極的に使用すること。
SKILL.mdUpdated Apr 16, 2026