test-automation-strategy について
自動テストスイートを構築・改善するチーム向けの戦略スキルです。テスト構成のパターン、CI/CD 連携、遅い・壊れやすい・不安定なテストへの対処を扱います。
主な機能
- 01自動化のよくあるアンチパターン検出
- 02Page Object、Builder、Factory パターンの活用
- 03CI/CD へのテスト統合
- 04不安定なテストの隔離と安定化
- 05ユニット・統合・E2E のテストピラミッド
活用シーン
- 01新しい自動テストフレームワークの設計
- 02遅いテストスイートの改善
- 03ランダムなテスト失敗の削減
- 04CI/CD パイプラインの高速化
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ proffesor-for-testing/ agentic-qe --skill test-automation-strategyインストール後、Claude Code で/test-automation-strategyを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evals/test-automation-strategy.yamlschemas/output.jsonscripts/validate-config.json詳細
テスト自動化戦略
<default_to_action> テスト自動化を設計または改善する際は、次の点に対応します。
- アンチパターンを検出します。アイスクリームコーン型ですか?テストスイートが遅いですか?不安定なテストがありますか?
- パターンを活用します。ページオブジェクトモデル、ビルダーパターン、ファクトリーパターン
- CI/CD に統合します。コミットごとにテストを実行し、早期に失敗させます
- 不安定なテストを管理します。隔離、修正、または削除し、決して無視しません
アンチパターンのクイック検出:
- アイスクリームコーン型(E2E が多く、ユニットテストが少ない)→ ピラミッド型に反転
- 遅いテスト(テストスイートが 10 分超)→ 並列化し、外部依存をモック化
- 不安定なテスト → タイミングを修正し、データを分離するか、隔離
- 壊れやすいセレクター → data-testid、セマンティックロケーターを使用 </default_to_action>
クイックリファレンスカード
使用する場面
- 新しい自動化フレームワークを構築する
- 既存のテスト効率を改善する
- 不安定なテストの負担を軽減する
- CI/CD パイプラインの速度を最適化する
検出するアンチパターン
| 問題 | 症状 | 修正方法 |
|---|---|---|
| アイスクリームコーン型 | E2E が 80%、ユニットテストが 10% | ピラミッド型に反転 |
| 遅いテストスイート | CI が 30 分以上 | 並列化し、不要なテストを削減 |
| 不安定なテスト | ランダムな失敗 | 隔離し、タイミングを修正 |
| 結合されたテスト | 実行順に依存 | データを分離 |
| 壊れやすいセレクター | CSS の変更で壊れる | data-testid を使用 |
CI/CD 統合
name: Test Pipeline
on: [push, pull_request]
jobs:
unit-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run test:unit -- --coverage
timeout-minutes: 5
- uses: codecov/codecov-action@v3
integration-tests:
needs: unit-tests
runs-on: ubuntu-latest
services:
postgres:
image: postgres:15
steps:
- run: npm run test:integration
timeout-minutes: 10
e2e-tests:
needs: integration-tests
runs-on: ubuntu-latest
steps:
- run: npx playwright test
timeout-minutes: 15
不安定なテストの管理
// Quarantine flaky tests
describe.skip('Quarantined - INC-123', () => {
test('flaky test awaiting fix', () => { /* ... */ });
});
// Agent-assisted stabilization
await Task("Fix Flaky Tests", {
tests: quarantinedTests,
analysis: ['timing-issues', 'data-isolation', 'race-conditions'],
strategies: ['add-waits', 'isolate-fixtures', 'mock-externals']
}, "qe-flaky-test-hunter");
エージェント支援による自動化
// Generate tests following pyramid
await Task("Generate Test Suite", {
sourceCode: 'src/',
pyramid: { unit: 70, integration: 20, e2e: 10 },
patterns: ['page-object', 'builder', 'factory'],
framework: 'jest'
}, "qe-test-generator");
// Optimize test execution
await Task("Optimize Suite", {
algorithm: 'johnson-lindenstrauss',
targetReduction: 0.3,
maintainCoverage: 0.95
}, "qe-regression-risk-analyzer");
// Analyze flaky patterns
await Task("Flaky Analysis", {
testHistory: 'last-30-days',
detectPatterns: ['timing', 'data', 'environment'],
recommend: 'stabilization-strategy'
}, "qe-flaky-test-hunter");
エージェント連携のヒント
メモリ名前空間
aqe/automation/
├── test-pyramid/* - Coverage by layer
├── page-objects/* - Shared page objects
├── flaky-registry/* - Quarantined tests
└── execution-metrics/* - Suite performance data
フリート連携
const automationFleet = await FleetManager.coordinate({
strategy: 'test-automation',
agents: [
'qe-test-generator', // Generate pyramid-compliant tests
'qe-test-executor', // Parallel execution
'qe-coverage-analyzer', // Coverage gaps
'qe-flaky-test-hunter', // Flaky detection
'qe-regression-risk-analyzer' // Smart selection
],
topology: 'hierarchical'
});
関連スキル
- tdd-london-chicago - ユニットテストのための TDD
- api-testing-patterns - 統合パターン
- cicd-pipeline-qe-orchestrator - パイプライン統合
- shift-left-testing - 早期の自動化
覚えておくこと
エージェントを使う場合: エージェントはピラミッド型に準拠したテストを生成し、不安定なパターンを検出して、実行時間を最適化し、テストインフラストラクチャを維持します。エージェントを活用して自動化の品質を高めましょう。
注意点
- エージェントが E2E テストを 80%、ユニットテストを 20%生成する(逆ピラミッド型)場合は、70/20/10 の比率を明示的に徹底します
- セレクターが変更されるとページオブジェクトモデルのテストは壊れやすくなります。CSS セレクターより data-testid 属性を優先します
- 不安定なテストを隔離したまま修正しないのは技術的負債です。修正または削除する期限として 2 週間の SLA を設定します
- エージェントがテストコードを二級市民として扱う場合があります。テストコードにも本番コードと同じレビュー基準が必要です
- テストの並列実行にはテストの分離が必要です。テスト間で状態を共有すると、非決定的な失敗が発生します
コメント
Markdown 対応