「[When/Where（状態）]→[What（条件）]→[How（手順）]→[be（期待値に反する結果）]」

ここでは不具合の内容が「ざっくりどういった内容なのか」を記載します。

詳細な手順などは後述で別途記載するので、この「概要」では比較的簡易に記載して、まずはどういった不具合内容なのかを読み手に知ってもらう事が目的とします。

チケットを読んだ人が迷わずに現象を再現させるための手順を記載します。

誰でも再現できるように、読む人の前提知識や背景知識がまったくない前提で記載しましょう。

・必要な条件や手順を省略せずに書く

必要な条件や手順を省略せず、1ステップごとに記載します。

目安として、前提知識不要かつチケットを読む人（イメージとして新人）が、記載されている前提と手順を読んだことだけで理解・再現できるくらいに細かく記載します。

省略するか詳細に書くか迷ったならば、詳細に書くほうに倒すほうが良い場合が多いです。


例）
 　NG：ボタンをクリックする
 　OK：注文画面で注文確定ボタンをクリックする

・手順の文章の中に動作は一つ

手順の一文に、動作を一つのみ記載します。
何個も動作があると、再現するひとが手順を抜いてしまう可能性があります。

例）
　NG：配送先に東京都を選択し、ポイントを使うを選択し、ボタンをクリックする
　OK：① 配送先コンボボックスで「東京都」を選択する
　　　  ② ポイントを使うコンボボックスをEnableにする
　　　  ③ 注文ボタンをクリックする

・数値を用いるなどして具体的に記載する

「いつ（タイミング）」「何を」「どうする」を具体的に書きます。数値が記載されているとより良いです。


例）数値を用いた具体的な手順
　※操作にタイミングがある場合。タイミングが不要な場合はNGに書いてある記載で構わないです
　 NG：ブラウザバックしたあと、少したった後にボタンをクリックする
　 OK：ブラウザバックしたら、約5秒後にボタンをクリックする


例）具体的なタイミングを記載した手順
　※操作にタイミングがある場合。タイミングが不要な場合はNGに書いてある記載で構わないです
 　NG：確認ダイアログでOKボタンをクリックする
 　OK：確認ダイアログ内に「Are you OK？」が表示されたら、OKボタンをクリックする

・実施対象を明記する

検査機材やPCなど、手順が複数のデバイスやアプリケーションにまたがっているときは、手順の中に検査機材やPCを明記しましょう。

いろんなデバイスやアプリケーションがあると、どの検査機材のUIやアプリケーションで手順を実行するべきなのか混乱するためです。

また画面名称やUI名称も記載してあるとより良いです。


例）PCとスマホの両方で操作が必要な場合
　NG：① OKボタンをクリックする
　　  　② 表示されたメッセージを確認する
　OK：① スマホに表示された確認ダイアログでOKボタンをクリックする
　  　　② PCのWebブラウザに表示されたメッセージを確認する

検査機材の情報を細かく記載します。

ソフトウェアエンジニアが解析に用いる重要な情報ですので、記載できることは記載しましょう。


　・検査対象ソフトウェアのバージョン・リビジョン・ビルド番号
　特定のバージョン・リビジョン・ビルド番号でのみ発生する現象の特定に有意義な情報になります。

　・評価機材
　機材固有の問題や機材の設定による不具合があるときの分析に使用することがあります。

現象発生時の証拠画像

現象発生時のスクリーンショット・画像・動画を撮影できる場合、撮影したそのファイルをチケットに添付して参照案内すると良いです。

文字だけでは、不具合のイメージが伝わらない場合がありますが、画像などあると現象が伝わりやすくなります。


画像を不具合の発生箇所を赤い丸などで囲い、不具合発生箇所を判別しやすくするとなお良いです。

例外発生などでエラーコードが画面に表示されている場合、その番号とエラーメッセージが映った写真も添付すると良いです。

解析に重要な手がかりとなるエラーコードの情報が正確に設計に伝わるためです。

手順や結果に書ききれない補足情報はすべて結果補足に記載します。


　・根拠となる仕様書の記載

　・同条件である検査機材・PCでの結果

　・他のPCや機体での結果

　・他の状態や条件、設定で確認した結果

　・過去の類似機種の動作

　・不具合チケットを起票した背景