How to Computer Use でアプリをQAする with Eigent

仕組み

1. どのアプリ環境をテストするか、そしてどのユーザーフローが最も重要かを Eigent に伝えます。
2. Eigent が各フローをクリック操作でたどり、フィールドに入力し、どこで問題が起きるかを記録します。
3. 見つかったバグごとに、Eigent は再現手順、期待される結果、実際の結果、重大度を記録します。
4. Eigent は非ブロッキングな問題を越えて続行し、最後に短いトリアージ要約で締めます。
5. 必要に応じて、見つかったバグの修正、Linear への課題作成、または次回の実行を1つの失敗フローに絞るよう Eigent に依頼できます。

さらに試せるプロンプト

• アプリをテストして。重大な問題があれば見つけて、レポートにまとめてください。
• staging でサインアップ、チームメンバーの招待、課金プランのアップグレードをテストしてください。すべてのバグを再現手順、期待される結果、実際の結果、重大度とともに記録してください。
• QA 実行を続けて、チェックアウトフローのみに集中してください — すべてのエッジケースを把握したいです。
• このレポートの P1 バグを Linear の下書き課題に変換してください。

使い方

local、staging、または production-like のどの環境をテストするか、そしてどのフローを対象にするかを Eigent に伝えてください。壊れている機能、レイアウトの問題、わかりにくい文言、またはそれらすべてなど、気になる問題の種類を指定します。アカウント状態、テストデータ、または feature flags がフローに影響する場合は、最初にその情報も含めてください。1つのブロッキングな問題が見つかった時点で実行を終了したい場合は、そのように伝えてください。そうでなければ、Eigent はすべての問題を収集し、最後に要約します。実行後は、バグの修正、チケット作成、または特定の失敗フローに対するフォローアップ実行を Eigent に依頼できます。

想定される出力

見つかったすべての問題を、再現手順、期待結果と実際の結果、重大度付きで一覧化した構造化バグレポート。最後に、P0〜P2 の所見と推奨される次のアクションをまとめた短いトリアージ要約で終わります。

制限事項

• Computer Use は UI を直接操作して検証します — インターフェース上に見えないサーバーサイドロジックやバックグラウンドジョブはテストできません。
• テスト精度は、アカウント状態と環境の詳細を事前に明確に提供するかどうかに左右されます。
• 非常に長い、または複雑なテスト計画は、1回の長い実行ではなく、焦点を絞った複数回の実行に分割すると効果的です。