「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の１７日目です。
今回の記事は，Chapter８「テスト実行 ～テストログとインシデントレポートを書こう～」を取り上げます。いつものように読む上で注目して欲しいポイントと補足をします。
※ご注意：本Advent Calendar はあくまで池田の個人企画です。
■テスト実行では実行に加えて記録が重要
勘の良い方だとChapetr８のタイトルを見て気がついたかもしれません。「テストケースを実行しよう」ではなく「テストログとインシデントレポートを書こう」としています。
もちろん実行することは（当たり前かつ）大切でなのですが，テストケースの実行そのものはテスト実装がきちんとなされていれば（よほど実行に専門性が必要な場合でなければ）すんなりと対応できるでしょう。
テスト実行では実行と共に大切な作業として「記録」があります。この重要性に余り目を向けられることがないのですが，直接的な実行と並んで大変重要です。なにせ実行したことを証明するための物だからです。記録を伴わない実行は信用に値されないということを強く認識しておくべきです。このためにタイトルを記録に目が行くように決めてあります。
■テスト実行における記録（ログ）
さて，記録というと何を想像するでしょうか。ここで多くの人は「バグ票」などのインシデントレポートを想像すると思いますが，さらに大切なのはテスト（実行）ログです。バグ票やインシデントレポートはテストログから生み出される物です。
テストログはテストケースがパスするしないにかかわらずに作成される記録です。おそらく多くの現場ではテストログはテストケースリストに合否情報などを付加することで代用していると思いますが，テストログとしては，極めて不十分な情報しか残っていない場合がほとんどです。それは，テスト実行時に詳細に記録として残すべきはバグの情報だけであるという先入観があるからでしょう。しかしながら，例えテストケースをパスしたとしてもその情報は詳細に残しておく必要があります。なぜならば，人の実施することには誤りがつきまとうからです。記録がないとそれに気がつくのは難しいでしょう。また，本当にパスしたかどうか監査やレビューを実施する際に，根拠となる情報が，担当者がパスしたと言っているというレベルでしかないために，脆弱な監査となってしまいます。
■インシデントレポートはテストログから生み出される
さて，テスト実行でのもうひとつの大切な文書としては「インシデントレポート」があります。これについてはあれこれと解説する必要は無いと思いますが，先ほども書いたとおり，インシデントレポートはテストログから起こす，ということを覚えておいて下さい。バグを発見したときに直接インシデントレポートを書くのは危険です（･･･と筆者は考えています）。というのもレポートが脊椎反射的になりがちで，経験として，きちんと分析された情報になりづらいです。今の国内のテストの現状を見ると，開発そのものに慣れていなかったり，テストに精通した人がテストを実行しているわけではないでしょうから，いったんその情報を残して，反芻してもらうということがないと，よくわからないレポートになってしまいます。
インシデントレポートは自身が体験したことを他人に正確に，わかりやすく，シンプルに伝えるべきものです。ですから，一度考えるという段取りを用意しておかないと使えないインシデントレポートを大量生産される事態に陥ります。インシデントレポートにまつわる問題については，テストエンジニアと呼ばれる人々が常に悩みを持ったり研究をしたりしている現状で，とても難しい作業です。ただし，この難しさは世間にはあまり認識されていないように思います。単にＢＴＳを導入すれば良いという問題ではないです。
Chapter８ではこうった難しい問題の入り口について解説をしているという目線で呼んでいただけると違った発見を得られるのではないかと思います。
■おわりに
テスト実行はテスト分析やテスト設計に比較して関心が低いと感じていますが，開発の現状を観察すると，むしろ分析設計という前にまず実行をきちんと改善すべきだと思います。テストログやインシデントレポートはテストに関わらない人達，主に開発者との品質面における情報の直接的なインタフェースです。そのインタフェースをきちんとしないと品質は向上しません。なぜならば品質は開発作業/行為により作り込まれる訳で，テストの作業/行為では作り込まれることはありません。ですからきちんと情報を入力するために，そのログや生み出されるレポートがなんであるか，何のために作るかということを意識していただきたいと思います。