mcpField
B
browse-qa

browse-qa

github.com/ulpi-ioテスト・品質5148 回インストール9 週間前に更新
リポジトリ

browse-qa について

browse-qa は、依頼をテストシナリオに分解し、実際の対象で検証して証拠付きのレポートを作る QA スキルです。明確な受け入れ基準が必要な QA 作業に向いており、適切な場合は再実行可能な回帰フローも保存します。

主な機能

  1. 01対象と受け入れ基準の明確化
  2. 02正常系・異常系・境界シナリオの計画
  3. 03browse によるブラウザーやシミュレーター操作
  4. 04結果を裏付ける証拠の収集
  5. 05範囲を絞った回帰フローの保存
  6. 06構造化された QA レポートの作成

活用シーン

  1. 01受け入れ基準に沿った機能テスト
  2. 02エラー経路や境界ケースの調査
  3. 03安定した手順の回帰テスト用記録
  4. 04阻害要因や未検証項目の報告

インストール

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

$npx skills add https://github.com/ulpi-io/skills --skill browse-qa

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

詳細

このスキルは、QA 計画とレポートを担当します。低レベルのブラウザーコマンドの解説は担当しません。

譲れないルール:

  1. テストを始める前に、受け取った仕様を明示的なシナリオに落とし込みます。
  2. あいまいな対象やプラットフォームは、実行前に確認します。
  3. 実際のブラウザーやシミュレーターの操作には、browse スキルを使用します。
  4. 失敗したシナリオや重要なシナリオごとに、証拠を記録します。
  5. 再実行可能なフローを保存するのは、範囲が明確で、回帰テストに役立つ場合に限ります。

browse-qa

入力

  • $request:チケット、URL、アプリの対象、受け入れ条件、または自然言語で記述された QA の依頼

目標

以下を満たす、信頼できる QA 実行結果を作成します。

  • あいまいな依頼を明示的なシナリオに落とし込む
  • 実際の対象に対してシナリオを実行する
  • 成功と失敗の両方について証拠を記録する
  • 適切な場合は、再実行可能な browse フローを保存する
  • ユーザーが次の対応を判断できる、明確な QA レポートを提出する

ステップ 0:対象と仕様を確認する

以下を明らかにします。

  • テスト対象の機能
  • プラットフォーム:Web、iOS シミュレーター、Android エミュレーター、または macOS アプリ
  • 対象の URL、ビルド成果物、またはアプリ識別子
  • 受け入れ条件または期待される結果

対象やプラットフォームがあいまいな場合は、テストの前に確認してください。

成功条件:QA の対象と受け入れ条件が明確であること。

ステップ 1:シナリオのリストを作成する

依頼を以下に分けます。

  • 正常系
  • バリデーションまたはエラー系
  • エッジケース
  • 指定された受け入れ条件の確認後に試す価値のある探索的プローブ

ユーザーから広範な QA の実施を依頼された場合を除き、1 回のセッションで実行できる規模に計画を抑えてください。

成功条件:期待される結果を含む、具体的なシナリオのリストがあること。

ステップ 2:browse スキルで実行する

Skill を使用して browse を呼び出し、以下を行います。

  • ナビゲーション
  • ページの安定化
  • インタラクティブ要素の特定
  • クリック、入力、送信
  • スクリーンショット、コンソールログ、ネットワークの確認

ルール:

  • 意図的に分離する場合を除き、1 つの論理的なユーザージャーニーには同じ browse セッションを使用します
  • ヘッデッドモードまたはハンドオフモードを使うのは、CAPTCHA、MFA、OAuth の認証画面など、実際に必要な場合に限ります
  • スクリーンショットとフローの成果物は、browse セッションのディレクトリに保存します

成功条件:各シナリオが実際の対象に対して実行され、合否を判断できるだけの証拠があること。

ステップ 3:再利用可能な回帰フローを記録する

シナリオが安定しており、再実行する価値がある場合は、次のようにします。

  • フローを記録する
  • 関連のないユーザージャーニーは、別々のフローファイルに分ける
  • 保存する各フローに、内容が分かる名前を付ける

ノイズが多い記録や、手動操作が途中に残る記録は、回帰テスト用の成果物として保存しないでください。

成功条件:保存したフローを個別に再実行でき、明確なシナリオに対応していること。

ステップ 4:結果を報告する

各シナリオについて、以下を記録します。

  • 期待される結果
  • 実際の結果
  • 合格または不合格
  • スクリーンショットのパス、コンソールエラー、ネットワークの症状などの証拠

さらに、以下も報告します。

  • 探索的テストで見つかった事項
  • 作成した回帰フローファイル
  • 完全な検証を妨げたブロッカー

成功条件:別のエンジニアが、セッション全体を再実行しなくても QA の結果を理解できること。

ガードレール

  • browse コマンドのマニュアル全体をここに転載せず、browse スキルを使用してください。
  • 依頼があいまいな場合、プラットフォームを推測しないでください。
  • 回帰テスト用の成果物を作成したと示すためだけに、価値の低いフローを保存しないでください。
  • disable-model-invocation を追加しないでください。ユーザーから依頼があれば、QA を引き続き利用できるようにしてください。
  • context: fork を追加しないでください。通常、結果は現在の実行フローで必要になります。

出力仕様

以下を報告します。

  1. テスト対象
  2. 実行したシナリオ
  3. 各シナリオの合否
  4. 記録した証拠
  5. 作成した回帰フローファイル
  6. ブロッカーまたは未検証の項目

コメント