【今回の登場人物】
- 大塚先輩：
- 入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で、
暇さえあれば写真を撮りに出かける。 - 中山君：
- 入社5年目。本連載の主人公。入社以来ソフトウェアテスト一筋で経験を積んできた。そろそろ大きい仕事をしたいと考えている。
- 小川君：
- 入社2年目。新人研修後、
その有望さから半年間顧客先に常駐。テスト業務の他、 設計作業も経験を積んできた。趣味はベースで、 定期的に仲間とライブを行うなど仕事と趣味を両立している。
状況説明
いよいよテスト実行の工程に入り、
中山君が頭を抱えているところに、
大塚先輩：- やはり混乱してるみたいだね。
中山君：- どうもすみません。今度こそはうまくやろうと思っていたんですが…。
アドバイスをもらうため、
ようやく
- 大塚先輩：
- …なるほど。こりゃまたいろいろとあるなぁ。
大塚先輩：- じゃ、
ひとつずつ指摘をしていこうか。
テストの実行結果とバグの情報は適切に記録しよう
- 大塚先輩：
- 小川君のテスト実行結果とインシデントレポートを見てみよう。
大塚先輩：- 小川君、
君はフォーマットがなかったから自分なりに作ってみたと言っていたね。 
小川君：- はい、
特に指示されませんでしたので、 自分なりにやりました。 - 大塚先輩：
- まず、
それが1つめの失敗だ。フォーマットのあるなしは個人が勝手に判断すべきではない。まずは責任者、 今回は中山君に確認を取るべきだった。 - 大塚先輩：
- 中身を見てみようか。まず目につくのは、
実行者はいいとして、 観察者がないことだね。 
小川君：- 観察者ですか……。今回は個別にテストを実行することと指示が出ていましたので、
そこは考えていませんでした。 - 大塚先輩：
- インシデントレポートの文章の書き方についても2～3ある。情報は事実を客観的に書くべきで、
そこに自分の私情を入れてはならない。見直してごらん、 気になるところはたくさんあるはずだよ。 
小川君：- なるほど… 確かにそう。
- 大塚先輩：
- こういったことを防ぐためにはどうすればいいかな？ 中山君。
- 中山君：
- レビュー… ですか？
- 大塚先輩：
- そうだ。何か成果物がある場合、
できるだけリーダは目を通すことが必要だ。特に公式文書となりえるものは、 だ。
実行結果のログとインシデントレポートは情報の源
テストケースの実行結果のログやインシデントレポートの中身は、
また、
なお、
テスト実行にはできる限り観察者／確認者を付ける
小川君の作ったテスト実行結果のログを見ると、
テスト実行者も人間ですから、
また、
インシデントレポートは人のことを考えたレポートに
小川君が作成したインシデントレポートを見ますと、
インシデントレポートの書き方の詳細については本稿では取り扱いませんが、
インシデントレポートの記述レベルを合わせるために
今回のケースでは、
バグの状態を定義しよう
- 大塚先輩：
- ここにあるインシデントレポートの今の状態はどうなっているの？
- 中山君：
- 状態ですか……？
- 大塚先輩：
- このままファイリングされるわけではないよね。どうするんだ。
- 中山君：
- 開発者にバグを直してもらいますので、
開発者に渡します。 - 大塚先輩：
- 直してもらったらどうなるんだ。
- 中山君：
- 再テストします。
- 大塚先輩：
- この流れの中でバグの状態は変わっているのはわかるだろう。
- 中山君：
- はい。
- 大塚先輩：
- うちの会社では、
バグの状態はあらかじめ決まっているんだ。品質管理規程を調べておかなきゃ駄目だよ。
バグの状態を確認しよう
インシデントレポートをただ書けばよいというものではありません。バグが除去されたことを確認するまで、
バグの状態は、
- インシデントレポートを書いたタイミングで
「Open」 - バグを修正する担当者をアサインしたタイミングで
「Assigned」 - バグを修正したタイミングで
「Resolved」 - 修正が正しいことを確認したタイミングで
「Verified」 - 再テストが完了したことを確認したタイミングで
「Closed」
しかし、
バグ管理のワークフローを確認しよう
- 大塚先輩：
- ところで、
このインシデントレポートはどうするつもりだったんだい。 
中山君：- はい、
いつものように開発者に渡そうと思っていました。 - 大塚先輩：
- 開発チームとどのようなやり取りをするか合意していたかい？
- 中山君：
- えっ、
開発者にインシデントレポートを渡すのは当たり前だと思っていましたが。 - 大塚先輩：
- どのようなタイミングで渡すんだい？
- 中山君：
- インシデントレポートを書いたら直ぐに渡そうと思っていました。
- 大塚先輩：
- 開発チームもそう思っているの？
中山君：- ……。
- 大塚先輩：
- そのレポートは誰に渡すんだい？ 開発チームだったら誰でも良いわけではないよね。
バグ管理のワークフローを確認しよう
インシデントレポートを開発者に渡し、
「テスト実行」
多くの組織では、
BTSを用意しておこう
バグやインシデントの管理はそのステータスや情報の管理はExcelベースで行うとかなり大変です。そこで利用をおすすめするのがBTS
今回は小川君のまじめさと機転故にいろいろとアドバイスをもらうことになってしまいました。皆さんも自分を振り返ってみてはいかがでしょうか。
次回は千秋ちゃんと中山君へのアドバイスです。
参考：インシデントレポートに記入すべき内容
インシデントレポートに、
以下の詳細情報を記入する。
- ログの作成日付、
作成した組織、 作成者 - 期待した結果と実際の結果
- テストアイテム
（構成アイテム） および環境の識別 - インシデントが発生したソフトウェアやシステムのライフサイクルプロセス
- 再現および解決を可能にするインシデントの記述、
たとえばログ、 データベースのダンプ、 スクリーンショットなど - 対応するステークホルダに与えるインパクトの範囲や程度
- システムに与えるインパクト
- 修正の緊急度／
優先順位 - インシデントのステータス
（例えば、 オープン、 次バージョンへ延期、 重複、 修正待ち、 再テスト待ち、 解決済みなど） - 結論、
アドバイス、 承認 - 外部との問題。例えば、
インシデントを修正することで他の分野に及ぼす影響 - 修正履歴。例えば、
インシデントを抽出し、 修正し、 修正が正しいことを確認する時にプロジェクトチームのメンバが実施した作業など - 問題を摘出したテストケースの仕様のID番号など参照情報