automation-testing

自動テスト（英語）

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

使用する場面

• 実際のプロジェクトの状況に応じた自動テストの支援が必要な場合。
• 実行、レビュー、または後続作業にそのまま使用できる出力が必要な場合。

ワークフロー

1. Progressive disclosure に記載されているメインプロンプト（対象範囲、構成、品質基準）を読み、従ってください。
2. 結果を左右するプロジェクトの状況のみ追加してください。対象範囲、環境、制約、リスク、依存関係、期待する成果物などです。
3. 入力が不完全な場合は、実用的な初稿を提示し、前提と不足情報を明示してください。
4. 既定では Markdown を使用してください。ユーザーから要望があった場合に限り、形式を切り替えてください。

ドメイン実行の要点

1. 候補のフロー｜保護義務｜繰り返し頻度の根拠｜オラクル／可観測性｜分離／クリーンアップ｜安定性｜保守上の制約｜採用／延期の理由、に基づいて選定してください。ROI のコストシナリオは分けて扱ってください。リターンの見込みがあっても、オラクルや権限の欠如は補えません。
2. 既存のフレームワークを再利用してください。まず、観測可能な事後条件、独立したデータ、失敗を伝播する CI のエントリーポイントを必須としてください。条件を満たさない候補は、解決条件を示したうえで延期してください。
3. 一意の識別子／ビジネスキー、セットアップ、操作、ビジネス上の事後条件、失敗シグナル、ティアダウンを明記してください。アサーションの失敗はログに記録するだけでなく、ランナー／CI を失敗させる必要があります。
4. 候補の選定、生成されたアセット、実際の実行、ビジネス上の受け入れを分けてください。急速に変化するプロトタイプや分離できない実際の決済では、Human／管理された検証が必要になることがあります。判断には根拠を示してください。

主な制約

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

段階的な情報開示

• ドメインの結果、有効な制御、または根拠の不足を判断する際は、サニタイズ済みの入力、項目ごとのオラクル、再現可能な計算を確認するため、references/domain-decision-example.md を読んでください。

• 出力を作成する前に、prompts/automation-testing.md（最低限の網羅範囲、出力構成、品質基準）を読み、従ってください。

• Excel／CSV／JSON／Word が求められた場合は、output-formats.md を読み、形式に従ってください。

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

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

• 形式変換や補助チェックには、一から作り直すのではなく、既存の scripts/ を優先してください。

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

提出前チェックリスト

• メインプロンプトの出力構成に従った
• 最低限の網羅範囲を確認した：対象範囲と目的、自動化候補、手動のみの領域、リスクと ROI に基づく優先順位、フレームワークとの整合性、データと環境の要件、不安定なテストのリスク、CI または実行戦略、...（詳細はメインプロンプトを参照）
• 最低限のチェックリストを網羅した、または省略した項目を説明した
• 高リスクの項目に明確な優先順位を付けた
• ユーザーが提示していない詳細を作り出していない
• 前提と不足情報を明示した

よくある落とし穴

• 対象範囲や状況が不足しているのに、網羅できているかのように見せないでください。
• すべての項目を同等に重要なものとして扱わないでください。
• 前提や情報の不足を省略しないでください。
• 現在のツールチェーンに関係のない一般論を大量に並べないでください。