Jira バグチケット作成ツール

「Checkout: Place order stays disabled after promo code」のように、機能領域と症状がわかる概要を書きます。説明には、環境、番号付きの再現手順、期待結果、実際の結果、スクリーンショット・ログ・HAR ファイルなどの証拠を記載します。重大度、優先度、コンポーネント、影響バージョンを設定し、関連するストーリーをリンクします。1 チケットにつきバグは 1 つにします。このツールはその構成を提供し、Markdown や Jira Wiki 記法に整形します。

完全なバグレポートには、具体的なタイトル、環境（ビルドやバージョン、ブラウザ、OS、デバイス、テストアカウント）、前提条件、番号付きの再現手順、期待結果、実際の結果、重大度と優先度、そしてスクリーンショット・動画・コンソールログ・API レスポンスなどの添付ファイルが含まれます。再現頻度と回避策があればそれも追加します。目標は、開発者が質問せずにバグを再現できることです。修正されるバグレポートの書き方も参考にしてください。

重大度はバグがシステムに与える影響の大きさ、優先度はビジネスとしてどれだけ急いで修正したいかを表します。通常は一致しますが、常にではありません。めったに使われない管理者向けレポートでのクラッシュは重大度は高いが優先度は低く、トップページの社名の誤字は重大度は低いが優先度は高くなります。通常、重大度はテスターが提案し、優先度はプロダクトオーナーが決めます。一貫した分類には バグの重大度と優先度ガイドを使ってください。

ログアウト状態、新規アカウント、特定の URL など、既知の状態から始め、各操作を具体的なデータとともに番号付きの手順として書きます。例：「3. プロモコード欄に SAVE10 を入力して［適用］をクリックする。」バグを発生させるのに必要な手順だけを含め、報告する前にもう一度その手順をたどってください。断続的に発生するバグの場合は、5 回中 3 回のように再現率を記載します。期待結果と実際の結果は手順の中ではなく、手順の後に書きます。

実務上は同じ意味で、ISTQB の用語集でも「バグ」は「欠陥」の同義語として扱われています。つまり、コードや要件などの作業成果物にある欠点で、それによって要件を満たさないものです。テストで見つかったものを「バグ」、リリース後に見つかったものを「欠陥」と呼び分けるチームもありますが、それはローカルな慣習です。関連用語として、エラー（誤り）は欠陥を引き起こす人間のミス、故障（failure）は欠陥が発現したときにユーザーが目にするものです。

部分的には可能です。このツールはメモを一貫した構成のチケットに変換し、Jira Cloud（Markdown）や Jira Server・Data Center（Wiki 記法）向けに整形します。Jira への貼り付けはご自身で行います。SDETRole はお使いの Jira にアクセスできないため、課題の作成までは行いません。完全な自動作成には、Jira の REST API や、夜間テストが失敗したらチケットを起票する CI ジョブなどの連携が必要です。自動作成されたチケットは、重複を避けるためにレビューしてください。

事実に基づき、具体的かつ中立的に書きます。正確なタイトル、実データを使った再現可能な手順、期待される振る舞いと実際の振る舞い、そして証拠を用意します。「開発者がログインを壊した」のような責任追及や意見は避け、観察した振る舞いとユーザーへの影響を記述します。トリアージが速く進むよう書式を統一し、何千行ものログは貼り付けずに添付します。バグレポート作成ツールとこの Jira チケット作成ツールは、どちらも完全性チェックリスト付きのプロフェッショナルなテンプレートを適用します。

Markdown を使ってください。現行の Jira Cloud エディターは、貼り付けた Markdown の見出し、リスト、コードブロックを変換します。Wiki 記法は Jira Server/Data Center 用で、Cloud でもレガシーなレンダラーを使っているフィールドやアプリでは Wiki 記法を使います。

Jira Wiki 記法では { がマクロの開始、[ がリンクの開始を意味するため、通常のテキスト内の {"error": [1]} のような JSON の断片は表示を壊すことがあります。このツールはそれらをバックスラッシュでエスケープします。{noformat} や {code} ブロック内のテキストは、貼り付けたとおりに残されます。