再現可能なソフトウェアバグ受付
再現可能なソフトウェア課題のためのバグ報告フォーム
報告者に、影響を受けるコンポーネントとビルド、実行環境、最短の再現可能な手順、期待結果、実際の結果、証跡を入力してもらいます。優先度の推測や修正担当の割り当ては求めません。
サインインしてこのサンプルデータ入りビューを確認し、サンプルデータ付きでアプリをインストールして、接続されたレコード、判断、ダッシュボードをテストします。
報告者が入力する項目と、トリアージが判断する項目
優れたバグ報告フォームは、別の人が問題を再現できる可能性を高めます。まず観測可能な事実を集め、その後でトリアージチームが重要度、優先度、担当、対象リリースを判断できるようにします。
- 報告者フィールドをトリアージフィールドから分離
- ファイル証跡を添付できるモバイル対応フォーム
- 黙って却下するのではなく、情報不足として差し戻す経路
報告者向けフィールドガイド
最小限で完全な再現情報一式を集める
すべてのフィールドは、誰かが問題を再現、分類、調査する助けになるべきです。
- 01
明確な要約
目に見える失敗と影響を受ける操作を説明します。
- 02
コンポーネントとビルド
分かる場合は、製品画面と正確なバージョンを選択します。
- 03
環境
デバイス、ブラウザー、OS、テナント、設定を記録します。
- 04
再現手順
最短の再現可能な順序を並べます。
- 05
期待結果と実際の結果
意図した結果と実際に起きたことを分けて記載します。
- 06
証跡と影響
有用な根拠を添付し、誰が作業を続けられないのかを説明します。
送信後
会話を失わずに不完全な報告を差し戻す
フォームは出発点にすぎません。トリアージでは、各結果に対する見える次のステップが必要です。
再現性を確認
環境を確認し、提示された手順を繰り返します。
不足している文脈を尋ねる
具体的な質問を添えて報告を差し戻し、同じレコードでやり取りを続けます。
重複を統合
新しい報告を削除するのではなく、正本となる課題にリンクします。
受理して割り当て
重要度、優先度、担当者、対象リリースを記録します。
人が行動に移せる報告を書く
曖昧な主張を観測可能な差分に置き換える
文脈、操作、結果が分かれていれば、短い報告でも十分に完全です。
| 弱い報告 | 対応可能な報告 | なぜ優れているか |
|---|---|---|
| チェックアウトが壊れている | Web 4.28.0 で 3DS から戻った後、決済確認がタイムアウトする | 操作、失敗、ビルドを示しています。 |
| 同期が重複する | 再接続後に同期を 2 回タップすると、同じローカル ID の行が 2 つ作成される | 再現可能なきっかけと観測可能な結果を示しています。 |
| エクスポートが間違っている | Reporting 12.2 のスケジュール CSV で、保存済みのカスタム列が 2 つ欠落する | モード、データ差分、リリースを特定しています。 |
質問と境界
バグ報告フォームに関する質問
どのフィールドを受付に置き、どのフィールドをトリアージに置くかを判断するための回答。
報告者に重要度と優先度を選ばせるべきですか？
通常はいいえ。報告者は業務影響と緊急度を説明し、トリアージチームが共通の重要度・優先度定義を適用します。
再現手順はどのくらいの長さにすべきですか？
別の人が繰り返せる最短の手順にします。セットアップが結果に影響する場合だけ含め、断続的な挙動は発生頻度を記録します。
報告者がビルドを知らない場合はどうしますか？
「未確認」を許可しつつ、トリアージが特定できるだけの環境情報を集めます。技術的な 1 フィールドが不明だからといって、有用な報告を止めないでください。
フォームはモバイルで使えますか？
はい。報告者はスマートフォンから影響を受けたコンポーネント、環境、再現手順、証跡を記録し、デスクトップ利用者と同じトリアージキューへ送信できます。
最初の引き渡しを改善
別の人が再現できる報告から始める
デスクトップまたはモバイルでサンプルフォームを開き、フィールドとルーティングを自社製品に合わせて調整します。