jpskill.com
🛠️ 開発・MCP コミュニティ

test-orchestrator

Coordinates testing strategy and execution across all test types. Use when creating test plans, implementing tests (unit/integration/E2E), or enforcing coverage requirements (80% minimum). Applies testing-requirements.md.

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o test-orchestrator.zip https://jpskill.com/download/17602.zip && unzip -o test-orchestrator.zip && rm test-orchestrator.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17602.zip -OutFile "$d\test-orchestrator.zip"; Expand-Archive "$d\test-orchestrator.zip" -DestinationPath $d -Force; ri "$d\test-orchestrator.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して test-orchestrator.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → test-orchestrator フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Test Orchestrator Skill

役割

QAリードとして機能し、システム全体のすべてのテスト活動を調整します。

責任

  1. テスト戦略

    • テスト計画の定義
    • テスト実行の調整
    • テスト環境の管理
    • カバレッジメトリクスの追跡
  2. テスト自動化

    • ユニットテストの調整
    • 統合テストスイート
    • E2Eテストシナリオ
    • パフォーマンステスト
  3. 品質ゲート

    • 受け入れ基準の定義
    • カバレッジ閾値の強制
    • 失敗したビルドのブロック
    • 品質メトリクスの報告
  4. コンテキストの維持

    ai-state/active/testing/
    ├── test-plans.json     # テスト戦略
    ├── coverage.json       # カバレッジメトリクス
    ├── results.json        # テスト結果
    └── tasks/             # アクティブなテストタスク

Skill の連携

利用可能なテスト Skill

  • unit-test-skill - ユニットテストの作成
  • integration-test-skill - 統合テスト
  • e2e-test-skill - エンドツーエンドのシナリオ
  • performance-test-skill - 負荷/ストレステスト
  • security-test-skill - セキュリティ検証

Skill へのコンテキストパッケージ

context:
  task_id: "task-004-testing"
  component: "authentication"
  test_requirements:
    unit: ["all public methods", ">80% coverage"]
    integration: ["database operations", "API calls"]
    e2e: ["login flow", "password reset"]
    performance: ["100 concurrent users", "<200ms response"]
  standards:
    - "testing-requirements.md"
  existing_tests:
    coverage: 65%
    failing: ["test_login_invalid"]

タスク処理フロー

  1. タスクの受信

    • コンポーネントの特定
    • 要件の確認
    • 既存のテストの確認
  2. テスト計画の作成

    • テストシナリオの定義
    • カバレッジ目標の設定
    • テストデータの特定
  3. Skill への割り当て

    • テストタイプの配布
    • 優先順位の設定
    • タイムラインの定義
  4. テストの実行

    • テストスイートの実行
    • 実行の監視
    • 結果の収集
  5. 品質の検証

    • カバレッジの確認
    • 失敗の確認
    • 修正の検証
    • レポートの生成

テストカテゴリ

ユニットテスト

  • [ ] すべてのパブリックメソッドがテストされている
  • [ ] エッジケースがカバーされている
  • [ ] モックが適切に使用されている
  • [ ] 高速な実行(<1秒)
  • [ ] 分離されたテスト
  • [ ] 明確なアサーション

統合テスト

  • [ ] コンポーネントの相互作用
  • [ ] データベース操作
  • [ ] API統合
  • [ ] メッセージキュー
  • [ ] ファイル操作
  • [ ] 外部サービス

E2Eテスト

  • [ ] ユーザーワークフロー
  • [ ] クリティカルパス
  • [ ] クロスブラウザ
  • [ ] モバイルレスポンシブ
  • [ ] エラーシナリオ
  • [ ] リカバリフロー

パフォーマンステスト

  • [ ] 負荷テスト
  • [ ] ストレステスト
  • [ ] スパイクテスト
  • [ ] ボリュームテスト
  • [ ] 耐久テスト
  • [ ] スケーラビリティテスト

テスト標準

テスト品質チェックリスト

  • [ ] 説明的なテスト名
  • [ ] AAAパターン(Arrange, Act, Assert)
  • [ ] 単一のアサーションに焦点を当てる
  • [ ] テストの相互依存性がない
  • [ ] 決定論的な結果
  • [ ] 意味のある失敗

カバレッジ要件

  • ユニットテスト: >80% のコードカバレッジ
  • 統合: すべてのAPIがテストされている
  • E2E: クリティカルパスがカバーされている
  • パフォーマンス: SLAを満たす
  • セキュリティ: OWASP top 10

統合ポイント

開発オーケストレーターとの連携

  • タスクからのテスト要件
  • 失敗フィードバックループ
  • カバレッジレポート
  • 品質ゲート

CI/CDパイプラインとの連携

  • 自動テスト実行
  • 失敗時のビルドブロック
  • テスト結果レポート
  • カバレッジトレンド

Human-Docs との連携

テストドキュメントを更新します。

  • テスト計画の変更
  • カバレッジレポート
  • 品質メトリクス
  • テストガイドライン

イベント通信

リッスンするイベント

{
  "event": "code.changed",
  "component": "user-service",
  "impact": ["auth", "profile"],
  "requires_testing": true
}

ブロードキャストするイベント

{
  "event": "tests.completed",
  "component": "user-service",
  "results": {
    "passed": 145,
    "failed": 2,
    "skipped": 3,
    "coverage": "85%"
  },
  "status": "FAILED"
}

テスト実行戦略

並列実行

class TestOrchestrator:
    def run_tests(self, suites):
        # 1. Identify independent tests
        # 2. Distribute across workers
        # 3. Collect results
        # 4. Aggregate coverage
        # 5. Generate report

テスト再試行ロジック

def retry_failed_tests(failures):
    MAX_RETRIES = 3
    for test in failures:
        for attempt in range(MAX_RETRIES):
            if run_test(test).passed:
                break
        else:
            mark_as_flaky(test)

成功指標

  • テスト実行時間 < 10分
  • カバレッジ > 80%
  • 不安定なテストの割合 < 1%
  • 誤検知率 < 0.1%
  • テストメンテナンス時間 < 10%

テストデータ管理

戦略

  1. Fixtures - 事前定義されたテストデータ
  2. Factories - 動的なデータ生成
  3. Snapshots - ベースライン比較
  4. Mocks - 外部サービスシミュレーション
  5. Stubs - 簡略化された実装

ベストプラクティス

  • テストデータを分離する
  • テスト後にクリーンアップする
  • リアルなデータを使用する
  • テストデータをバージョン管理する
  • データ要件を文書化する

一般的なテストパターン

Page Object Pattern (E2E)

class LoginPage {
  async login(email: string, password: string) {
    await this.emailInput.fill(email);
    await this.passwordInput.fill(password);
    await this.submitButton.click();
  }
}

Test Builder Pattern

def test_user_creation():
    user = UserBuilder()
        .with_email("test@example.com")
        .with_role("admin")
        .build()

    assert user.is_valid()

避けるべきアンチパターン

❌ 順序に依存するテスト ❌ ハードコードされたテストデータ ❌ 実装の詳細のテスト ❌ 遅いテストスイート ❌ 無視される不安定なテスト ❌ テストドキュメントがない

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Test Orchestrator Skill

Role

Acts as QA Lead, coordinating all testing activities across the system.

Responsibilities

  1. Test Strategy

    • Define test plans
    • Coordinate test execution
    • Manage test environments
    • Track coverage metrics
  2. Test Automation

    • Unit test coordination
    • Integration test suites
    • E2E test scenarios
    • Performance testing
  3. Quality Gates

    • Define acceptance criteria
    • Enforce coverage thresholds
    • Block failing builds
    • Report quality metrics
  4. Context Maintenance

    ai-state/active/testing/
    ├── test-plans.json     # Test strategies
    ├── coverage.json       # Coverage metrics
    ├── results.json        # Test results
    └── tasks/             # Active test tasks

Skill Coordination

Available Test Skills

  • unit-test-skill - Unit test creation
  • integration-test-skill - Integration testing
  • e2e-test-skill - End-to-end scenarios
  • performance-test-skill - Load/stress testing
  • security-test-skill - Security validation

Context Package to Skills

context:
  task_id: "task-004-testing"
  component: "authentication"
  test_requirements:
    unit: ["all public methods", ">80% coverage"]
    integration: ["database operations", "API calls"]
    e2e: ["login flow", "password reset"]
    performance: ["100 concurrent users", "<200ms response"]
  standards:
    - "testing-requirements.md"
  existing_tests:
    coverage: 65%
    failing: ["test_login_invalid"]

Task Processing Flow

  1. Receive Task

    • Identify component
    • Review requirements
    • Check existing tests
  2. Create Test Plan

    • Define test scenarios
    • Set coverage goals
    • Identify test data
  3. Assign to Skills

    • Distribute test types
    • Set priorities
    • Define timelines
  4. Execute Tests

    • Run test suites
    • Monitor execution
    • Collect results
  5. Validate Quality

    • Check coverage
    • Review failures
    • Verify fixes
    • Generate reports

Test Categories

Unit Testing

  • [ ] All public methods tested
  • [ ] Edge cases covered
  • [ ] Mocks properly used
  • [ ] Fast execution (<1s)
  • [ ] Isolated tests
  • [ ] Clear assertions

Integration Testing

  • [ ] Component interactions
  • [ ] Database operations
  • [ ] API integrations
  • [ ] Message queues
  • [ ] File operations
  • [ ] External services

E2E Testing

  • [ ] User workflows
  • [ ] Critical paths
  • [ ] Cross-browser
  • [ ] Mobile responsive
  • [ ] Error scenarios
  • [ ] Recovery flows

Performance Testing

  • [ ] Load testing
  • [ ] Stress testing
  • [ ] Spike testing
  • [ ] Volume testing
  • [ ] Endurance testing
  • [ ] Scalability testing

Test Standards

Test Quality Checklist

  • [ ] Descriptive test names
  • [ ] AAA pattern (Arrange, Act, Assert)
  • [ ] Single assertion focus
  • [ ] No test interdependencies
  • [ ] Deterministic results
  • [ ] Meaningful failures

Coverage Requirements

  • Unit Tests: >80% code coverage
  • Integration: All APIs tested
  • E2E: Critical paths covered
  • Performance: Meets SLAs
  • Security: OWASP top 10

Integration Points

With Development Orchestrators

  • Test requirements from tasks
  • Failure feedback loops
  • Coverage reporting
  • Quality gates

With CI/CD Pipeline

  • Automated test execution
  • Build blocking on failures
  • Test result reporting
  • Coverage trends

With Human-Docs

Updates testing documentation:

  • Test plan changes
  • Coverage reports
  • Quality metrics
  • Test guidelines

Event Communication

Listening For

{
  "event": "code.changed",
  "component": "user-service",
  "impact": ["auth", "profile"],
  "requires_testing": true
}

Broadcasting

{
  "event": "tests.completed",
  "component": "user-service",
  "results": {
    "passed": 145,
    "failed": 2,
    "skipped": 3,
    "coverage": "85%"
  },
  "status": "FAILED"
}

Test Execution Strategy

Parallel Execution

class TestOrchestrator:
    def run_tests(self, suites):
        # 1. Identify independent tests
        # 2. Distribute across workers
        # 3. Collect results
        # 4. Aggregate coverage
        # 5. Generate report

Test Retry Logic

def retry_failed_tests(failures):
    MAX_RETRIES = 3
    for test in failures:
        for attempt in range(MAX_RETRIES):
            if run_test(test).passed:
                break
        else:
            mark_as_flaky(test)

Success Metrics

  • Test execution time < 10 min
  • Coverage > 80%
  • Flaky test rate < 1%
  • False positive rate < 0.1%
  • Test maintenance time < 10%

Test Data Management

Strategies

  1. Fixtures - Predefined test data
  2. Factories - Dynamic data generation
  3. Snapshots - Baseline comparisons
  4. Mocks - External service simulation
  5. Stubs - Simplified implementations

Best Practices

  • Isolate test data
  • Clean up after tests
  • Use realistic data
  • Version test data
  • Document data requirements

Common Testing Patterns

Page Object Pattern (E2E)

class LoginPage {
  async login(email: string, password: string) {
    await this.emailInput.fill(email);
    await this.passwordInput.fill(password);
    await this.submitButton.click();
  }
}

Test Builder Pattern

def test_user_creation():
    user = UserBuilder()
        .with_email("test@example.com")
        .with_role("admin")
        .build()

    assert user.is_valid()

Anti-Patterns to Avoid

❌ Tests that depend on order ❌ Hardcoded test data ❌ Testing implementation details ❌ Slow test suites ❌ Flaky tests ignored ❌ No test documentation