Quality Assurance Skill
品質保証・QAの包括的なガイド集。テスト計画、品質メトリクス、バグ管理、リリース判定基準、探索的テスト、ユーザビリティテストなど、ソフトウェア品質を確保するための実践的な手法を網羅します。
概要
このスキルでは、以下のトピックを扱います:
- 品質メトリクス: KPI設定、ダッシュボード構築、データドリブンな品質管理
- テスト計画: リスクベーステスト、テスト戦略、実行管理
- リリース管理: リリースクライテリア、段階的ロールアウト、ロールバック戦略
- バグ管理: トリアージ、優先度付け、ライフサイクル管理
- 探索的テスト: セッションベース、ペルソナベーステスト
- ユーザビリティテスト: SUS評価、アクセシビリティ、UXテスト
📚 公式ドキュメント・参考リソース
このガイドで学べること: QAプロセス構築、テスト計画策定、品質メトリクス設定、バグ管理、リリース判定基準 公式で確認すべきこと: 最新のテストツール、品質標準、業界ベストプラクティス
主要な公式ドキュメント
-
ISTQB Syllabus - ソフトウェアテストの国際標準
-
ISO/IEC 25010 - ソフトウェア品質モデル
-
WCAG 2.1 Guidelines - Webアクセシビリティガイドライン
-
XCTest Documentation - Apple公式テストフレームワーク
関連リソース
- Software Testing Help - QA総合リソース
- Ministry of Testing - テスターコミュニティ
- Google Testing Blog - Googleのテスト手法
詳細ガイド
Core Guides
1. QA Metrics & KPI Dashboard
品質保証における測定指標とKPIダッシュボードの構築・運用を完全解説。データドリブンな品質管理を実現。
主な内容:
- メトリクスの基礎: SMART原則、プロダクト/プロセス/プロジェクトメトリクス
- 主要KPI: バグKPI、テストKPI、パフォーマンスKPI、ユーザー満足度KPI
- バグメトリクス: バグ密度、流出率、再発率、エイジング分析
- テストメトリクス: カバレッジ4指標、実行メトリクス、自動化率、ROI分析
- パフォーマンスメトリクス: クラッシュ率、起動時間、API応答時間
- ダッシュボード構築: Grafana + Prometheus実装、リアルタイム監視
- レポーティング: 日次/週次レポート自動生成、Slack/Email統合
- ケーススタディ: E-commerce品質改善（-85%バグ削減）、SaaS QA体制構築
実績データ:
- 本番バグ削減: 20件/月 → 3件/月 (-85%)
- クラッシュ率改善: 0.3% → 0.07% (-77%)
- テストカバレッジ向上: 45% → 83% (+84%)
- リリースサイクル短縮: 4週間 → 2週間 (-50%)
2. テスト計画・実行ガイド
効果的なテスト計画の策定から実行、結果分析までを完全解説。プロジェクトの品質を確保するための実践ガイド。
主な内容:
- テスト計画の基礎: 計画書構成要素、Entry/Exit Criteria
- テスト戦略: リスクベーステスト、テストレベル別戦略（Unit/Integration/E2E）
- テストケース設計: 境界値分析、同値分割、デシジョンテーブル
- テスト実行管理: トラッキング、統計分析、失敗分析、アラート
- テストデータ管理: ファクトリーパターン、Faker活用、DBシーディング
- リグレッションテスト: 選択戦略（影響範囲/リスク/時間ベース）、スイート管理
- テスト環境管理: 環境構成、切り替え、YAML設定
- ケーススタディ: モバイルアプリテスト計画（iOS/Android）
3. リリース管理とクライテリア
リリース判定基準の策定からリリース後のモニタリングまで、安全で確実なリリースプロセスを完全解説。
主な内容:
- リリースクライテリア: 機能完了、品質基準、パフォーマンス、セキュリティ、ドキュメント
- Entry/Exit Criteria: テストフェーズ開始/終了条件、チェッカー実装
- リリース判定プロセス: Go/No-Go会議、判定フレームワーク、信頼度計算
- リリースチェックリスト: 開発/テスト/バグ/コード品質/ドキュメント/インフラ
- 段階的ロールアウト: カナリアリリース（5%→25%→50%→100%）、フィーチャーフラグ
- ロールバック戦略: 自動ロールバック、トリガー設定、通知統合
- リリース後モニタリング: 24時間監視計画、チェックポイント、アラート対応
- ケーススタディ: モバイルアプリリリース失敗と学び（クラッシュ率1.2%）
実績データ:
- リリース失敗率改善: 40% → 5% (-88%)
- 本番重大バグ削減: 8件 → 0.5件 (-94%)
- 顧客クレーム削減: 15件 → 2件 (-87%)
- 顧客満足度向上: 65% → 92% (+42%)
Practical Guides
4. QAプロセス完全ガイド
QAプロセス全体の実践的な手法。要件定義からリリース後まで。
5. テストの基礎完全ガイド
テストの基本原則、テスト技法、テストピラミッドの実践。
6. バグ管理完全ガイド
バグライフサイクル、トリアージ、優先度付け、レポート作成の実践的手法。
Checklists & Templates
7. 包括的QAチェックリスト
品質保証プロセス全体をカバーする実践的なチェックリスト集。
主な内容:
- テスト計画チェックリスト: プロジェクト理解、スコープ定義、戦略、リソース、スケジュール
- 機能テストチェックリスト: 認証、CRUD操作、決済処理
- 非機能テストチェックリスト: パフォーマンス、互換性、使用性
- セキュリティテストチェックリスト: 認証・認可、データ保護、脆弱性対策
- ユーザビリティテストチェックリスト: アクセシビリティ（WCAG 2.1 AA）、ヒューリスティック
- パフォーマンステストチェックリスト: Core Web Vitals、リソース最適化
- リグレッションテストチェックリスト: 範囲選定、実行前後確認
- リリース前/後チェックリスト: コード品質、テスト完了、バグ管理、モニタリング
8. テスト計画書テンプレート
プロフェッショナルなテスト計画書テンプレート。即座に使用可能。
主な内容:
- プロジェクト概要、テスト対象、テスト戦略
- リソース計画、スケジュール、品質基準
- リスク管理、品質メトリクス、成果物定義
- コミュニケーション計画、承認プロセス
Quick Start
対象読者
- QAエンジニア
- テストエンジニア
- プロダクトマネージャー
- 開発チーム全体
- プロジェクトマネージャー
このSkillでできること
- データドリブンな品質管理の実現
- 効果的なテスト計画の策定
- 安全なリリースプロセスの確立
- 品質メトリクスの定義と測定
- バグの効率的な管理
- リリース品質の客観的判定
QA戦略
品質の定義
品質の4つの柱:
-
機能品質
- 要件を満たしているか
- バグが少ないか
- 期待通りに動作するか
-
パフォーマンス品質
- 応答速度は十分か
- メモリ使用量は適切か
- バッテリー消費は許容範囲か
-
セキュリティ品質
- データは安全に保護されているか
- 脆弱性はないか
- 認証・認可は適切か
-
ユーザビリティ品質
- 使いやすいか
- 直感的か
- アクセシビリティに配慮されているか
QAプロセス
要件定義
↓
テスト計画策定
↓
テストケース作成
↓
テスト実行
↓
バグ報告・修正
↓
リグレッションテスト
↓
リリース判定
↓
リリース後モニタリング
↓
フィードバック収集
↓
継続的改善
テスト計画
テスト計画テンプレート
# テスト計画書
## 1. 概要
- プロジェクト名: [プロジェクト名]
- バージョン: [バージョン]
- 作成日: [日付]
- 作成者: [名前]
## 2. テスト対象
### 対象機能
- [機能A]
- [機能B]
- [機能C]
### 対象外
- [対象外の機能や理由]
## 3. テスト環境
### デバイス
- iPhone 14 Pro (iOS 17.0)
- iPhone SE (iOS 16.0)
- iPad Pro 12.9" (iPadOS 17.0)
### テストデータ
- [テストアカウント情報]
- [テストデータセット]
## 4. テストスコープ
### 機能テスト
- ユーザー登録・ログイン
- データ作成・編集・削除
- 同期機能
### 非機能テスト
- パフォーマンステスト
- セキュリティテスト
- ユーザビリティテスト
## 5. テストスケジュール
| フェーズ | 期間 | 担当者 |
|---------|------|--------|
| テストケース作成 | 1週間 | QAチーム |
| 機能テスト | 2週間 | QA + Dev |
| リグレッションテスト | 3日 | QAチーム |
| 最終確認 | 1日 | 全員 |
## 6. 品質基準
### リリース可能基準
- Criticalバグ: 0件
- Majorバグ: 5件以下
- テストケースPass率: 95%以上
### 品質メトリクス
- コードカバレッジ: 80%以上
- レスポンス時間: 2秒以下
- クラッシュ率: 0.1%以下
## 7. リスク管理
| リスク | 影響度 | 対策 |
|--------|--------|------|
| デバイス不足 | 中 | クラウドテストサービス利用 |
| テスト期間不足 | 高 | 優先順位付けと自動化 |
## 8. 成果物
- テスト結果レポート
- バグレポート一覧
- リリース判定書
テストケーステンプレート
# テストケース: TC-001
## 基本情報
- ID: TC-001
- 優先度: High
- カテゴリ: ログイン機能
- 作成日: 2025-12-24
## テストシナリオ
正しいメールアドレスとパスワードでログインできる
## 前提条件
- アプリがインストールされている
- 有効なユーザーアカウントが存在する
- ネットワーク接続がある
## テスト手順
1. アプリを起動
2. ログイン画面で有効なメールアドレスを入力
3. 正しいパスワードを入力
4. 「ログイン」ボタンをタップ
## 期待結果
- ホーム画面に遷移する
- ユーザー名が表示される
- エラーメッセージが表示されない
## 実測結果
- Pass / Fail
- 備考: [実際の動作、スクリーンショット等]
## テストデータ
- Email: test@example.com
- Password: TestPass123!
## 関連バグ
- [バグID、必要に応じて]
品質メトリクス
主要メトリクス
1. バグメトリクス:
struct BugMetrics {
let totalBugs: Int
let criticalBugs: Int
let majorBugs: Int
let minorBugs: Int
var bugDensity: Double {
// バグ密度 = バグ数 / KLOC（1000行あたり）
return Double(totalBugs) / (linesOfCode / 1000.0)
}
var criticalBugRatio: Double {
return Double(criticalBugs) / Double(totalBugs)
}
}
2. テストカバレッジ:
# Xcodeでのカバレッジ測定
xcodebuild test \
-scheme MyApp \
-enableCodeCoverage YES
# カバレッジレポート生成
xcrun xccov view --report DerivedData/Logs/Test/*.xcresult
3. 品質ダッシュボード:
## 品質ダッシュボード (Week 51)
### バグ統計
- 総バグ数: 23件
- Critical: 0件 ✅
- Major: 3件 ⚠️
- Minor: 20件
### バグ解決率
- 今週発見: 15件
- 今週修正: 18件
- 解決率: 120%
### テスト進捗
- テストケース総数: 500件
- 実行済み: 450件 (90%)
- Pass: 430件 (95.6%)
- Fail: 20件 (4.4%)
### コードカバレッジ
- 全体: 82% ✅
- Unit Tests: 85%
- UI Tests: 75%
### パフォーマンス
- 平均起動時間: 1.2秒 ✅
- APIレスポンス: 800ms ✅
- クラッシュ率: 0.08% ✅
バグ管理
バグレポートテンプレート
# バグレポート: BUG-123
## 基本情報
- ID: BUG-123
- タイトル: ログイン後に画面が真っ白になる
- 優先度: Critical
- 重要度: High
- ステータス: Open
- 発見者: [QA担当者]
- 発見日: 2025-12-24
- 担当者: [開発者]
## 環境
- デバイス: iPhone 14 Pro
- OS: iOS 17.2
- アプリバージョン: 1.2.0 (Build 45)
- ネットワーク: WiFi
## 再現手順
1. アプリを起動
2. メールアドレス "test@example.com" でログイン
3. パスワード "password123" を入力
4. ログインボタンをタップ
5. 画面が真っ白になる
## 期待動作
ホーム画面が表示される
## 実際の動作
画面が真っ白のまま何も表示されない
## 再現率
100% (10回中10回)
## 影響範囲
すべてのユーザーがログイン後に操作不可
## 添付
- スクリーンショット: bug-123-screenshot.png
- クラッシュログ: crash-log.txt
- ビデオ: bug-123-video.mp4
## 追加情報
- コンソールログに "Failed to load user data" エラーが表示される
- ネットワークタブでAPI呼び出しが401エラーを返している
## 関連チケット
- BUG-100 (類似の問題)
- FEATURE-50 (関連機能)
バグ優先度の定義
| 優先度 | 説明 | 対応時間 | 例 | |--------|------|----------|---| | Critical | アプリが使用不可 | 即時 | クラッシュ、データ損失 | | Major | 主要機能が動作しない | 24時間以内 | ログインできない、決済失敗 | | Minor | 副次的な機能の問題 | 次回リリース | UI崩れ、文言の誤り | | Trivial | 軽微な問題 | バックログ | タイポ、配色の改善 |
バグトリアージ
struct BugTriageSystem {
enum Priority {
case critical
case major
case minor
case trivial
}
enum Severity {
case blocker // リリース不可
case high // 主要機能に影響
case medium // 副次的な影響
case low // 軽微な影響
}
struct Bug {
let id: String
let title: String
var priority: Priority
var severity: Severity
var status: Status
var assignee: String?
enum Status {
case open
case inProgress
case readyForTest
case closed
case wontFix
}
}
func triageBug(_ bug: Bug) -> Priority {
switch (bug.severity, impactedUsers(bug)) {
case (.blocker, _):
return .critical
case (.high, .all):
return .critical
case (.high, .many):
return .major
case (.medium, .all):
return .major
case (.medium, .many):
return .minor
default:
return .trivial
}
}
enum ImpactedUsers {
case all // 全ユーザー
case many // 多数のユーザー
case few // 少数のユーザー
case specific // 特定条件下のみ
}
func impactedUsers(_ bug: Bug) -> ImpactedUsers {
// ロジックは省略
.all
}
}
探索的テスト
セッションベーステスト
# 探索的テストセッション
## セッション情報
- テスター: [名前]
- 日時: 2025-12-24 14:00-15:00
- チャーター: 新規ユーザー登録フローの探索
## テスト範囲
- ユーザー登録画面
- メール認証フロー
- プロフィール設定
## テストアプローチ
- 正常系フローの確認
- エッジケースの探索
- エラーハンドリングの確認
- ユーザビリティの評価
## 発見事項
### バグ
1. [BUG-124] メールアドレスに特殊文字を含むと登録失敗
- 重要度: Medium
- 再現率: 100%
2. [BUG-125] パスワード強度チェックが機能していない
- 重要度: High
- セキュリティリスクあり
### 改善提案
1. パスワード強度のビジュアルインジケーターが欲しい
2. 登録完了後の次のステップが分かりにくい
### 質問・懸念
1. プライバシーポリシーへのリンクが見つからない
2. メール認証の有効期限が不明
## 時間配分
- セットアップ: 5分
- テスト実行: 45分
- バグ報告: 10分
## 次回のチャーター
プロフィール編集機能の探索
エクスプローラトリーテスト技法
1. ツアー法:
- ガイドツアー: 主要フローに沿って探索
- 悪党ツアー: 異常入力、不正操作を試す
- サポータツアー: ヘルプ、設定等のサポート機能を探索
2. ペルソナベース:
## ペルソナ: 高齢者ユーザー
### 特性
- 年齢: 65歳
- ITリテラシー: 低
- 視力: 弱い
- 期待: シンプルで分かりやすい操作
### テスト観点
- 文字サイズは十分か
- ボタンは押しやすいか
- エラーメッセージは分かりやすいか
- ヘルプは充実しているか
ユーザビリティテスト
ユーザビリティテスト計画
## ユーザビリティテスト
### 目的
新規ユーザーが初回使用時にスムーズにタスクを完了できるか検証
### 参加者
- 人数: 5名
- 条件: アプリ未使用、18-60歳、スマートフォン所有
### タスク
1. アプリをダウンロードしてアカウント作成
2. プロフィールを設定
3. 商品を検索して購入
4. レビューを投稿
### 測定指標
- タスク成功率
- タスク完了時間
- エラー回数
- 満足度スコア (1-5)
### 観察ポイント
- つまづいた箇所
- 迷った箇所
- 発話内容
- 表情・仕草
### 結果テンプレート
| タスク | 成功 | 時間 | エラー数 | 満足度 | コメント |
|--------|------|------|----------|--------|----------|
| タスク1 | ✅ | 2:30 | 1 | 4 | メール確認が分かりにくい |
| タスク2 | ✅ | 1:45 | 0 | 5 | スムーズ |
| タスク3 | ❌ | - | 3 | 2 | 検索結果が見つからない |
| タスク4 | ✅ | 3:00 | 2 | 3 | レビュー画面が分かりにくい |
SUS（System Usability Scale）
## SUS質問票
1-5のスケールで評価（1=全く同意しない、5=非常に同意する）
1. このシステムを頻繁に使いたいと思う
2. このシステムは不必要に複雑だと思う
3. このシステムは使いやすいと思う
4. このシステムを使うにはサポートが必要だと思う
5. このシステムの機能はうまく統合されていると思う
6. このシステムには一貫性がないと思う
7. ほとんどの人はこのシステムを素早く学習できると思う
8. このシステムは非常に扱いにくいと思う
9. このシステムを使うことに自信を持っている
10. このシステムを使う前に多くのことを学ぶ必要があると思う
### スコア計算
- 奇数項目: (スコア - 1)
- 偶数項目: (5 - スコア)
- 合計 × 2.5 = SUSスコア (0-100)
### 評価基準
- 80-100: 優秀
- 68-79: 良好
- 68未満: 改善必要
パフォーマンステスト
パフォーマンス計測
import XCTest
class PerformanceTests: XCTestCase {
func testAppLaunchTime() {
measure(metrics: [XCTApplicationLaunchMetric()]) {
XCUIApplication().launch()
}
// 基準: 2秒以内
}
func testScrollPerformance() {
let app = XCUIApplication()
app.launch()
let table = app.tables.firstMatch
measure(metrics: [XCTOSSignpostMetric.scrollDecelerationMetric]) {
table.swipeUp(velocity: .fast)
}
// 基準: スムーズにスクロール（60fps維持）
}
func testAPIResponseTime() {
measure {
let expectation = self.expectation(description: "API")
fetchUserData { result in
expectation.fulfill()
}
waitForExpectations(timeout: 5.0)
}
// 基準: 1秒以内
}
}
負荷テスト
## 負荷テストシナリオ
### テスト1: 同時接続数
- シナリオ: 1000ユーザーが同時にログイン
- 期待値: すべてのリクエストが5秒以内に完了
- ツール: Apache JMeter
### テスト2: データ量
- シナリオ: 10,000件のアイテムをリスト表示
- 期待値: スクロールがスムーズ、メモリリークなし
- 測定: Instruments (Allocations, Leaks)
### テスト3: 長時間使用
- シナリオ: 8時間連続使用
- 期待値: メモリ使用量が安定、クラッシュなし
- 測定: Instruments (Time Profiler)
リリース判定
リリース判定基準
## リリース判定書
### プロジェクト情報
- バージョン: 1.5.0
- ビルド番号: 150
- リリース予定日: 2025-12-31
- 判定日: 2025-12-24
### 品質基準
#### 必須条件（Must）
- [ ] Criticalバグ: 0件 ✅
- [ ] Majorバグ: 5件以下 → 現在3件 ✅
- [ ] テストケースPass率: 95%以上 → 現在96.5% ✅
- [ ] コードカバレッジ: 80%以上 → 現在82% ✅
- [ ] クラッシュ率: 0.1%以下 → 現在0.08% ✅
#### 推奨条件（Should）
- [ ] パフォーマンステスト完了 ✅
- [ ] セキュリティスキャン実施 ✅
- [ ] ユーザビリティテスト実施 ✅
- [ ] アクセシビリティチェック完了 ⚠️ (一部未対応)
#### 任意条件（Nice to Have）
- [ ] 探索的テスト実施 ✅
- [ ] Beta版フィードバック反映 ✅
### 既知の問題
1. [BUG-200] iPad横画面で一部UIが崩れる (Minor)
- 影響範囲: iPad Pro 12.9"のみ
- 対応予定: 次回リリース
### リスク評価
- リリースリスク: 低
- 理由: すべての必須条件をクリア、既知の問題は軽微
### 判定結果
✅ **リリース可**
承認者: [名前]
日付: 2025-12-24
リリース後チェックリスト
## リリース後チェックリスト
### 即日
- [ ] App Storeでの公開を確認
- [ ] クラッシュレポートをモニタリング
- [ ] ユーザーレビューをチェック
- [ ] 主要メトリクスをダッシュボードで確認
### 1週間以内
- [ ] クラッシュ率が基準内か確認
- [ ] パフォーマンスメトリクスを分析
- [ ] ユーザーフィードバックをトリアージ
- [ ] 緊急性の高いバグに対応
### 1ヶ月以内
- [ ] リリース振り返りミーティング実施
- [ ] KPI達成状況を確認
- [ ] 次回リリースの計画策定
継続的改善
レトロスペクティブ
## Sprint Retrospective
### 良かったこと (Keep)
- 自動テストのカバレッジが向上した
- バグ修正の速度が上がった
- QAと開発の連携がスムーズだった
### 改善すべきこと (Problem)
- テストケースの整理が追いつかない
- 探索的テストの時間が不足
- パフォーマンステストが後回しになった
### 試すこと (Try)
- テストケースレビュー会を週1で実施
- 探索的テストを毎日30分確保
- パフォーマンステストを自動化
品質改善アクション
## 品質改善アクションプラン
### 目標
クラッシュ率を0.08% → 0.05%に削減
### アクション
1. クラッシュレポートの自動収集・分析
- 担当: 開発チーム
- 期限: 1週間
2. Top 10クラッシュの修正
- 担当: 各担当者
- 期限: 2週間
3. クラッシュ防止のためのコードレビュー強化
- 担当: 全員
- 継続的に実施
### KPI
- クラッシュ率: 週次でトラッキング
- クラッシュフリーユーザー率: 99.95%以上
関連Skills:
- testing-strategy - テスト戦略
- code-review - コードレビュー
- ci-cd-automation - CI/CD自動化
- incident-logger - インシデント管理
更新履歴:
- 2025-12-24: 初版作成