qa-manual-istqb

QA テスト設計と ISTQB 成果物

以下の各工程を網羅する、ISTQB Foundation Level（CTFL）に準拠した QA テストエンジニア向けワークフローです。 テスト計画 → テスト分析 → テスト設計 → テスト実装 → テスト実行 → テスト完了

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

• 要件、ユーザーストーリー、または受け入れ基準に基づき、すぐに記入できる QA 成果物を作成する
• テスト計画およびテスト戦略を作成またはレビューする
• 要件からテスト条件およびテストケースを生成する
• テスト設計技法（同値分割、境界値分析、決定表、状態遷移、ユースケース）を適用する
• バグレポートを作成し、欠陥ライフサイクルを管理する
• リスクベースの選定により回帰テストスイートを構築する
• トレーサビリティマトリクス（要件 ↔ テスト ↔ 欠陥）を作成する
• チャーターを使って探索的テストセッションを実施する
• ISTQB の技法を使ってテスト工数を見積もる
• 静的テストの手法を使ってテストウェアをレビューする
• 自動化候補を選定し、トレーサビリティを備えた Playwright のスキャフォールドを準備する

使用しない場面

• バージョン管理された Playwright の仕様コードを作成・保守する場合（playwright-e2e-testing を使用してください）。
• Selenium／Java のテストを作成する場合（webapp-selenium-testing を使用してください）。
• ライブブラウザーを操作してデバッグする場合（playwright-cli を使用してください）、または既存の回帰テストスイートの CI を管理する場合（playwright-regression-testing を使用してください）。
• 対抗的な戦略批評を行う場合。これは grill-me-qa スキルの目的です。このスキルは成果物を作成するものであり、成果物を問いただすものではありません。

前提条件

要件	備考
Node.js 18+	CLI スクリプトと Playwright に必要です
Playwright	自動化には npm init playwright@latest を使用します
テキストエディター	Markdown および CSV 成果物の作成・編集に使用します
Git	テストウェアのバージョン管理に推奨されます

クイックスタート（いずれかを選択）

• テスト計画を作成する：出発点として templates/test-plan.md を使用します。
• テストサマリーレポートを作成する：templates/test-summary-report.md を使用します。
• テストケースを生成する：templates/test-cases.csv を使用し、テストベース（要件、ユーザーストーリー、受け入れ基準）に基づいて記入します。
• バグレポートを作成する：templates/bug-report.md を使用します。
• バグログを作成する：templates/bug-log.csv を使用します。
• トレーサビリティを作成する：templates/traceability-matrix.csv を使用します。
• 回帰テストスイートの定義を作成する：templates/regression-suite.md を使用します。
• Playwright テストのスキャフォールドを作成する：templates/playwright-spec.ts を使用し、テスト対象システムに合わせて調整します。
• 探索的テストを実施する：templates/exploratory-charter.md を使用して時間枠を設定し、結果を記録します。

ローカルで実行する場合は、同梱の CLI を使って成果物を生成します。

node scripts/qa_artifacts.mjs list
node scripts/qa_artifacts.mjs create test-plan --out specs --project "My App" --release "R1"
node scripts/qa_artifacts.mjs create test-cases --out specs --feature "Checkout"
node scripts/qa_artifacts.mjs create bug-report --out specs/bugs --title "Search returns 500"

収集する入力（不足している場合は確認してください）

• テストベース：要件、ユーザーストーリー、受け入れ基準、設計、リスク登録簿、欠陥履歴。
• スコープ：対象／対象外の機能、対象プラットフォーム／ブラウザー／デバイス、ロケール、アクセシビリティ、連携。
• 品質リスク：発生し得る障害、影響、発生可能性、規制／コンプライアンス、重要なユーザージャーニー。
• 制約：期限、環境、データの可用性、ツール、アクセス／ロール、CI/CD に関する期待事項。
• 定義：重要度と優先度の尺度、対象とするテストレベルとテストタイプ、開始／終了基準。

ワークフロー

1) テスト計画（および／またはテスト戦略）を作成する

1. テストベースから、テスト目標、スコープ、前提条件、制約を特定します。
2. テストレベルとテストタイプを定義します（該当する場合、機能テスト、変更関連テスト、主要な非機能テストを含みます）。
3. 各領域に適したテスト設計技法を選択します（references/test-design-techniques.md を参照）。
4. 環境、テストデータ、ツール、構成管理のニーズを明記します。
5. 開始／終了基準、成果物、報告の頻度／指標を定義します。
6. リスクマトリクスと軽減策を追加し、それに応じてテストに優先順位を付けます（リスクベーステスト）。

使用するファイル：templates/test-plan.md（詳細なセクションとチェックリスト）。

2）テスト条件とテストケースを作成する

1. 手順ごとのテストケースを書く前に、テストベースをテスト条件（何をテストするか）に変換します。
2. 各条件にテスト技法を選びます。
   • 入力やバリデーションには、同値分割と境界値分析を使用します。
   • ルールの組み合わせには、デシジョンテーブルを使用します。
   • ライフサイクルやフローには、状態遷移テストを使用します。
   • エンドツーエンドのユーザージャーニーには、ユースケース／シナリオテストを使用します。
   • 迅速に把握するには、探索的テストセッションを実施します（templates/exploratory-charter.md を参照）。
3. 個別に実行でき、曖昧さがなく、要件／ユーザーストーリー ID まで追跡可能なテストケースを作成します。
4. 観察および測定可能な期待結果を追加します（テストオラクルを定義します）。
5. リスクベースの回帰テスト選定に役立つよう、優先度タグとリスクタグを追加します。
6. 安定性と価値の基準を用いて、自動化候補をマークします（references/automation-playwright-best-practices.md を参照）。

使用するファイル：templates/test-cases.csv。

3）自動化候補と Playwright のひな形を準備する

1. 安定性、価値、リスクの基準を用いて候補を選定します（references/automation-playwright-best-practices.md を参照）。
2. templates/playwright-spec.ts から、テストケース ID とスイートタグを含む追跡可能なひな形を作成します。
3. playwright-e2e-testing を使用して、バージョン管理された UI 仕様、フィクスチャ、テストインフラストラクチャを実装し、保守します。

4）回帰テストスイートを構築し、保守する

1. スイートの階層を定義します（例）：スモークテスト（重要なパス）、サニティテスト（ビルド検証）、回帰テスト（広範囲）、フルテスト（リリース）。
2. リスク、実行頻度、重要度、欠陥履歴に基づいてテストを選定します（カバレッジだけに基づいて選定しないでください）。
3. テストに一貫したタグを付け、選定ルールと担当者を文書化します。
4. スイートを定期的に見直し、不要になったカバレッジを削除し、流出した欠陥や高リスクな変更に対するカバレッジを追加します。

使用するファイル：templates/regression-suite.md と references/regression-suite-strategy.md。

5）バグレポートを作成し、バグを効果的に文書化する

1. 確実に再現できるようにし、手順を最小限にまとめ、発生頻度のばらつきと影響範囲を記録します。
2. 環境の詳細（ビルド／アプリのバージョン、OS、ブラウザー／デバイス、アカウント／ロール、データ条件）を記録します。
3. 期待される動作と実際の動作を説明し、影響を記載して、深刻度と優先度を一貫して設定します。
4. 証拠（スクリーンショット、コンソールログ、ネットワークトレース、Playwright トレース）を添付し、関連するテスト／要件にリンクします。
5. ライフサイクルを追跡します：トリアージメモ、担当者、修正バージョン、検証手順と結果、クローズ基準。

使用するファイル：templates/bug-report.md と references/bug-report-quality.md。

6）静的テスト（レビュー）を実施する

1. レビューを早期に計画します（シフトレフト）：要件、設計、テスト計画、テストケースを対象にします。
2. 一貫性を保つためにチェックリストを使用します（references/static-testing.md を参照）。
3. 発見事項を、深刻度と対応の実行可能性を含めて文書化します。
4. 静的テストで見つかった欠陥は、個別に追跡します（予防と検出を区別します）。

レビュー用チェックリストと技法については、references/static-testing.md を使用します。

7）テスト工数を見積もる

1. 要因を特定します：スコープ、複雑さ、リスク、チームの経験、ツールの成熟度。
2. 見積もり技法を適用します（references/test-estimation.md を参照）。
   • 専門家の判断／過去のデータ
   • テストポイント分析
   • 作業分解構成図
3. リスクや不確実な要素に備えて、予備工数を追加します。
4. プロジェクトの進行に合わせて見積もりを見直し、精緻化します。

技法と計算式については、references/test-estimation.md を使用します。

8）テストの進捗とメトリクスを監視する

1. 実行メトリクスを追跡します：計画済み、実行済み、合格、不合格、ブロック中。
2. 欠陥メトリクスを監視します：発見済み、修正済み、未解決を、深刻度／優先度別に確認します。
3. テストカバレッジを算出します：カバー済みの要件、テスト済みのリスク領域。
4. ステータスを定期的に報告し、ブロッカーは早期にエスカレーションします。

メトリクスの定義とダッシュボードについては、references/test-monitoring-metrics.md を使用します。

品質ゲート（セルフチェック）

• テスト計画には、範囲、アプローチ、リスク、環境、開始／終了基準、成果物、メトリクスが含まれています。
• テストケースは追跡可能で、原子的かつ決定的であり、明確なオラクルとデータを含んでいます。
• 自動化は保守しやすくなっています（安定したロケーター、最小限の不安定さ、独立したテスト、明確なアサーション）。
• リグレッションはリスクベースで、タグ付けされ、明確な追加／削除ルールに基づいて整理されています。
• バグ報告は再現可能で、対応につながる内容であり、証拠、環境、影響が含まれています。
• 静的テストのレビューは文書化され、指摘事項が解決まで追跡されています。
• 見積もりには予備時間が含まれ、範囲が明確になるにつれて精緻化されています。

トラブルシューティング

問題	原因	解決策
テストケースに追跡可能性がない	要件 ID が不足している	requirement_id 列を追加し、ユーザーストーリー／AC にリンクする
バグ報告が却下される	再現手順が不十分	最小限の手順を使い、正確なデータと環境を含める
リグレッションスイートが遅すぎる	テストが多すぎ、優先順位付けがない	リスクベースの選定を適用し、スモーク／サニティ／フルに階層化する
自動テストが不安定	ロケーターまたはタイミングが不安定	data-testid を使い、スリープを避け、Playwright の自動待機を使う
テストの見積もりが不正確	スコープの拡大、リスクの見落とし	予備時間を追加し、スコープが変わったら再見積もりする
レビューで不具合が見つからない	表面的なレビュー	チェックリストを使い、十分な時間を確保し、レビュー担当者を交代する
テストオラクルが不明確	期待結果が不足している	要件、ルール、または参照システムからオラクルを定義する

同梱リソース

テンプレート（templates/）

テンプレート	用途
test-plan.md	ISTQB に準拠したテスト計画の構成
test-summary-report.md	サイクル終了時の概要と承認
test-cases.csv	追跡可能性を備えたテストケースリポジトリ
test-conditions.md	テストベースから導出したテスト条件
traceability-matrix.csv	要件 ↔ テスト ↔ 不具合の対応付け
bug-report.md	詳細な不具合報告
bug-log.csv	不具合追跡ログ
regression-suite.md	スイートの定義と選定ルール
exploratory-charter.md	セッションベースの探索的テスト
playwright-spec.ts	Playwright テストのひな形
test-environment-checklist.md	環境の準備状況の確認
risk-assessment-matrix.md	品質リスクの特定と優先順位付け

References (references/)

Reference	Content
test-design-techniques.md	EP、BVA、デシジョンテーブル、状態遷移、ユースケース
experience-based-techniques.md	エラー推測、チェックリストベース、探索的テスト
static-testing.md	レビュー、ウォークスルー、インスペクション
test-levels-types.md	単体、統合、システム、受け入れ；機能、非機能
test-estimation.md	見積もり手法と要因
test-monitoring-metrics.md	進捗管理と品質メトリクス
risk-based-testing.md	リスクの特定、分析、軽減
istqb-glossary.md	ISTQB の主要用語
test-process-and-deliverables.md	テストプロセスのフェーズと成果物
automation-playwright-best-practices.md	Playwright の実装ガイダンス
regression-suite-strategy.md	テストスイートの管理と最適化
bug-report-quality.md	効果的な不具合報告
defect-lifecycle.md	不具合の状態とワークフロー

Scripts (scripts/)

Script	Purpose
qa_artifacts.mjs	テンプレートから QA 成果物を生成する CLI ツール

---

注意すべき兆候

• 要件やリスクに紐付いていないテストケースを作成すること。追跡できないカバレッジは見せかけにすぎません。
• 再現手順、期待結果と実際の結果、または環境情報が欠けたバグ報告は、開発者にとって役に立ちません。
• リスクや変更の分析ではなく、勘に頼って回帰テストスイートを選ぶこと。労力が無駄になり、回帰の見落としにもつながります。
• 開始基準・終了基準や工数見積もりがないテスト計画では、実行を管理できません。
• この成果物作成スキルを戦略批評と混同しないでください（敵対的レビューには grill-me-qa を使用してください）。

---

検証

• テストケースが ISTQB の構成に従っている — 各ケースに ID、説明、前提条件、手順、期待結果がある（実際の結果は実行後に記入）
• カバレッジマトリクスが維持されている — 要件がテストケースに対応付けられ、未カバーの要件がない
• トレーサビリティが維持されている — 各テストケースが要件またはユーザーストーリーに紐付いている