バグレポートを書くにあたっての心構え、フォーマットなどを記述する
開発とともにテスト工程を価値あるものとして進めることを考慮する必要がある
Q. テスト実行において、良いテスターとは？
まず、テスターはどのようなマインドを持つべきかの質問。
ANSWER
1. バグを多く見つけた
2. 誰も見つけられないレアバグを見つけた
3. エンジニアに多くのバグを修正させた
個人的には "3" である
なぜならば、
品質とは、リリースされたサービスがユーザーに満足されることである
↓
ユーザーに影響のあるバグは出さないこと
↓
テスターは開発にバグの重要性を伝え、直すように働きかけないといけない
個人的に、このようなマインドをもってテスト実行、バグレポートを開発に出す必要がある。
テスターは品質の状態を伝えるのが仕事であり、品質を作り上げるのはエンジニアであるからである。
バグレポートでの出来事（たぶんフィクションです）
バグレポートの必要要素
バグレポートをエンジニアに報告するとき、エンジニアが短時間で状況を把握し、そのバグを直すように働きかけ、バグ修正に必要な情報がそろっている内容であることが望まれる。
| 1.再現（発生頻度） | バグがどの確率で発生するかを示す。（５回中５回発生するのか、まれに発生するのか） エンジニアがバグの再現をするときに、発生頻度が低い場合バグ出ないと誤判断してしまう。 |
|---|---|
| 2.分離（原因特定） | 一つのバグに対しテスト条件を変えてテストする。 そこからバグの原因につながるような情報（限られた条件で発生する等）を導き出す |
| 3.一般化（影響範囲） | 一つのバグに対して類似した処理が同様のバグを含んでいないかを確認する |
| 4.比較 | 旧バージョンのシステム、別の環境（iOS、Android等）で見つかったバグの再現性を確認する 今回のバグがデグレ、特定環境でのみ起きる、既存バグであるかを確認することで、開発の対応判断の助けになる |
| 5.要約 | バグの内容を簡潔に、いろいろなステークホルダに理解できるようにまとめる。 バグ報告、分析等を行いやすくする |
| 6.凝縮・明確化 | 不必要な情報、あいまいな情報を削る。 報告されたバグの内容から発散しないように、誤解を招かないようにする |
| 7.中立化 | 中立の立場からバグを客観的に報告する。 プログラマ、システムの実装、コーディングの非難、バグ改修内容の提案などは避ける |
| 8.プライオリティ | バグの重要性、優先度を定義する。 このバグにより、ほかのテスト活動に影響の有無を伝える（例えば、これがブロッカーとなりほかのテストが実行できない等） また、このバグによりビジネスリスクがどの程度あるかを伝える |
バグレポート
バグレポートフォーマットのサンプル
【Priority / 優先度・重要度】
【Issue / 事象】
【Expected value / 期待値】
【How to repro / 操作手順】
【Test date / テストデータ】
【Frequency / 発生頻度】
【Environment / 環境】
【Discovery time / 発見時刻】
【Discoverer / 発見者】
【Remarks / 備考】
実際のバグレポートのサンプル
