長い間テストをしている人なら、このような気持ちを抱いたことがあるはずです。要件レビューでは誰もがうなずいていたのに、オンラインになると、「製品は書かれていないが、考えられるべきだった」という落とし穴がたくさんありました。私は何百ものユースケースを書きましたが、振り返ってみると、境界と例外の半分が漏洩していることがわかりました。自動化スクリプトはますます移動することを恐れるようになり、すべての変更が失敗しました。ストレステストが完了した後、レポートのボトルネックはすべて頭を撫でることに基づいていました。
このセット QAエージェントのスキル これらが私が解決したいことです。テストポジションの高頻度アクションを 8 つの独立したスキルに分割します。各スキルは 1 つのことだけを行いますが、それは標準的な方法で実行され、次元を見逃すことはなく、ユーザーに代わってランダムな決定を下すこともありません。わかりやすく説明するためにいくつかの写真を示します。
1. 一文で理解: 8 つのスキルがテスト パイプラインに結び付けられる
8 つの名前を見て怖がらないでください。これらは実際には、テストのさまざまな段階に対応する、左から右への組み立てラインです。要件が入力され、ユースケースが出力され、スクリプトとレポートが完成し、役割分担が明確になります。
2. 各スキルの役割 (1 枚のカードで 1 つのことを行う)
各スキルは同じ構造に従います。電話をかけるタイミング → 契約の入力 → 実行プロセス → カバレッジマトリックス → 契約の出力 → 品質ゲートコントロール → 手動による意思決定 → 境界とピット。以下はその「IDカード」です。
3. すべてのスキルに共通する「内なる力と精神技術」
8つのスキルは見た目は異なりますが、その背後にある考え方は同じです。この図を理解すると、フレームワーク全体が「安定」している理由が理解できるでしょう。
4. 一度にすべてを進めず、段階的にルートを進めてください
フレームは良いのですが、一気に入れると「味気ない」ものになりがちです。 README では、チームの現在の問題点に応じて、どの問題点に最初に対処する必要があるかという、非常に実用的な進歩の順序が示されています。
5. スキルの「内部フロー」を見てみましょう: Web オートメーションを例に挙げます。
先ほど申し上げたのは水平組立ラインです。垂直的には、各スキルにも独自の明確な内部プロセスがあります。 05 の Web オートメーション ブループリントを例に挙げると、「最初に画像、後からスクリプト」を主張しているため、「書いた後はあえてメンテナンスしない」という問題を解決できます。
6. Cursorへのインストール方法（3ステップ）
フレームはカーソル エージェントによって使用されます – を押します description 自動マッチングトリガー、手動でも実行可能 @ 点呼。たった 2 行のコマンドです:
これらは、「カーソル設定」→「スキル」で確認できます。会話の中でそれらを使用する @01-requirement-analysis 点呼、またはエージェント自身にボタンを押させる description マッチ。新しいスキルを追加するのも簡単です: コピー _template/SKILL.md → 9 章を記入 → 作成 references/ そして assets/ → README テーブルに行を追加するだけです。
7.最後に書く
このフレームワークで最も印象的なのは、どれだけ多くのスキルを持っているかではなく、拘束: AI は自身の境界を明確に知っています。AI は次元を埋め、穴を占領し、証拠を整理する責任があります。しかし、「オンライン化するべきなのか、ボトルネックはどこにあるのか、ビジネスルールはどうやって決めるのか？」責任が必要な事柄はすべて人間に委ねられます。
テスト チームにとって、これは次のことを意味します。新人はテンプレートに従ったディメンションを見逃すことがなくなり、上級者は経験を再利用可能な資産に蓄積し、レビュー ミーティングとストレス テストのレビューで最終的に言語が統一されるようになります。あなたもテストチームを率いている場合、または「ユースケースを書き終えられず、自動化を維持できない」ことに悩まされている場合は、フェーズ 1 の 01 から始めて、最初は要件レビューを少し静かにしておいてもよいでしょう。
