mcpField
Q
qa-checklist

qa-checklist

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

qa-checklist について

qa-checklistは、コード差分をデプロイ済みアプリ向けの短い手動QAチェックリストに変換するスキルです。コードレビューや回帰テストではなく、ユーザーに見える変更を対象にします。

主な機能

  1. 01ブランチと基準との差分を確認
  2. 02コード変更を画面上の動作に変換
  3. 03主要な失敗経路と関連フローを対象化
  4. 04約5~10項目のチェックリストを作成

活用シーン

  1. 01リリース前の機能変更の確認
  2. 02フォーム検証とアクセス制御のテスト
  3. 03フィーチャーフラグの両状態の確認

インストール

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

$npx skills add https://github.com/unlearndev/skills --skill qa-checklist

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

詳細

差分から手動QAチェックリストを作成する

変更が正しく動作することを確認できる、デプロイ済みアプリで人が実行できる短いチェックリストを作成します。対象読者はブラウザーとテストアカウントを持つ人であり、コードを読む開発者ではありません。各手順は、UI(まれに、その変更がメール受信トレイ/API クライアントにしか表示されない場合はそちら)を通じて実行し、結果を確認できる内容にしてください。

これは回帰テスト一式でもコードレビューでもありません。この差分で変更された内容と、副作用で問題が起こりやすい隣接するフローを1、2個だけ対象にしてください。チェックリストが約10項目を超える場合は範囲が広すぎます。変更が実際に及んだ箇所だけに絞ってください。

1. 差分を取得する

特に指定がなければ、現在のブランチとmainを比較します。ユーザーが指定したベース、コミット範囲、PRがあればそれに従ってください。

git fetch origin
git diff origin/main...HEAD --stat     # overview
git diff origin/main...HEAD            # read the whole diff

このブランチで追加された内容だけを確認できるよう、...(マージベース)を使ってください。差分だけでは判断が難しい場合は、変更されたファイルを開いてください。移動した行だけでなく、ユーザーから見える動作を把握する必要があります。

2. コードの変更をユーザーから見える動作に置き換える

変更ごとに、**「これによって、ユーザーが目にするものや操作がどう変わるか?」**を考えてください。チェックリストに含める内容は、その問いへの答えで決まります。

  • コントローラー/ルート/ページ — 実際に操作するページやアクションを記載します。新しいルートならアクセスし、ストア/更新ロジックが変更されたならフォームを送信して結果を確認します。
  • バリデーションと認可 — 失敗するケースもQA手順に含めます。無効な入力を送信してインラインエラーが表示されることを確認し、権限のないユーザーとして操作を試してブロックされることを確認します。
  • フロントエンドコンポーネント — トグル、モーダル、楽観的更新、空の状態、フラッシュメッセージなど、クリックして確認する操作を記載します。
  • フィーチャーフラグ — 動作が制御される場合(例:Pennant)、フラグが有効な場合と無効な場合の両方を確認します。有効時は機能が表示され、無効時は適切に非表示になることを確認してください。差分から対象アカウントを特定できる場合は、その方法も記載します。
  • メール/通知/ジョブ — アクションを実行した後、確認できる結果(メールの受信、通知の表示など)を確認します。確認できる表示がないものは省略してください。
  • マイグレーション/データ変更 — ユーザーに見える内容が変わる場合(ページ上のフィールド名変更など)に限ります。マイグレーションの実行はデプロイ用チェックリストに含め、このチェックリストには含めません。

動作に変更のないリファクタリング、テストのみの変更、CI/ツール類、コードスタイルはすべて省略してください。差分全体がそれらに該当する場合は、その旨を伝えてください。「手動QAは不要です」という回答も有効です。

3. チェックリストを作成する

Markdown形式のチェックリストを1つだけ出力してください。ルール:

  • 平易な英語で、命令形の手順にします。「フィードバック項目を開いて👍リアクションをクリックする」とし、「ReactionController@store がリアクションを永続化することを確認する」とはしません。クラス名、コード上のルート名、ファイル名には言及しないでください。
  • 各手順に操作と期待される結果を組み合わせます。Xを実行すると、Yが表示されるはずです。
  • 一連の流れに沿って手順を並べます。準備から始め、操作を実施し、副作用を確認するまで、前の手順に戻らずに進められるようにしてください。
  • 必要な前提条件があれば、冒頭の1行に記載します。2つ目のテストアカウント、フィーチャーフラグの有効化、操作対象となる既存レコードなどが該当します。
  • チェックボックスはおおよそ5~10個にします。コードパスごとではなく、動作ごとに1項目とします。

形式:

## QA checklist — <one-line summary of the change>

**Before you start:** <preconditions, or omit this line>

- [ ] <action> — <expected result>
- [ ] ...

ほかには何も付け加えずに終えてください。差分の要約やコードに関するコメントは不要です。

コメント