mcpField
Q
qa-test-plan

qa-test-plan

github.com/carlitoseテスト・品質053 回インストール2 週間前に更新
リポジトリ

qa-test-plan について

qa-test-planは、検証ワークフローでQAテスト計画を作成するスキルです。変更の因果経路に沿って確認項目を選び、証拠や制約、未解決のゲートを記録します。テスト実行やリリース判定は行いません。

主な機能

  1. 01変更の因果関係に沿った確認項目の選定
  2. 02静的・単体・統合テストの分類
  3. 03手順と期待結果の記録
  4. 04基準・不変条件・ゲートとの対応付け
  5. 05計画・実行・ブロック状態の区別

活用シーン

  1. 01コード変更のQA確認を計画
  2. 02必要な環境と証拠を整理
  3. 03環境や予算による未確認範囲を記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/carlitose/agent-skills --skill qa-test-plan

インストール後、Claude Code で/qa-test-planを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

QA テスト計画

担当範囲:QA 計画の作成です。テストの実行、コードの変更、ゲートの解決、完了/リリース状況の判断、Verification Record の作成は行いません。

正規のVerification Recordに記載された分類体系と識別子を使用してください。観察結果は呼び出し元が記録し、意味上の唯一の集約はverification-auditが行います。

入力

次の取得経路のいずれかを受け入れます。

  • ランナーからの引き継ぎ: 正規化済みのTicket Envelope、受け入れ基準、凍結された差分、CandidateRef、提供された不変条件/境界、環境、ゲート、観察済みのチェック。
  • スタンドアロンでの取得: PR、コミット、ローカル差分、またはユーザーが依頼した範囲を読み取り専用で取得します。観察された識別情報、依頼された動作、リポジトリのルール、利用可能な環境、制限事項、チェックを記録します。

Markdown を解析して Ticket Envelope を捏造してはなりません。不明な入力はドラフトの制限事項またはゲートとして記録し、アクセス可能であることや実行が成功することを前提にしてはなりません。

変動する取り込み量の上限

  • max_volatile_bytes:1 回の呼び出しにつき、正規化後の UTF-8 バイト数で 103998。これは、観測された差分候補の最高値 96,393 バイトに、チケット本文の最大値 2,380 バイトとレビュー引き継ぎの最大値 5,225 バイトを加えたものです。対象コーパスは、実行時の TK-01/TK-02/TK-05/TK-07/TK-08 の正規化済み git diff --no-ext-diff --no-color の観察結果、9 件のチケット本文、コンパクトなリーフ結果です。
  • max_single_output_bytes:32596。観測された TK-02 の実行可能コードの差分候補です。

すべての差分、生ファイルの抜粋、貼り付けられた引き継ぎ情報、エビデンス本文、ツールの結果は、CRLF または単独の CR を LF に正規化した後にカウントしてください。変更ファイルのマニフェストから開始し、コマンド出力がコンテキストに入る前に切り詰め、大きな素材はファイルまたはハンクごとに分割してください。貼り付けた成果物よりもパスと SHA-256 の参照を優先し、計画で扱う必要のある因果関係上の欠落を埋める場合に限って内容を読み込んでください。次に必要な読み込みで上限を超える場合は、調査済み範囲と未調査範囲を正確に示し、budget-exhaustedを付けたスキーマ 3 の部分計画を返してください。上限内に収めるために、因果関係のあるケース、エビデンス分類、不変条件、境界、ゲートを削除してはなりません。

計画の作成

まず、検証の受け入れ条件と試行あたりのコストを適用してください。コストの高い実行を受け入れる前に、現在の識別情報と、デリバリーされたパッケージング/アーティファクトグラフの結果を必須とします。失敗したシャードや置き換えられたシャードを含め、過去のすべての試行を一覧にし、元のエビデンス識別情報と不明なコストを保持してください。必須のプロファイルや正確な HEAD に対する CI を免除せず、因果関係に基づくチェックを選択してください。全スイートを繰り返す場合は、新しい CandidateRef だけでなく、具体的な理由と今回の試行に残っている予算が必要です。

変更された動作ごとに、次の項目を実施します。

  1. 注入箇所からユーザー/外部の観察結果までの因果関係を示します。
  2. 変更された仕組みを通過する最小のテストを選択します。
  3. 正規のリファレンスに従って、対象の観察結果を static、unit、integration、simulated、または live に分類します。
  4. 正確なセットアップ、操作、期待結果、クリーンアップ、取得するエビデンスを明記します。
  5. ケースをチケットの基準、不変条件、境界項目、ゲート ID に対応付けます。
  6. 関連する場合は、負のケース/エラーパス、リトライ、順序/冪等性のチェック、回帰テストを追加します。

モックされたプロバイダーや偽のブラウザーを live として分類してはなりません。必須の環境、認証情報、承認、またはデバイスを利用できない場合は、具体的な未解決ゲートと承認済みのシミュレーション計画を記載し、要件を黙って引き下げてはなりません。

出力

ランナーへの引き継ぎでは、呼び出し元の schema-3 qa-plan リーフ結果を返します。これを正確な CandidateRef と正規のフェーズ契約に結び付けます。schema-1 の quality ペイロードには、因果スコープ、コンテンツアドレス指定された計画済みエビデンスの参照、制約事項を記載します。タイムアウトまたは中断時は、complete: false、最後に永続化されたフェーズ、正確な残りのフェーズを返します。部分的な計画を破棄したり、合格と判定したりしないでください。 観測された分離を含む正規化済みの schema-3 execution を含めます。要求された計画から、委任、コンテキストの分離、並列実行、権限を推測してはなりません。

単独で取得する場合は、次を返します。

# QA Plan

## Candidate
- CandidateRef:

## Admission and Cost
- Current identity, delivered packaging/artifact-graph results and evidence references.
- Prior attempts/shards with original identities, outcomes, durations and artifact hashes.
- Summed invocation time versus measured end-to-end elapsed time; unknowns and lower bounds.
- Selected/omitted checks with causal or mandatory-policy reason, full-repeat justification,
  estimated next cost, the current attempt's remaining budget and unresolved execution state.

## Automated Checks
- ID, command, layer, causal path, expected evidence.

## Manual / Environment Checks
- ID, setup, action, expected observation, evidence class, cleanup.

## Negative and Regression Paths
- ID, failure or preserved behavior, expected observation.

## Mapping
- QA ID -> acceptance criterion / invariant / boundary item / gate.

## Open Gates and Limits
- Gate ID, owner, unblock condition, and claim impact.

チェックを計画したことは、チェックを実行した証拠にはなりません。計画済み、実行済み、合格、失敗、スキップ、ブロックの状態を明確に区別してください。単独のドラフトでは、チケットの完了やリリースを主張できません。

コメント