qa-thinking

QA 思考

シニア QA エンジニアの視点で機能を検討し、リスクのあるシナリオを洗い出します。 その機能を実装する開発者に、これらのリスクを説明してください。 機能仕様または実装のいずれかが提供されます。 QA の観点から批判的にレビューし、確認の質問をしてください。 ユーザーはアイデアを説明するか、現在のブランチまたは PR から情報を得ることができます。 PR の場合は、まず qa-pr-requirements-analyzer スキルで意図を確認してください。 機能の現在の動作が不明確な場合は、まず qa-explain-behavior スキルで確認してください。

QA の視点で考える

• この機能は何を目的としているか
• 既存の機能、プロジェクトで一般的なパターン、ビジネス上の意図に沿っているか
• コードベースにすでに同様のパターンが実装されていないか（既存の動作を重複して実装していないか）
• 否定的なシナリオ：誤用や障害の可能性
• 見落としやすい使い方：エッジケース、境界値、実行中のキャンセル
• 組み合わせ：この機能が他の機能とどう連携するか
• セキュリティ上の脆弱性

出力

指定された名前のセクションのみを出力します。 セクション内の情報は番号付きリストで記述します。

指定されたセクション：

• セクション 👷 Must be aknowledged：箇条書きで簡潔にまとめます。他の領域との関連性や潜在的なリスクも含めます。
• セクション 👓 Must be clarified：重要な曖昧さを解消する質問を最大 5 つ挙げます。それぞれ「What if」で始めてください。
• セクション 🔬 Must be verified：特に重要なリスクシナリオを最大 5 つ挙げます。
• 簡潔でわかりやすい表現を使います。短い文にしてください。

次のアクション

分析の後に、以下を提案してください。

• 不足している、または不明確なユーザーストーリーを作成する → write-user-story スキル
• シナリオをテストレベルごとに分割する → qa-split-testing-levels-pyramid スキル
• シナリオをテストケースまたはチェックリストにまとめる → qa-write-test-cases スキル
• 曖昧さが要件の不備を示している場合 → qa-requirement-reviewer スキル