【今回の登場人物】
- 大塚先輩：
- 入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で，暇さえあれば写真を撮りに出かける。
- 中山君：
- 入社5年目。本連載の主人公。入社以来ソフトウェアテスト一筋で経験を積んできた。そろそろ大きい仕事をしたいと考えている。
- 小川君：
- 入社2年目。新人研修後，その有望さから半年間顧客先に常駐。テスト業務の他，設計作業も経験を積んできた。趣味はベースで，定期的に仲間とライブを行うなど仕事と趣味を両立している。
状況説明
いよいよテスト実行の工程に入り，まずはそれぞれがテスト実装で分担した範囲のテストケースを実行することとなりました。15時になりお互いの状況を確認するために会議室に集合した3人でしたが，問題が山積みでした。
中山君が頭を抱えているところに，他のプロジェクトに行ったはずの大塚先輩が顔を出しました。
大塚先輩：- やはり混乱してるみたいだね。
中山君：- どうもすみません。今度こそはうまくやろうと思っていたんですが…。
アドバイスをもらうため，中山君をはじめ小川君や千秋ちゃんはそれぞれの状況を大塚先輩に報告することにしました。
ようやく「何か重大な問題が起きた場合には早期にエスカレーションを行う」ということがわかってきた中山君です。
- 大塚先輩：
- …なるほど。こりゃまたいろいろとあるなぁ。
大塚先輩：- じゃ，ひとつずつ指摘をしていこうか。
テストの実行結果とバグの情報は適切に記録しよう
- 大塚先輩：
- 小川君のテスト実行結果とインシデントレポートを見てみよう。
大塚先輩：- 小川君，君はフォーマットがなかったから自分なりに作ってみたと言っていたね。
小川君：- はい，特に指示されませんでしたので，自分なりにやりました。
- 大塚先輩：
- まず，それが1つめの失敗だ。フォーマットのあるなしは個人が勝手に判断すべきではない。まずは責任者，今回は中山君に確認を取るべきだった。
- 大塚先輩：
- 中身を見てみようか。まず目につくのは，実行者はいいとして，観察者がないことだね。
小川君：- 観察者ですか……。今回は個別にテストを実行することと指示が出ていましたので，そこは考えていませんでした。
- 大塚先輩：
- インシデントレポートの文章の書き方についても2～3ある。情報は事実を客観的に書くべきで，そこに自分の私情を入れてはならない。見直してごらん，気になるところはたくさんあるはずだよ。
小川君：- なるほど… 確かにそう。
- 大塚先輩：
- こういったことを防ぐためにはどうすればいいかな？ 中山君。
- 中山君：
- レビュー… ですか？
- 大塚先輩：
- そうだ。何か成果物がある場合，できるだけリーダは目を通すことが必要だ。特に公式文書となりえるものは，だ。
実行結果のログとインシデントレポートは情報の源
テストケースの実行結果のログやインシデントレポートの中身は，品質状況を測るための情報として取り扱われたり，バグの調査の情報となります。長年組織で改善されながらできあがったそれらのフォーマットは，これらの情報を記録し損なわないようにするためにできるだけ利用することを心がけましょう。
また，場合によっては社内の開発プロセスにおいて使用が義務づけられている場合があります。大塚先輩は小川君に対し責任者に確認を取るようにとアドバイスをしていますが，本来ならば中山君がフォーマットを提供し，記述内容の詳細について説明をしなければなりません。
なお，インシデントレポートに記述すべき項目として『ISTQBテスト技術者資格制度Foundation Levelシラバス』で述べていることを，この記事の最後に示します。
テスト実行にはできる限り観察者／確認者を付ける
小川君の作ったテスト実行結果のログを見ると，実行者の欄はありますが，観察者／確認者の欄がありません。この場合の観察者／確認者とは，テスト実行者が確実にテストケースを手順に沿って実行しているかを確認します。
テスト実行者も人間ですから，ヒューマンエラーの混入を根絶するのは困難です。観察者／確認者を置くことで，可能なかぎりこのヒューマンエラーが混入することを防ぎます。
また，そのテストケースが実行されたとき，それが一人の目で確認されたのか複数の目で確認されたのかは，後々テスト結果を評価する場合の判断基準の1つになります。現実としてペア以上でテストケースを実行していくのは難しい場合もありますが，そこはそのテストやテストケースの重要度によって判断をしましょう。
インシデントレポートは人のことを考えたレポートに
小川君が作成したインシデントレポートを見ますと，小川君個人の見解を見つけることができます。インシデントレポートは事実を客観的に書き，個人の見解は必要ありません。個人の見解は事実を惑わす危険性があるほか，書きようによってはインシデントレポートを受け取る設計者などの心証を悪くしてしまう場合があります。
インシデントレポートの書き方の詳細については本稿では取り扱いませんが，「誰が何のために読むのに作成されるのか」を意識しておかねばなりません。そしてその意識の情勢は中山君が言ったとおりレビューなどを通して行います。リーダはインシデントレポートのように他部門に送付される文書についてはできるだけレビューを行ってその記述内容の品質を確認するようにしましょう。
インシデントレポートの記述レベルを合わせるために
今回のケースでは，人数が少ないためお互いにインシデントレポートをレビューし合えば，記述レベルを揃えることができます。しかし，大規模開発の場合はどうでしょうか。あらかじめインシデントレポートの書き方や起票の基準を学ばなければ，つまり，一人一人が好き勝手にインシデントレポートを発行してしまったら，プロジェクトは混乱してしまいます。ある人がバグ一件だと判断しインシデントレポートを一枚発行したとしても，別の人はバグ十件だと判断することもあります。これは管理する立場としては，大変困った状況になります。
