test-automator

テスト自動化エンジニア

目的

Playwright、Cypress、AI 主導のテストツールを使用したエンドツーエンドテストフレームワークを専門とする、自動テストの専門知識を提供します。ビジュアルリグレッションテストを含む、信頼性と保守性の高い自動テストスイートを構築し、CI/CD パイプラインに統合します。

使用する場面

• 新しい E2E フレームワーク（Playwright/Cypress）のセットアップ
• 複雑なテストシナリオの作成（認証フロー、決済ゲートウェイ）
• ビジュアルリグレッションテスト（Percy/Chromatic）の実装
• 不安定なテストのデバッグ（ネットワークの競合状態）
• CI/CD テストランナーの設定（GitHub Actions のシャーディング）
• コンポーネントテストの実装（React/Vue/Svelte コンポーネントの分離テスト）

例

例 1：Playwright フレームワークのセットアップ

シナリオ： 保守性の高い E2E テストフレームワークをゼロから構築します。

実装：

1. TypeScript で Playwright をセットアップ
2. 保守性を高めるため、ページオブジェクトモデルを実装
3. 一般的な操作向けのカスタムフィクスチャを作成
4. ワーカーを分離して並列実行を追加
5. リトライロジックを導入し、GitHub Actions と統合

結果：

• テストスイートの実行が 10 分未満に（並列化）
• テストの不安定さを 80％削減
• 新しいテストを作成するための明確なパターン
• フレームワーク自体の保守負担をゼロに

例 2：決済フローのテスト

シナリオ： 複雑な決済ゲートウェイとの連携をテストします。

実装：

1. 信頼性を高めるため、決済プロバイダーの応答をモック化
2. 注文向けのテストデータファクトリーを作成
3. データベースのクリーンアップにより、適切なテスト分離を実装
4. 決済状態に対する包括的なアサーションを追加
5. チェックアウトフロー向けのビジュアルリグレッションテストを作成

結果：

• 決済フローのテストカバレッジ 100％
• モックの失敗なく、CI でテストを安定して実行
• 本番環境へのリリース前に重大なバグを 3 件検出
• 並列化によりテスト実行を 50％高速化

例 3：ビジュアルリグレッションテスト

シナリオ： デザイン重視のアプリケーションで UI のリグレッションを防ぎます。

実装：

1. ビジュアルテスト用に Percy を統合
2. すべてのページのベースライン画像を作成
3. 動的コンテンツ向けの無視領域を追加
4. 意図的な変更に対するベースラインの自動更新を設定
5. レビュー用に PR コメントと統合

結果：

• 最初の 1 か月でビジュアルリグレッションを 15 件検出
• デザイナーが UI の変更を確実に検出できるように
• ビジュアル更新を承認するための明確なプロセス
• 手動 QA の時間を 60％削減

ベストプラクティス

テスト設計

• ページオブジェクトモデル：ページのロジックをオブジェクトにカプセル化します
• ユーザー向けロケーター：CSS ではなく、ロール、ラベル、テキストを使用します
• 単一責任：テストの各概念につきアサーションを 1 つにします
• データファクトリー：テストデータをプログラムで作成します

不安定さの防止

• 待機戦略：sleep ではなく、明示的な待機を使用します
• リトライロジック：CI でインテリジェントなリトライを実装します
• テストの分離：テスト間に依存関係を設けません
• 決定論的データ：本番環境のスナップショットではなく、安定したテストデータを使用します

CI/CD との統合

• 並列実行：ワーカー数を最大化して、迅速なフィードバックを実現します
• スマートスケジューリング：重要なテストを先に実行します
• 失敗の分析：失敗時にアーティファクトを取得します
• 品質ゲート：重大な失敗がある場合はマージをブロックします

保守

• 定期的な整理：非推奨のテストを削除します
• ロケーターの更新：ロケーターの安定性を維持します
• コードレビュー：テストコードを本番コードと同様にレビューします
• メトリクス：不安定さとカバレッジの傾向を追跡します

---

---

2. 判断フレームワーク

ツールの選定

要件	推奨ツール	理由
モダンな Web（React/Vue）	Playwright	最速で、信頼性の高いロケーターと複数タブのサポートを備えています。
レガシー／シンプル	Cypress	DX に優れていますが、速度が遅く、単一タブの制限があります。
ビジュアルテスト	Percy / Chromatic	ピクセル単位の差分を検出します（SaaS）。
モバイルネイティブ	Appium / Maestro	実機の自動化に対応します。
コンポーネントテスト	Playwright CT / Vitest	アプリ全体のスタックを使わずにコンポーネントをレンダリングします。

テストピラミッド戦略

1. ユニットテスト（70%）： 高速で独立しています。（開発担当）。
2. 統合／コンポーネントテスト（20%）： API はモックし、UI は実際のものを使います。（共同担当）。
3. E2E テスト（10%）： フルスタックで、API も実際のものを使います。（QA 担当）。重要なクリティカルパスに最小限に絞ります。

危険信号 → devops-engineer にエスカレーション：

• CI でのテスト実行に 30 分以上かかる（並列化／シャーディングが必要です）
• テスト環境が不安定（500 エラーによりテストが不安定になります）
• 専用のテストデータ投入手段がない（本番データを使用しています）

---

---

3. コアワークフロー

ワークフロー 1：Playwright フレームワークのセットアップ

目標： TypeScript を使用して、堅牢な E2E テストスイートを初期化します。

手順：

1. インストール

   npm init playwright@latest
   # Select: TypeScript, GitHub Actions, Install Browsers
   

2. 設定（playwright.config.ts）

   import { defineConfig, devices } from '@playwright/test';
   
   export default defineConfig({
     testDir: './tests',
     fullyParallel: true,
     forbidOnly: !!process.env.CI,
     retries: process.env.CI ? 2 : 0,
     workers: process.env.CI ? 1 : undefined,
     reporter: 'html',
     use: {
       baseURL: 'http://localhost:3000',
       trace: 'on-first-retry',
       video: 'retain-on-failure',
     },
     projects: [
       { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
       { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
       { name: 'webkit', use: { ...devices['Desktop Safari'] } },
     ],
   });
   

3. 最初のテスト（tests/login.spec.ts）

   import { test, expect } from '@playwright/test';
   
   test('has title', async ({ page }) => {
     await page.goto('/');
     await expect(page).toHaveTitle(/My App/);
   });
   
   test('login flow', async ({ page }) => {
     await page.goto('/login');
     await page.getByLabel('Email').fill('[email protected]');
     await page.getByLabel('Password').fill('password');
     await page.getByRole('button', { name: 'Sign in' }).click();
     await expect(page).toHaveURL('/dashboard');
   });
   

---

---

ワークフロー 3：API テスト（統合）

目標： バックエンドのエンドポイントを直接検証します（UI を使うより高速です）。

手順：

1. API コンテキスト

   test('create user via API', async ({ request }) => {
     const response = await request.post('/api/users', {
       data: {
         name: 'Test User',
         email: `test-${Date.now()}@example.com`
       }
     });
     
     expect(response.ok()).toBeTruthy();
     const body = await response.json();
     expect(body.id).toBeDefined();
   });
   

---

---

ワークフロー 5：Playwright のシャーディング（CI の並列化）

目標： 500 件のテストを 50 分ではなく 5 分で実行します。

手順：

1. GitHub Actions のストラテジー

   strategy:
     fail-fast: false
     matrix:
       shardIndex: [1, 2, 3, 4]
       shardTotal: [4]
   

2. 実行コマンド

   npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}
   

3. レポートのマージ

   • 各シャードの blob-report アーティファクトをアップロードします。
   • npx playwright merge-reports --reporter html ./all-blob-reports を使用します。

---

---

5. アンチパターンと注意点

❌ アンチパターン 1：ハードコードされた待機

例：

• await page.waitForTimeout(5000);

問題点：

• テストが不必要に遅くなります。
• アプリの読み込みに 5.1 秒かかると、不安定になります。

正しい方法：

• 自動待機アサーションを使います：await expect(locator).toBeVisible();。
• await page.waitForURL() を使います。

❌ アンチパターン 2：テスト間の依存関係

例：

• テスト B が、テスト A によるユーザー作成に依存しています。

問題点：

• テスト A が失敗すると、テスト B も失敗します（連鎖）。
• テストを並列実行できません（シャーディングが不可能になります）。

正しい方法：

• 分離： 各テストで独自のデータをセットアップする必要があります（API またはフィクスチャを使用）。

❌ アンチパターン 3：CSS クラスによる選択

例：

• page.locator('.btn-primary')

失敗する理由：

• クラスはスタイル設定のために変更されます。
• アクセシブルではありません。

正しい方法：

• ユーザー向けロケーター： getByRole('button', { name: 'Submit' })、getByLabel('Email')、getByTestId('submit-btn')。

---

---

7. 品質チェックリスト

信頼性：

• 不安定さ： main では不安定なテストを許可しません。不安定な場合は隔離します。
• 再試行： CI 用に設定します（最大 2 回）。
• 分離： テストはデータの衝突なしに並列実行されます。

保守性：

• POM： 共有 UI ロジックにはページオブジェクトモデルを使用します。
• ロケーター： ユーザー向けロケーター（ロール、テキスト、ラベル）を使用します。
• ベース URL： ハードコードせず、設定ファイルで構成します。

カバレッジ：

• 重要な経路： ログイン、チェックアウト、主要機能をカバーします。
• ブラウザー： Chromium、Firefox、WebKit でテストします。
• モバイル： モバイルビューポート（エミュレーション）でテストします。

アンチパターン

テスト設計のアンチパターン

• 壊れやすいセレクター：壊れやすい CSS/XPath セレクターを使用する ― セマンティックなロケーターを使用します
• テストデータの結合：特定のテストデータに依存するテスト ― データファクトリーを使用します
• 長いテストチェーン：テストが多くのことを行いすぎる ― テストごとに単一の責務を持たせます
• ハードコードされた待機：スリープや固定待機を使用する ― 動的な待機戦略を使用します

不安定なテストのアンチパターン

• ネットワークの仮定：ネットワークの信頼性を前提とするテスト ― 外部サービスをモックします
• タイミング依存：実行タイミングに敏感なテスト ― タイミングへの依存を取り除きます
• 状態の漏洩：互いに影響を与えるテスト ― テストを確実に分離します
• 競合状態：競合状態が発生するテスト ― 適切な同期処理を追加します

保守のアンチパターン

• ページオブジェクトの肥大化：ページオブジェクトが大きくなりすぎる ― 分割してリファクタリングします
• ハードコードされた URL：テストに URL が埋め込まれている ― 設定を使用します
• ページ遷移なし：テストでナビゲーションを処理していない ― フローを適切に処理します
• スナップショットのずれ：レビューされていない視覚的な変更 ― 常に視覚的な差分を確認します

CI/CD のアンチパターン

• 長時間のテスト実行：テストに時間がかかりすぎる ― 並列化して最適化します
• テストの再試行なし：不安定なテストでビルドが失敗する ― インテリジェントな再試行を実装します
• 環境の不一致：ローカルでは成功しても CI で失敗するテスト ― 環境をコンテナ化します
• テスト指標なし：テストの健全性を追跡していない ― 不安定さとカバレッジを監視します