qa-methodology について
QA と SDET 向けのテスト手法スキルで、テスト戦略、自動化、回帰テスト、リスク優先順位、品質ゲート、エージェント評価を扱います。リファレンス、テンプレート、リスク順位付けや受け入れ基準のテスト可能性を確認するスクリプトを含みます。
主な機能
- 01テスト戦略とリスク優先度の設計
- 02自動化と回帰テストの計画
- 03品質ゲートと指標の定義
- 04エージェント評価の設計
- 05テンプレート・資料・スクリプト
活用シーン
- 01プロジェクトや機能のテスト範囲を計画
- 02リスクの優先順位付けと CI 障害の分類
- 03品質ゲートと受け入れ基準のレビュー
- 04エージェント評価用データセットの設計
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ magnus919/ agent-skills --skill qa-methodologyインストール後、Claude Code で/qa-methodologyを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
pytest.iniREADME.mdassets/qa-definition-of-done.mdrisk-matrix-grid.mdtest-design-techniques-checklist.mdevals/evals.jsonfactory-assurance-challenges.mdreferences/agent-ui-navigation.mdagentic-eval-design.mdai-code-quality-gates.mdai-test-artifact-evidence.mdci-failure-triage.mdexploratory-testing.mdholdout-scenarios.mdperformance-testing.mdqa-career-levels.mdquality-gates-and-metrics.mdregression-testing.mdrisk-based-testing.mdsdet-engineering.mdsecurity-testing.mdtest-automation.mdtest-data-management.mdtest-debugging.mdtest-design-techniques.mdtest-strategy.mdscripts/check-ac-testability.pyrisk-prioritize.pytemplates/agent-ui-run-record.mdai-assisted-verification-note.md詳細
QA の方法論
シニアからプリンシパルレベルの QA および SDET の方法論:テスト戦略、自動化、回帰テスト、リスクベースの優先順位付け、探索的テスト、品質ゲート、エージェント型の仕様駆動開発における AI コード品質ゲート、エージェント型評価の設計、キャリアレベル、SDET エンジニアリング。
担当範囲
| 担当すること | 担当しないこと |
|---|---|
| テスト戦略 — 何を、どのレベルで、どの優先度でテストするか | 根本原因のデバッグ — systematic-debugging に引き継ぎます |
| テスト自動化 — フレームワークの選定、並列化、不安定なテストの管理 | セキュリティの実装と脅威モデリング — secure-software-engineering に引き継ぎます |
| E2E 自動化戦略とカバレッジの判断 | ブラウザテストツール(Playwright)の操作 — 仕様の作成・実行、セレクター、ネットワークのモック化、スクレイピング — playwright に引き継ぎます |
| 回帰テストスイート — 選定、影響分析、スイートの改善 | 仕様パイプラインの仕組みとゲートの判定 — spec-driven-development に引き継ぎます |
| 品質ゲート — ブロッキングか助言的かの判断、メトリクス、DORA | 評価フレームワークのガバナンスと統計 — agent-evals-and-observability に引き継ぎます |
| リスクベースのテスト — P×I スコアリング、優先順位付け、登録簿 | 明示的な基準に基づく検証判定 — verification-methodology に引き継ぎます |
| 探索的テスト — SBTM チャーター、ヒューリスティクス、ツアー | 機能の実装 — これは開発者の担当です |
| AI コード品質ゲート — 独立した検証、AC のテスト可能性 | 本番環境のモニタリングとインシデント対応 — これは SRE の担当です |
| ミューテーションに基づくテスト強化 — 範囲を限定したミューテーションレビューの証拠と、生き残ったミューテーションのトリアージ | 明示的な基準に基づく検証判定 — verification-methodology に引き継ぎます |
| エージェント型評価の設計 — データセット設計、評価者バイアス、不安定な評価への対策 | |
| QA のキャリアレベル — シニア/スタッフ/プリンシパルの職務範囲の段階的な拡大 | |
| SDET エンジニアリング — テストインフラストラクチャ、gTAA、CI/CD 統合 |
基本原則
テストされていなければ、壊れています。 テストされていないコードとは、まだ障害モードが発見されていないコードです。
品質は成果物ではなく、プロセスの特性です。 最後にテストしても品質は生まれません。サイクル全体を通じた戦略、自動化、ゲート設定によって品質を設計に組み込みます。
実装ではなく、振る舞いをテストします。 振る舞いに結び付いたテストはリファクタリング後も機能しますが、実装に結び付いたテストはリファクタリングで壊れます。
優先度はリスクに基づいて決めます。 すべてに同じだけテスト投資を行う必要はありません。発生確率 × 影響度をスコア化し、それに応じて割り当てます。
不安定なテストは、テストがないよりも悪いものです。 非決定的な失敗は、チームにすべての失敗を無視する習慣を身に付けさせます。検出したら隔離し、再実行は一度だけにします。二度は実行しません。
開発時のテストと受け入れ認定を分けます。 実装者はテストを実行し、自分の作業をデバッグする必要があります。独立した受け入れレビューでは、別の評価者と観測可能な証拠を用います。新しいセッションにすればコンテキストの共有は減りますが、共有された先入観や相関するエラーがなくなるわけではありません。
読み込みガイド
| ファイル | 読み込むタイミング |
|---|---|
references/test-strategy.md | テスト戦略を設計するとき — ピラミッド構造、シフトレフト/ライト、障害発生時のコスト、診断指標としてのカバレッジ |
references/test-automation.md | フレームワークの選定、並列実行/シャーディング、不安定なテストの隔離、予測型 ML テスト選択、ミューテーションに基づく強化 |
references/quality-gates-and-metrics.md | 品質ゲート(ブロッキングとアドバイザリー)、DORA メトリクス、見栄え重視と実用的なメトリクスの違い、ミューテーションテストを設計するとき |
references/regression-testing.md | リグレッションスイートの構築 — 影響分析、選択の計算、スイートの進化、シフトライトのフィードバック |
references/test-data-management.md | テストデータ戦略 — フィクスチャー、ファクトリー、タイムトラベル、マスキング、GDPR/PII のルール |
references/performance-testing.md | 負荷/ストレス/ソークテスト — k6/Locust/Gatling/JMeter、SLO のしきい値、CI の実行頻度 |
references/security-testing.md | セキュリティテスト — OWASP Top 10:2025、STRIDE、SAST/DAST/SCA、サプライチェーン/SBOM |
references/ci-failure-triage.md | CI が赤くなったとき — 終了コードの分類(1/2/126/127/137/139/143)、git bisect、不安定なテストと失敗を区別する手順 |
references/test-debugging.md | 成功するはずのテストが失敗するとき — CI とローカル環境の差異、実行順序/共有状態、モックのバインド |
references/risk-based-testing.md | リスクに基づく優先順位付け — P×I の計算式、5×5 マトリックス、リスクワークショップ、リスク登録簿、再評価のきっかけ |
references/exploratory-testing.md | 探索的テスト — SBTM、チャーターの作成、SFDIPOT/HICCUPPS ヒューリスティック、ツアー |
references/test-design-techniques.md | テスト設計技法の選択 — EP、BVA、デシジョンテーブル、状態遷移、ペアワイズ、エラー推測 |
references/qa-career-levels.md | QA のキャリア形成 — Senior/Staff/Principal の職務範囲、レベル設定の仕組み、アーキタイプ、よくある誤解 |
references/sdet-engineering.md | SDET の役割とスキル — gTAA/TAF アーキテクチャ、POM、テストにおける SOLID、内製と購入の判断、テスト容易性 |
references/holdout-scenarios.md | 保留する受け入れケース、アクセス境界、修正フィードバック、汚染の記録を設計するとき |
templates/holdout-record.md | 固定したケース、露出履歴、候補に紐づく結果を記録するとき |
references/ai-code-quality-gates.md | AI 生成コードのレビュー — 独立した検証、AC のテスト容易性、エージェントによるテストの品質、ヒューマン・イン・ザ・ループ |
references/ai-test-artifact-evidence.md | AI 支援 QA における来歴、仕様優先のオラクルレビュー、生成物レビューのトリアージ、ワークフローの証拠、緊急時の例外 |
references/agent-ui-navigation.md | エージェントのナビゲーション/リプレイ戦略、独立したオラクル、範囲を限定した修正、完全なカバレッジ |
templates/agent-ui-run-record.md | ナビゲーション、リプレイ、独立したチェック、不足している証拠を記録するとき |
references/agentic-eval-design.md | エージェント評価の設計 — データセットのテスト設計、ジャッジのバイアス、不安定な評価への対処、CI ゲートの段階、リプレイ |
templates/test-strategy.md | テスト戦略ドキュメントの作成 — 対象範囲、リスク層、レベル配分、自動化の目標を記入するとき |
templates/risk-register.md | リスク評価の結果を記録 — 項目、P×I スコア、担当者、軽減策を記入するとき |
templates/exploratory-charter.md | SBTM チャーターの作成 — 対象、リソース、発見目標、タイムボックスを記入するとき |
templates/bug-report.md | 構造化されたバグレポートの提出 — 再現手順、期待値と実際の結果、重大度を記入するとき |
templates/verification-plan.md | 独立した検証の計画 — AC と手法のトレーサビリティ、検証担当者の割り当て、終了基準を記入するとき |
templates/mutation-review.md | 範囲を限定したミューテーションレビューの対象範囲、分類、生き残ったテスト、独立した証拠を記録するとき |
templates/ai-assisted-verification-note.md | AI 支援によるテスト/レビューの来歴、独立したオラクルチェック、証拠の扱いを記録するとき |
assets/risk-matrix-grid.md | ワークショップでのリスク評価 — ゾーンのしきい値を含む 5×5 の P×I グリッド |
assets/test-design-techniques-checklist.md | 機能に適用する技法の選択 — シナリオタイプと技法を対応付けたクイックリファレンスチェックリスト |
assets/qa-definition-of-done.md | リリース準備状況の定義 — 完了の定義における QA の貢献 |
scripts/risk-prioritize.py | リスク項目の JSON ファイルから P×I の順位を計算するとき |
scripts/check-ac-testability.py | 受け入れ基準に曖昧な動詞や、観測可能な結果の欠落がないか確認するとき |
evals/evals.json | このスキルの出力品質評価を実行するとき(スキーマ v1、23 ケース) |
エージェント駆動の UI ナビゲーション
ライブナビゲーション、リプレイ、またはロケーターの修復を行う場合は、references/agent-ui-navigation.md
を読み、templates/agent-ui-run-record.md に記入してください。実行前に、独立した厳密なオラクルと
必須のケース ID を確定してください。ナビゲーターにアサーションを弱めさせたり、
必須のカバレッジを省略させたりしてはいけません。すべての経路で、永続性、アカウント ID、
作用回数を再確認してください。任意の範囲内のテキスト判断には System One を再利用してください。操作はツールスキルが担い、
証拠の判定は verification-methodology が担います。
スクリプト
| スクリプト | 実行方法 | 目的 |
|---|---|---|
| risk-prioritize | python3 scripts/risk-prioritize.py --json <input.json> | リスク項目(確率、影響度)を読み込み、P×I スコアを計算し、順位付けした JSON を出力します |
| check-ac-testability | python3 scripts/check-ac-testability.py <spec.md> | 受け入れ基準にテスト不可能な表現がないかスキャンし、該当項目がある場合はゼロ以外の終了コードを返します |
トリガー
次のタスクに関わる場合、このスキルを読み込んでください。
- テスト戦略 — プロジェクトや機能に対して、何をどのように、どの優先度でテストするかを設計する
- 回帰テスト — 回帰テストスイートを構築、選定、または改善する
- CI トリアージ — CI 失敗、終了コード、フレークと実際の失敗の分類を診断する
- テスト自動化 — フレームワークの選定、並列処理、フレークの隔離、ML による選定を行う
- 品質ゲート — ゲートの設計、ブロッキングと助言の使い分け、メトリクス、DORA を扱う
- ミューテーションを活用したテスト強化 — 差分を考慮したミューテーション範囲、生存したミュータント、弱いアサーション、レビュー証拠を扱う
- リスクベーステスト — P×I スコアリング、リスク登録簿、優先順位付けのワークショップを行う
- 探索的テスト — SBTM チャーター、オラクルのヒューリスティック、セッションの振り返りを扱う
- エージェント評価 — 評価データセットの設計、ジャッジのバイアス、フレーク評価の規律、CI の階層を扱う
- SDD ゲートレビュー — 仕様駆動型ゲートにおける QA の責任、受け入れ基準のテスト可能性、独立検証を扱う
- SDET — テストインフラエンジニアリング、gTAA、CI/CD 統合、キャリアの範囲を扱う
使用しない場合
代わりに、該当する名前付きの兄弟スキルに振り分けてください。
- spec-driven-development — 仕様書の作成、SDD パイプラインの実行、ゲート判定形式、改訂ループ
- agent-evals-and-observability — 評価フレームワークのガバナンス、統計的比較、テレメトリーとプライバシー管理、採点器の実装
- verification-methodology — 明示された合否基準に照らして証拠を収集し、判定を示す
- release-engineering — テスト証拠をリリース候補の準備状況、昇格、実施可否の判断、本番ロールアウト、ロールバックの判断にまとめる。QA はテスト戦略とゲートの意味付けを担います
- systematic-debugging — 本番インシデントの根本原因分析、バグの再現、故障箇所の特定
- secure-software-engineering — セキュリティ実装、脅威モデリング、安全なデフォルト設定、依存関係の評価
- playwright — Playwright ツール自体の操作:E2E 仕様の作成と実行、セレクターの堅牢性、ネットワークのモック化、ヘッドレススクレイピング、画面表示ありのデバッグ
停止条件と終了条件
- テスト戦略の完了条件: 戦略文書に、リスク階層、テストレベルの配分、自動化の対象、各階層の終了基準が記載されていること。
- リスク評価の完了条件: 特定されたすべてのリスクについて、P×I スコア、担当者、緩和策または受容の判断が登録簿に記録されていること。
- CI トリアージの完了条件: 失敗が分類され(フレークか実際の失敗か、環境かコードか)、根本原因が特定され、修正またはエスカレーションの経路が明確になっていること。
- ゲートレビューの完了条件: すべての受け入れ基準に検証方法が対応付けられ、検証者が実装者から独立しており、証拠が添付されていること。
- エスカレーションの上限: 診断が収束しない場合は 3 回の確認で停止し、それまでに収集した証拠を報告してください。