このツールについて
すべてのチームが Jira を使っているわけではありません。このツールは、GitHub issue、Azure DevOps、Linear、Confluence、メールなど、トラッカーを問わず使えるバグレポートを作成し、バグの扱いを左右する 2 つの点を記録します。どれだけ確実に再現するか、そしてデグレード（リグレッション）かどうかです。「断続的、10 回中 3 回」とあれば開発者はタイミングや状態の問題を疑い、「デグレード、最後に正常だったビルドは 2.30.4」とあればゼロからデバッグする代わりに 2 つのビルドを比較できます。GitHub 形式では、タイトルを本文から除き（専用のフィールドがあるため）、「キー: 値」形式の環境の行を表に変換し、添付ファイルをチェックリストとして並べるので、ファイルのドラッグを忘れません。
使い方
- 具体的なタイトルと、誰が影響を受けるかを 1 行で説明します。
- 手順、期待結果と実際の結果、そして「キー: 値」形式の行で環境を記入します。
- 再現性（常に、回数付きの断続的、1 回のみ）と、以前のビルドでは正常に動いていたかを設定します。
- Markdown、GitHub issue、テキストから選び、コピーまたはダウンロードします。作業中の内容はこのブラウザに保存されます。
バグレポート作成ツール のよくある質問
ときどきしか再現しないバグはどう報告すればよいですか？
「Intermittent」（断続的）を選び、何回の試行で何回発生したかを記録します。ログイン後の初回実行、遅いネットワーク、特定のアカウントなど、関連がありそうなことを説明に追加してください。「ときどき」よりも比率のほうがはるかに役立ちます。
最後に正常だったビルドを尋ねるのはなぜですか？
バグがデグレードで、最後に正常に動いていたビルドがわかっていれば、開発者は 2 つのビルドを比較したり、その間のコミットを二分探索したりできます。通常、現在のビルドだけをデバッグするよりもずっと速く原因にたどり着けます。
ここでスクリーンショットを添付できますか？
いいえ。ファイルはトラッカー側で管理します。レビュアーがどんな証拠があるかわかるよう添付ファイル欄にファイル名を記載し、GitHub や Jira などレポートの提出先でアップロードしてください。