manual-testing

手動テスト

ツールで可能な限りすべてを証明してから、人間の目、手、デバイス、または判断が必要なものだけをユーザーに確認してもらう、短い検証サイクルで作業を完了してください。

テスト計画をユーザーに考えさせないでください。手順を示して進めてください。

品質基準

ユーザーに何かを依頼する前に、次の点を把握してください。

• 何を変更したか
• 期待される動作は何か
• 何を自動で検証できるか
• 人による確認がまだ必要なものは何か
• 近接する動作にどのようなリグレッションが起きる可能性があるか

ユーザーに「いろいろ試してみて」や「うまく動くか教えて」と頼むのは避けてください。具体的な操作、画面またはコマンド、期待される結果、返信に含めてもらう簡潔な選択肢を提示してください。

ワークフロー

1. 検証マトリクスを作成する

何かを実行する前に、変更内容を簡潔な検証計画に落とし込んでください。

変更した動作ごとに、次の項目を記録します。

• 主な成功パス
• 最も起こりやすい失敗またはエッジケース
• 近接するリグレッションの確認項目を1つ
• 検証担当：ツールまたはユーザー

次のようなシンプルな内部チェックリストを使用してください。

動作	正常系	エッジケース／リグレッション	検証担当
設定の保存	フォームが保存される	バリデーションエラーも引き続き機能する	ツール＋ユーザー

マトリクスは小さくまとめ、現在の変更に焦点を当ててください。

2. まずツールで検証できるチェックを実行する

ユーザーに依頼する前に、自動検証をすべて実施してください。

次の項目は、できる限り自分で検証してください。

• ビルド、コンパイル、型チェック、リント、テスト
• API のレスポンスとステータスコード
• ファイル出力、データベースの状態、ログ、副作用
• CLI の動作、終了コード、生成されたアーティファクト
• ツールで確認できる場合は、ブラウザーの自動操作、スクリーンショット、DOM テキスト、ネットワーク動作

結果が次の項目に左右される場合に限り、ユーザーに作業を依頼してください。

• 視覚的な正しさ
• 動き、タイミング、操作感
• 実機での動作
• ブラウザー間の違い
• スクリーンリーダーでの動作
• 人の操作が必要なサードパーティのフロー

自動チェックに失敗した場合は、手動検証を依頼する前に作業を止め、問題に対処してください。

3. ユーザーが確認しやすい手順を用意する

ユーザーが最小限の手間で確認できるように準備してください。

次の情報を提示します。

• 正確なルート、URL、画面、またはコマンド
• 必要なセットアップ状態
• 実行する操作を1つ
• 期待される結果
• 返信してもらう内容

アプリを起動した状態にしておく必要がある場合は、開く場所を正確に伝えてください。状態、データ、フィクスチャを安全に準備できる場合は、事前に自分で用意してください。

4. 具体的な手順でユーザーを導く

曖昧な指示をまとめて提示するのではなく、順を追って手動検証を進めてください。

できる限り、一度に1つの操作だけを依頼してください。短いスモークテストなら、密接に関連するチェックを最大2～3個までまとめてください。

次の形式を使用します。

Testing: [feature or fix]
Progress: Step N of M

Action: [exact thing to click, type, or inspect]
Expected: [what should happen]
Reply with one:
1. [expected outcome]
2. [common failure mode]
3. [second common failure mode]
4. Other

構造化質問ツールが利用できる場合は、返信の選択肢を構造化プロンプトにしてください。利用できない場合は、選択肢を併記して通常のテキストで質問してください。

例：

Testing: profile photo upload
Progress: Step 2 of 3

Action: Open `/settings/profile`, upload a PNG under 2 MB, and wait for the save state to finish.
Expected: The new avatar appears in the header and no error message is shown.
Reply with one:
1. Upload worked and the new avatar is visible
2. Upload finished but the avatar did not update
3. I saw an error message or spinner got stuck
4. Other

5. 適切な範囲を確認する

変更した経路を必ず最初にテストし、次に最も失敗しやすい箇所を確認してください。

次の項目を、確認範囲を調整するためのチェックリストとして使用してください。

UI の変更の場合：

• 初期表示を確認する
• 該当する場合は、読み込み中、空、エラー、無効、成功の各状態を確認する
• インタラクティブなコントロールのキーボード／フォーカス操作を確認する
• レイアウトに影響する変更の場合は、モバイルまたは狭い画面幅での表示を確認する
• 文言、間隔、明らかな視覚的リグレッションを確認する

バグ修正の場合：

• 元のバグが発生する経路を再現する
• バグが発生しなくなったことを確認する
• 近接する経路も引き続き正しく動作することを確認する

API またはバックエンドの変更の場合：

• 正常系のレスポンスを確認する
• 無効な入力または失敗時の動作を確認する
• 永続化された副作用または下流の状態変更を確認する
• ログまたはエラーに新たな問題がないことを確認する

CLI またはローカルツールの変更の場合：

• 成功パスを確認する
• よくある失敗パスと終了コードを確認する
• 該当する場合は、出力ファイル、stdout／stderr、ヘルプテキストを確認する

6. デバッガーのように失敗に対処する

ユーザーから問題の報告があった場合：

• 失敗した正確な手順を記録します
• 期待された動作と実際の動作を記録します
• 確認できるエラーテキスト、ログ、スクリーンショットがあれば記録します
• 直ちに停止して調査するか、残りのチェックを続けても価値がある場合に限り続行するかを判断します

コードを変更する前に、失敗について妥当な仮説を2～3個立てます。そうすることで、次のデバッグ手順を当てずっぽうではなく、意図的に進められます。

失敗によって変更への確信が持てなくなる場合は、手動テストを中止して原因の診断に切り替えます。

7. 確信できる点と未解決点をまとめる

最後に、証明できたことと、まだ仮定にとどまっていることを分けて、簡潔な検証結果をまとめます。

以下を含めてください：

• 実行した自動チェックとその結果
• 完了した手動手順とその結果
• 見つかったバグやリグレッション
• 未検証の領域
• 推奨する次のアクション

ガイドライン

• ユーザーの負担を最小限にし、エージェントの作業を最大限にします
• ユーザーが一度に一つのコンテキストに集中できるようにします
• 自由回答形式の質問より、具体的な回答の選択肢を提示します
• 実行可能な場合は、成功パスを1つ、失敗パスを1つ、関連するリグレッションを1つ確認します
• 人による確認を依頼する前に、ツールを積極的に活用します
• 何をテストしているのか、何がすでに合格したのかをユーザーが把握できるよう、進行状況を明確に伝えます