Quality Assurance

品質保証

概要

品質保証は、包括的なテスト戦略、コード品質の徹底、フェーズゲート検証という、3 つの重要な品質側面を統合したスキルです。あらゆる段階で、コードがテスト済みで保守しやすく、本番環境へのデプロイに備えられていることを保証します。

以下を統合しています：

• testing-strategist - テストピラミッドと包括的なテスト
• code-quality-enforcer - コード標準とベストプラクティス
• validation-gate-checker - フェーズ移行の検証

このスキルを使用する場面

次の場合に品質保証を使用します：

• プロジェクトのテストインフラを構築するとき
• コードレビューを実施するとき
• プロジェクトのフェーズ間を移行する準備ができているか検証するとき
• チームの品質基準を確立するとき
• 本番環境の品質問題をデバッグするとき
• コードの保守性を高めるとき
• 本番環境への準備ができていることを確認するとき

主な機能

テスト戦略（testing-strategist より）

• 最適なカバレッジを備えたテストピラミッドを設計する
• 単体テスト、統合テスト、E2E テストの戦略を定義する
• カバレッジ目標と品質指標を設定する
• テストフレームワークとツールを選定する
• テスト自動化と CI/CD 統合を計画する

コード品質（code-quality-enforcer より）

• コーディング標準とベストプラクティスを徹底する
• コードの可読性と保守性をレビューする
• セキュリティの脆弱性とアンチパターンを特定する
• 型安全性とエラー処理を確保する
• 品質スコアを向上させるためにコードをリファクタリングする

検証ゲート（validation-gate-checker より）

• フェーズ移行の基準を定義する
• 次のフェーズに進む準備ができているか検証する
• 成果物が完成していることを確認する
• 標準への準拠を確認する
• 時期尚早なフェーズ移行を防ぐ

ワークフロー

パート 1：テスト戦略

テストピラミッド

構成：

        /\
       /E2E\      10% - End-to-End (Critical user flows)
      /------\
     /Integr-\   20% - Integration (Components, APIs, DB)
    /----------\
   /   Unit     \ 70% - Unit (Functions, classes, logic)
  /--------------\

根拠：

• 単体テストは高速で、分離されており、保守コストが低いです
• 統合テストは、コンポーネント間の連携に関する問題を検出します
• E2E テストは重要なユーザーワークフローを検証しますが、実行が遅く、不安定です

---

単体テスト（テスト全体の 70%）

カバレッジ目標：

• 重要なコード（認証、決済、セキュリティ）：100%
• ビジネスロジック：>90%
• コードベース全体：>85%

テスト対象：

• 純粋関数とビジネスロジック
• エッジケースとエラー条件
• 入力の検証
• 状態管理
• ユーティリティ関数

ベストプラクティス：

• ソースファイルごとにテストファイルを 1 つ用意する
• 高速に実行する（テストあたり <1ms）
• 外部依存関係を使用しない（モック／スタブを使用）
• 説明的なテスト名を付ける
• AAA パターン（Arrange、Act、Assert）を使用する

例：

// Good: Fast, isolated, clear
describe('calculateDiscount', () => {
  it('applies 10% discount for orders over $100', () => {
    const result = calculateDiscount(150)
    expect(result).toBe(15)
  })

  it('returns 0 for orders under $100', () => {
    const result = calculateDiscount(50)
    expect(result).toBe(0)
  })

  it('throws error for negative amounts', () => {
    expect(() => calculateDiscount(-10)).toThrow()
  })
})

---

統合テスト（テスト全体の 20%）

テスト対象：

• 実際のデータベースを使った API エンドポイント
• 連携して動作する複数のコンポーネント
• サードパーティサービスとの統合（モックを使用）
• データベースクエリとトランザクション
• ファイルシステム操作

ベストプラクティス：

• テスト用データベースのセットアップ／ティアダウンを行う
• テスト用データベースまたはトランザクションを使用する
• 外部サービスをモックする
• 正常系と主要なエラーシナリオをテストする
• テストあたり <5 秒で実行する

例：

// Good: Real database, tests integration
describe('POST /api/users', () => {
  beforeEach(async () => {
    await db.users.deleteMany({})
  })

  it('creates user and returns 201', async () => {
    const response = await request(app)
      .post('/api/users')
      .send({ email: '[email protected]', name: 'Test' })

    expect(response.status).toBe(201)
    expect(response.body.email).toBe('[email protected]')

    const user = await db.users.findOne({ email: '[email protected]' })
    expect(user).toBeDefined()
  })

  it('returns 400 for duplicate email', async () => {
    await db.users.create({ email: '[email protected]' })

    const response = await request(app)
      .post('/api/users')
      .send({ email: '[email protected]', name: 'Test' })

    expect(response.status).toBe(400)
  })
})

---

E2E テスト（テスト全体の 10%）

テスト対象：

• 重要なユーザーワークフロー（サインアップ、チェックアウトなど）
• 複数ページにわたるユーザーの操作経路
• バックエンドとの UI 操作
• クロスブラウザー互換性（必要な場合）

ベストプラクティス：

• 重要な経路のみをテストする
• ページオブジェクトパターンを使用する
• デプロイ前に CI/CD で実行する
• 実行に時間がかかることを許容する（テストあたり 30s-2min）
• CI ではヘッドレスブラウザーを使用する

例：

// Good: Tests complete user flow
describe('User Signup Flow', () => {
  it('allows new user to signup and access dashboard', async () => {
    await page.goto('/signup')

    await page.fill('input[name="email"]', '[email protected]')
    await page.fill('input[name="password"]', 'SecurePass123!')
    await page.click('button[type="submit"]')

    await page.waitForURL('/dashboard')
    expect(await page.textContent('h1')).toContain('Welcome')
  })
})

---

テストツールの推奨

JavaScript/TypeScript：

• 単体テスト：Jest または Vitest
• 統合テスト：Supertest（API）+ Jest
• E2E：Playwright または Cypress

Python：

• 単体テスト：pytest
• 統合テスト：fixture を使った pytest
• E2E：Selenium または Playwright

全般：

• カバレッジ：Istanbul（JS）、Coverage.py（Python）
• CI/CD：GitHub Actions、CircleCI、GitLab CI
• モック：Jest（JS）、unittest.mock（Python）

---

パート 2：コード品質の徹底

コード品質の原則

1. 読みやすさ

• 説明的な変数名と関数名
• 単一責任の原則
• 明確で一貫性のある書式
• 「何を」ではなく「なぜ」を説明するコメント

2. 保守性

• DRY（同じことを繰り返さない）
• SOLID 原則
• 型安全性（TypeScript、型ヒント）
• あらゆる箇所でのエラー処理

3. テスト

• すべての関数に対する単体テスト
• エッジケースを網羅
• 動作を説明するテスト名

4. セキュリティ

• シークレットをハードコードしない
• 入力値の検証
• SQL インジェクションの防止
• XSS 対策

---

コード品質チェックリスト

コードレビューの前に：

• シークレットや API キーをハードコードしていない
• 関数が 50 行未満（長い場合は分割する）
• エラー処理がある（try/catch、null チェック）
• すべてのテストに合格している
• 型安全性を確保している（TypeScript の strict モード、Python の型ヒント）
• console.log やデバッグ用コードがない
• 説明的な変数名を使っている（x、tmp、data などは使わない）
• コメントは「何を」ではなく「なぜ」を説明している
• DRY を守っている（コードをコピー＆ペーストしていない）
• セキュリティのベストプラクティスを守っている（入力値の検証、サニタイズ）

---

コードレビューのガイドライン

確認する項目：

重大な問題（必ず修正）：

• セキュリティの脆弱性（SQL インジェクション、XSS、シークレット）
• 移行手順を伴わない破壊的変更
• エラー処理の不足
• ロジックやアルゴリズムの誤り
• パフォーマンスのボトルネック

重要な問題（修正すべき）：

• コードの重複（DRY 違反）
• 不適切な命名や構造
• 新しいコードに対するテストの不足
• 型安全性の違反
• 書式の不統一

軽微な問題（修正するとよい）：

• スタイルの不統一
• コメントの過剰
• 最適化の余地
• ドキュメントの改善点

---

コード品質スコア

採点システム（0～100）：

セキュリティ（30 点）：

• コードにシークレットがない（10 点）
• 入力値の検証（10 点）
• エラー処理（10 点）

読みやすさ（25 点）：

• 説明的な名前（10 点）
• 明確な構造（10 点）
• 適切なコメント（5 点）

テスト（25 点）：

• 単体テストのカバレッジ >85%（15 点）
• エッジケースのテスト（10 点）

保守性（20 点）：

• DRY の遵守（10 点）
• 関数が 50 行未満（5 点）
• 型安全性（5 点）

評価：

• 90-100：優秀
• 80-89：良好
• 70-79：許容範囲
• <70：改善が必要

---

パート 3：検証ゲート

検証ゲートにより、次のフェーズに進む前に各フェーズが完了していることを確認します。

フェーズ 1 → フェーズ 2（発見 → 設計）

ゲートの基準：

• PRP ドキュメントが完成し、レビュー済みである
• ユーザーと問題の記述を検証済みである
• 成功基準が定義され、測定可能である
• ユーザーストーリーが文書化されている（Jobs-to-be-Done）
• スコープについて関係者の合意が得られている
• 未解決の質問が担当者とともに記録されている

成果物：

• 製品要件プロンプト（PRP）
• ユーザー調査の概要
• 成功指標ダッシュボード

レビュー時の質問：

• ユーザーの問題を理解できていますか？
• 成功を測定できますか？
• スコープは明確で、合意されていますか？

---

フェーズ 2 → フェーズ 3（設計 → 開発）

ゲートの基準：

• アーキテクチャが文書化されている（システム図）
• データモデルが設計されている（ERD またはスキーマ）
• API コントラクトが定義されている（該当する場合）
• セキュリティ上の脅威が特定されている（脅威モデル）
• 重大な脅威への緩和策が計画されている
• 技術スタックが承認されている
• インフラストラクチャ計画が文書化されている

成果物：

• アーキテクチャドキュメント
• データモデル / ERD
• API 仕様（OpenAPI/Swagger）
• 緩和策を含む脅威モデル
• インフラストラクチャ図

レビュー時の質問：

• アーキテクチャは堅牢で、スケーラブルですか？
• セキュリティ上の脅威は緩和されていますか？
• 必要なインフラストラクチャへのアクセス権がありますか？

---

フェーズ 3 → フェーズ 4（開発 → テスト）

ゲート基準：

• すべての P0 機能が完成している
• 単体テストのカバレッジが 80% 超
• コードレビューが完了している
• 静的解析（SAST）に合格している
• 重大または高深刻度の問題がない
• エラー処理が実装されている
• ロギングと監視が整備されている

成果物：

• 動作するソフトウェア（すべての P0 機能）
• テストカバレッジレポート
• コードレビューの承認
• SAST スキャン結果

レビュー時の質問：

• すべての MVP 機能が完成していますか？
• コード品質は許容できる水準ですか？
• 重大なバグは解決されていますか？

---

フェーズ 4 → フェーズ 5（テスト → デプロイ）

ゲート基準：

• すべてのテスト（単体、統合、E2E）に合格している
• テストカバレッジが 90% 超
• ユーザー受け入れテスト（UAT）が完了している
• セキュリティテスト（DAST、侵入テスト）に合格している
• パフォーマンステスト（負荷、ストレス）に合格している
• ドキュメント（ユーザー向け + 開発者向け）が完成している
• ロールバック計画が文書化されている
• デプロイ手順書が準備できている

成果物：

• テスト結果（すべて合格）
• UAT の承認
• セキュリティテストレポート
• パフォーマンステスト結果
• デプロイ手順書

レビュー時の質問：

• 品質に確信を持てていますか？
• 必要に応じてロールバックできますか？
• 本番環境のインフラストラクチャは準備できていますか？

---

例

例 1：API テスト戦略

プロジェクト： ユーザー管理用 REST API

テスト計画：

単体テスト（70%）：

• ビジネスロジック（検証、権限）
• データ変換
• ユーティリティ関数
• エラー処理ロジック

統合テスト（20%）：

• POST /users（DB にユーザーを作成）
• GET /users/:id（DB から取得）
• PUT /users/:id（DB で更新）
• DELETE /users/:id（DB から削除）
• 認証ミドルウェア
• エラーレスポンス（400、401、404、500）

E2E テスト（10%）：

• 登録からログインまでの一連のフロー（ユーザー作成 → メール確認 → ログイン）
• パスワードリセットのフロー
• プロフィール更新のフロー

ツール：

• Jest（単体テスト）
• Supertest（統合テスト）
• Playwright（E2E）

カバレッジ目標： 全体で 90%

---

例 2：コード品質レビュー

修正前（品質が低い - スコア：55/100）：

// Bad: Hardcoded secret, no error handling, poor naming
function getData(x) {
  const result = fetch('https://api.example.com/data', {
    headers: { Authorization: 'Bearer sk_live_abc123' }
  })
  return result.json()
}

問題点：

• セキュリティ：API キーがハードコードされている（-10 点）
• エラー処理：なし（-10 点）
• 命名：変数名が不適切（-10 点）
• テスト：テストがない（-15 点）

修正後（品質が高い - スコア：95/100）：

// Good: Secure, robust, clear
async function fetchUserData(userId: string): Promise<UserData> {
  try {
    const apiKey = process.env.API_KEY;
    if (!apiKey) {
      throw new Error('API_KEY environment variable not set');
    }

    const response = await fetch(`https://api.example.com/users/${userId}`, {
      headers: { 'Authorization': `Bearer ${apiKey}` }
    });

    if (!response.ok) {
      throw new Error(`API request failed: ${response.status}`);
    }

    return await response.json();
  } catch (error) {
    logger.error('Failed to fetch user data', { userId, error });
    throw new Error(`Failed to fetch user ${userId}`);
  }
}

// Tests
describe('fetchUserData', () => {
  it('fetches user successfully', async () => {
    // Test implementation
  });

  it('throws error if API_KEY not set', async () => {
    // Test implementation
  });
});

---

例 3：フェーズゲートの検証

プロジェクト： カスタマーサポートチャットボット（フェーズ 3 → フェーズ 4）

検証チェック：

要件：

• ✅ すべての P0 機能が完成している（チャット UI、AI の応答、エスカレーション）
• ✅ 単体テストのカバレッジ：87%
• ✅ コードレビュー：承認済み（レビュアー 2 名）
• ❌ SAST スキャン：中程度の深刻度の問題が 3 件（不合格）
• ✅ エラー処理：実装済み
• ✅ ロギング：Datadog との統合が完了

判定： ゲート不合格 - 次に進む前に SAST の問題を修正する必要があります

対応事項：

1. 中程度の深刻度の問題 3 件を修正する（入力検証）
2. SAST スキャンを再実行する
3. ゲート基準を再レビューする

合格までの推定時間： 2 日

---

ベストプラクティス

テスト

1. 先にテストを書く（TDD） - 要件が明確になります
2. テストを独立させる - 状態を共有しないようにします
3. 実装ではなく振る舞いをテストする - リファクタリングに強いテストになります
4. 説明的なテスト名を使う - テストはドキュメントになります
5. 素早く失敗させる - まず高速なテストを実行します

コード品質

1. 品質チェックを自動化する - ESLint、Prettier、型チェック
2. まず自分のコードをレビューする - 明らかな問題を見つけます
3. 小規模で焦点を絞った PR にする - 十分にレビューしやすくなります
4. 根本原因を修正する - 症状にパッチを当てるだけにしないでください
5. 継続的にリファクタリングする - 技術的負債を蓄積させないでください

検証ゲート

1. 基準を事前に文書化する - 想定外の事態を防ぎます
2. 重大なゲートには厳格に対応する - セキュリティ、本番環境への準備状況
3. あると望ましい項目には柔軟に対応する - 進行を妨げないようにします
4. ゲートの通過状況を追跡する - ボトルネックを特定します
5. チェックを自動化する - CI/CD で適用します

---

よくある落とし穴

1. 間違った対象をテストする

アンチパターン： 実装の詳細（プライベートメソッド）をテストする 推奨： パブリック API と振る舞いをテストする

2. エッジケースの網羅性不足

アンチパターン： 正常系だけをテストする 改善策： null、空の配列、エラー、境界値をテストする

3. フェーズゲートの省略

アンチパターン： 「リリースしてから修正します」 結果： 本番環境でのバグ、セキュリティ上の問題

改善策： ゲートを徹底し、必要に応じて延期する

4. 品質の過剰な追求

アンチパターン： すべてを100％網羅しようとし、完璧主義で身動きが取れなくなる 改善策： リスクに合わせた現実的な品質を目指す

5. 手動での品質チェック

アンチパターン： コミット前にリンターを実行するのを覚えておく 改善策： コミット前フックとCI/CDで自動化する

---

関連スキル

• testing-strategist - 元のテストスキル（現在は統合済み）
• security-architect - セキュリティテストと脅威の検証
• deployment-advisor - 本番環境への準備状況の検証
• performance-optimizer - パフォーマンステストと最適化
• framework-orchestrator - フェーズ移行に検証ゲートを使用

---

成果物

品質保証を利用する際は、以下を作成します。

1. テスト戦略ドキュメント

   • テストピラミッドの内訳
   • カバレッジ目標
   • ツールとフレームワーク
   • CI/CD統合計画

2. コード品質基準

   • スタイルガイド
   • リントルール
   • レビューチェックリスト
   • 品質スコアの評価基準

3. フェーズゲートの基準

   • 各フェーズの開始条件と終了条件
   • 必要な成果物
   • レビュープロセス
   • 承認権限

4. 品質ダッシュボード

   • テストカバレッジの指標
   • コード品質スコア
   • ゲート通過状況の追跡
   • 傾向分析

---

成功指標

以下を満たしていれば、品質保証は機能しています。

• テストカバレッジが常に85％を超えている
• リリースに占める本番環境のバグが1％未満である
• コードレビューでマージ前に問題が見つかる
• フェーズゲートによって時期尚早な移行が防がれている
• 品質が時間とともに向上している（低下していない）
• チームが強制されなくても基準に従っている
• CI/CDパイプラインが品質を自動的に担保している

---

忘れないでください： 品質は任意ではありません。持続可能なソフトウェアと技術的破産を分けるものです。