テスト実行の記録と報告書の作成

ようやくテストを実行できるようになりました。テストを実行したら実行結果が合格か不合格かの記録をしていきますが、この作業はそう単純ではありません。合格か不合格かという直接的な結果だけではなく、それ以外にもさまざまな情報を記録する必要があるのです。また、すべてのテストケースを実行し終えたら、記録した情報を文書としてまとめ、報告を行わなければいけません。報告までちゃんと行って、はじめてテストという仕事が完了するのです。

A君はテストケースの合否だけしか記録していなかったので、K先輩に対して報告をすることができませんでした。今回は先輩だからまだいいものの、これがお客様だった場合どうなるでしょうか。自分が説明できない仕事をしていたとしたら、きっと不信感をもたれてしまうでしょう。

第5回の今回は、おろそかにしがちなテスト実行時の記録とテスト報告について、注意すべき事柄を説明します。

テスト実行を記録する目的

最初に新人の皆さんに考えていただきたいことがあります。

筆者らの答えは、一番最後に提示します。なぜ記録するのか？ 報告書はなぜ書くのか？ を頭に置きつつ、ここからの記事を読んでください。

テスト実行時にはどのような情報を記録するか

テスト実行時には、テストケースの実行結果が合格か不合格かを記録していきますが、記録する情報はそれだけではありません。代表的なものを以下に挙げます。

（1）実行日時

そのテストケースがいつ実行されたかを記録します。

ただ、これだけですと、実行に着手した日なのか実行が終わった日なのか判別がつかないため、通常、実行開始日時と実行終了日時に分けて記録されます。

（2）担当者名

誰がテストを実行したのかを記録します。この際、複数人で実行した場合は、全ての名前を記録します。

このテスト担当者も、テスト環境を操作する人とテスト結果を検証する人が別れている場合には、それぞれ役割毎に名前を記録します。

（3）実行手順

テスト環境を操作した手順を記録します。

事前にテストデータを用意したり、テスト環境を特殊な状態においてからテストを実行する場合には、その準備に必要な手順も記録します。

（4）テストケースの実行結果

テストケースの実行結果を記録します。

合格、不合格のほか、条件付合格、条件付不合格という結果もあります。これについては、後ほど解説します。

（5）バグの情報

テストケースが不合格、つまりバグがあった場合、その情報を記録します。

この記録は通常バグ票と呼ばれるものとして記録され、その情報を元に開発者がデバッグを行います。

（6）その他、気になった点

上記4つに該当しないことでも、気がついたことはすべて書き残しておかねばなりません。

どんなささいなことでも、おかしいなと思ったときには記録してください。それがバグの影であることがあります。

この5つは本当に最低限の情報ですが、しっかりと記録する必要があります。この中で新人さんにとくに気をつけて記録してほしいのは（4）と（5）です。この（4）と（5）は関連性があります。（⁠4）が不合格であった場合、その根拠となる情報が（5）として記録されるからです。つまり、これらの情報が不足していると、バグの解析が困難になります。最悪、再度テストケースを実行してバグを再現させ情報を収集しなおす必要があり、大きな手間となってしまいます。

テストケースの実行結果は合格と不合格の2値とはかぎらない

テストケースを実行し、合格、不合格が確定したら、テストケース実行結果表の合格欄に結果を記入しますが、これは合格と不合格のに２値であるとは限りません。以下に値を挙げてみます。

つまり、条件付合格というような状態が存在するということです。

新人の皆さんは「テストケースの実行結果は2値ではない」ということをしっかりと理解してください。条件付合格のような状態もあるということです。上記であれば、Ⅱ、Ⅲ、Ⅴの場合は、気になるところや想定しない別のバグがヒットしたことについて、それを付加情報として記録しておく必要があります。

もし、職場で使用している書式のテンプレートが、合格／不合格の2値での記入しか許さない場合、備考欄などを使って詳細に書いておきましょう。

バグ票を書こう

バグの情報はバグ票として作成しなければならないと説明しました。

このバグ票は、インシデントログとかインシデントレポートとか呼ばれることがあります。インシデントとは簡単に書くと、プロジェクトの中で調査が必要なもののことです。この場合、バグは調査が必要なものですから、インシデントに相当します。インシデントログやインシデントレポートは、組織によってバグ票、障害管理票、故障処理票と呼ばれることもあります。本記事ではなじみのある用語としてバグ票という呼び名を使って話を進めます。

このバグ票に書かれる代表的な情報を以下に列挙します。

• 発見日
• 発見者
• 実行したテストケースのID
• バグの概要
• バグの詳細
• バグの重要度
• バグ修正の緊急度
• バグの再現手順
• バグが発見されたときの環境（ハード／ソフトなど）
• 想定されるユーザへの影響

このような情報を“⁠詳細に⁠”記録する必要があります。これらが曖昧で適当に記録されていると、設計者がデバッグを行うときに情報が足りないという状況になります。発見したバグの情報をどれだけ注意深く観察し、環境含めて写し取れるかもテスト担当者の大事なスキルです。

このバグ票は、「⁠自分以外の他人が見る」ということをくれぐれも意識して作成する必要があります。

上記以外にも、発見されたソフトウェアのバージョンや、発見したテスト工程、バグの分類などさまざまな情報が記録されます。

テスト終了時には報告書が作成されなければならない

ひとつの仕事の終わりには、必ず“⁠終了報告⁠”を行わなければなりません。そして、それはソフトウェアテストにおいても例外ではありません。テストも終了したら、それまで作成したドキュメントや得られた情報からテスト報告書を作成する必要があります。

が、まず、ここで絶対にやってはいけないことを書いておきます。

「テスト実行結果ログの表紙をテスト報告書と書きなおす」

現場によっては、テスト項目書の表紙だけを差し替えることで、報告書とする場合があるようです。もし、こういったことが行われていた場合、テストの現場としては非常に危険な状況といわざるを得ません。なぜなら、表紙だけを差し替えるということは、実行結果について十分な分析や吟味を行わないということだからです。

実行結果のログは報告書と同じものではありません。作成される目的が根本的に異なります。これは肝に銘じてください。

何を報告すべきか

では報告書にはどのようなことが書かれるべきでしょうか？ 最低限、以下のようなものを押さえておきましょう。

• テスト報告書ID
• テストの目的と方針
• テスト対象の情報
• テスト結果（合格数/不合格数）
• 未解決のバグ情報のリスト
• テスト結果の分析結果
• テスト担当者の見解
• このテストに関係する人と連絡先
• 関連するドキュメントのリスト

報告書を書くための情報源は、今までに作成したドキュメントや記録です。情報をまとめるという性格が強い作業なのでそれほど苦労はしないと思いますが、「⁠分析結果」や「テスト担当者の見解」は新人さんには難しいかと思います。慣れないうちは、周りの先輩に見てもらいながら作成すると良いでしょう。

さて、この報告書は事実を脚色せずにありのままに書く必要があります。また、冒頭のシチュエーションではM先輩が報告相手ということになりますが、M先輩が読んで理解できるものにしなければなりません。前もってM先輩にどのような報告を行えばよいか聞いておくのも良いでしょう。

終わりに

テスト実行を記録する目的

さて、ここまでお読みになって、次の質問に答えられるようになっているでしょうか？

今やっているテストの目的は、バグを見つけるためです。テストケースを実行して不合格であることがわかっただけでは、バグは見つかりません。「⁠どんな操作をしたのか」これが分からなければ、バグがどこに潜んでいるのかを探せなくなってしまいます。また、同じテストケースを実行してバグが再現できなければなりません。操作手順が変わることによって、バグが再現できないこともあります。

では、報告書はなぜ書くのでしょうか？ この答えは新人の皆さんが所属している組織によって答えが変わるでしょう。一度、なぜ書くのかを先輩に聞いてみましょう。1つの答えとしては、「⁠報告書は品質管理に使用する」というものです。

まとめ

テストはその終わりに報告が行わなければなりません。そしてそのためには詳細に情報が記録されている必要があります。これらがしっかりと行われていないと、設計者に適切にバグ情報を伝えられずに迷惑をかけてしまいます。

また、テスト結果の報告先の人が、このテストが適切に行われたのかどうか判断することができません。終了報告がきちんとできることは、社会人としても基本的なことなので、なにごともやりっぱなしにせず、きちんと行うように心がけましょう。さらに、何を報告すべきなのかをよく考えることも心がけることが大切です。

さて、これでテストを仕事として与えられてから報告するところまで、ひととおり解説しました。次回は、第1回から第5回までを振り返ります。そして、今後、さらにスキルアップするためにはどうすればよいかについて解説を行います。