test-strategy

テスト戦略

中国語版： 対応する中国語のスキルを参照してください。

使用する場面

• 実際のプロジェクトの状況に即したテスト戦略の支援が必要な場合。
• 実行、レビュー、または後続作業にそのまま使用できる成果物が必要な場合。

ワークフロー

1. Progressive disclosure に記載されているメインプロンプト（カバレッジ、構成、品質基準）を読み、それに従います。
2. 結果に影響するプロジェクトのコンテキストだけを追加します。対象範囲、環境、制約、リスク、依存関係、期待される成果物を含めます。
3. 入力が不完全な場合は、実用的な初稿を返し、前提と不足情報を明示します。
4. 既定では Markdown を使用し、ユーザーからの要望がある場合にのみ形式を変更します。

ドメイン実行の要点

1. 目的→義務／対象範囲→レイヤー／深度→データ／環境→リソース／担当者→開始／終了ルールの根拠→証拠／残存リスクを結び付けた、最低限実行可能な表を作成します。
2. プロジェクトのスタックと実際の対応能力を活用し、重大な損失や権限に関する義務を優先して保護します。各シナリオにはビジネス上の事後条件／証拠が必要です。リソースが不足している場合は、未完了の作業と最低限の代替案を明らかにします。
3. ゲートはプロジェクトに基づいて設定します。しきい値がない場合は未確定／UNKNOWN のままにし、自動的に 95% を合格基準として適用してはいけません。人によるリスク受容を戦略の草案で代替することはできません。
4. 設計、計画、実際の実行、受け入れを分けます。別の実行担当者が引き継げるように、依存関係／ブロッカー、変更、中止／再評価のトリガー、担当者を含めます。

中核となる制約

• リスク／ビジネスへの影響に基づいて優先順位を付け、すべてを同等に扱わないでください。
• 確認済みの事実と現時点での前提を分けてください。
• ユーザーが提示していないエンドポイント、フィールド、環境、根本原因を捏造しないでください。
• 出力は実行可能なものにします。具体的なシナリオ、明確な優先順位、明確な次のステップを示してください。

段階的な情報開示

• ドメインの成果、適切な制御、証拠の不足を評価する際は、サニタイズ済みの入力、項目ごとのオラクル、再現可能な計算について、references/domain-decision-example.md を参照してください。

• 出力を作成する前に、prompts/test-strategy.md を読み、その内容に従ってください（最低限のカバレッジ、出力構成、品質基準）。

• Excel／CSV／JSON／Word が指定された場合は、output-formats.md を読み、指定形式を守ってください。

• 既製のテンプレートが適している場合は、output-templates/ 内の対応するファイルを使用してください。

• フレームワークの詳細、トラブルシューティング、スキーマに関するメモを参照する場合は、references/ 内の関連ファイルのみを読み、ディレクトリ全体を読み込まないでください。

• 形式変換や補助的なチェックには、独自に作り直すよりも既存の scripts/ を優先してください。

• このスキルの評価／回帰テストには、skill-up と evals/ を使用してください。

提出前チェックリスト

• メインプロンプトの出力構成に従った
• 最低限のカバレッジに重点を置いた：目標と対象範囲、品質リスク、テストの種類と深度、優先領域、リソースと担当者の要件、環境とデータの戦略、開始と終了の考え方、自動化の方向性、……（詳細はメインプロンプトを参照）
• 最低限のチェックリストを網羅した、または省略項目について説明した
• 高リスク項目に明確な優先順位を付けた
• ユーザーが提示していない詳細を捏造しなかった
• 前提と不足情報を明示した

よくある落とし穴

• 対象範囲やコンテキストが不足しているのに、完全な内容であるかのように装わないでください。
• すべての項目を同等に重要なものとして扱わないでください。
• 前提や情報の不足を省略しないでください。
• 現在のツールチェーンに関係のない一般論を羅列しないでください。