manual-testing

手動／探索的テスト

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

使用する場面

• 実際のプロジェクトの状況に即した手動テストの支援が必要な場合。
• 実行、レビュー、またはフォローアップにそのまま使える出力が必要な場合。

ワークフロー

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

ドメイン実行の要点

1. 各タイムボックスに、タスク／リスク、環境／ビルド、データ、探索範囲、期限、証跡を明記します。許可された範囲内で、スクリプト実行と探索を分けて記録します。
2. 前提条件→操作→期待結果→実際の結果→証跡 ID→状態を記録します。未開始は NOT_RUN、中断は INCOMPLETE、環境による実行不能は BLOCKED とします。チェックリストは実行ログではありません。
3. 復旧可能なデータ／チェックポイントを準備し、ポリシーに従ってアカウント／注文／設定を復元して、残存物がないか確認します。許可されていない削除は後片付けではありません。
4. 時間が限られている場合は、まず重大なリスクの検証サイクルを完了し、その後、未完了の作業、担当者、再開地点を記録します。結論の対象は観察事項のみとし、判定基準が不明な項目は未解決のままにします。

主な制約

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

段階的な開示

• ドメイン上の結果、有効な制御項目、または証跡の不足を判断する際は、無害化された入力、項目ごとの判定基準、再現可能な計算について、references/domain-decision-example.md を参照してください。

• 出力を作成する前に、prompts/manual-testing.md を読み、その指示（最低限のカバレッジ、出力構成、品質基準）に従います。

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

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

• 形式変換や補助的なチェックには、作り直すのではなく既存の scripts/ を優先して使用します。

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

提出前チェックリスト

• メインプロンプトの出力構成に従った
• 最低限のカバレッジに重点を置いた：範囲、主要なユーザーフロー、セットアップとアカウント、正常系チェック、異常系チェック、境界値チェック、探索の重点領域、収集する証跡、…（詳細はメインプロンプトを参照）
• 最低限のチェック項目を網羅した、または省略した項目を説明した
• 高リスク項目に明確な優先度を付けた
• ユーザーが提示していない詳細を作り上げていない
• 前提と不足情報を明示した

よくある落とし穴

• 範囲／コンテキストが不足しているのに、網羅できているかのように見せないでください。
• すべての項目を同じ重要度として扱わないでください。
• 前提や情報の不足を省略しないでください。
• 現在のツールチェーンに関係のない一般論を羅列しないでください。