1．概要

IEEE829から学ぶテストドキュメントの第6回目として、テストログについて記載いたします。

テストログを一言でいうと、テスト中に起きた出来事をまとめたドキュメント、になります。
ただ、テスト中に起きた出来事はテストケースに記載することが多く、テストログという別のドキュメントを作成することはほとんどありません。
（そのため、テストケースとかぶる項目が多いです…）

しかしながら、例えば自動テストを実施した場合、その履歴をテストログということがあります。そのため、現場ではテストログ　＝　自動テストの結果　となっていることもあります。

2．IEEE829のテストログについて

以下がIEEE829に記載されているテストログに記載する項目となります

テストログ識別番号
説明
アクティビティとイベントの記述

テストログは「アクティビティとイベントの記述」さえ記載されていればよく、それ以外は特に記載しなければならない項目はありません。

ただ、IEEE829のテストログは項目が大雑把ですので、詳細は事象で詳しく記載いたします。

3．アクティビティとイベントの記述について

テストログに記載するアクティビティとイベントは、「ログを残すことで後々役に立つこと」、が記載されていれば問題ありません。

例として、

不具合の原因を追究しやすくなるような情報
テスト完了後の振り返り会で役立つ情報
テスト実施管理に使える情報

などが該当します。そのため、ログを残しても誰も見ない、使わないのであれば各情報を記載する必要はありません。

テストログとして残すべき項目

上記を詳細にまとめると、以下のような項目がログに記載した方がいい内容になります。

テスト実施順序

テストケースに記載されている実施手順が該当。自動テストなどではテストしたコードの履歴でもいい
⇒不具合が発見された際、再現確認や原因追及のため利用する

テストケースの説明

順序だけでは何をテストしたかわからない場合、説明文を記載する
⇒どんなテストを実施したのか確認の際に利用（管理もしくは振り返りに使うこともある）

テスト結果

テストを実施した結果、どのような結果となったか記載する。
テストの網羅率や表示されたエラー内容（エラーコード、エラーメッセージ）なども該当する
⇒テストケースに誤りがなかったか、別の問題が起きていないか確認ため利用（主に管理）

テスト実施中に起きた問題ある事象（「備考欄」に記載することが多い）

テスト実施中に気になる動作があればそれを記載する。（特に非機能要件が該当しやすい）
例えば、
・ボタンを押してからの動作が遅く感じる
・特定の環境だけテスト結果が異なる
・ボタン押下が多く使いづらい
・データを保存すると仕様にない部分も変更されている…など
⇒テストケース外の問題を把握するために記載する（主に管理）

日付、開始時間、終了時間

テストを行った日程を記載する
⇒のちにテスト実施者の生産性を算出したり、スケジュール管理に利用したりする。

テスト環境

テストを実施した際の環境を記載する（特に不具合の影響範囲を特定できる情報があるといい）
・テスト対象システムのバーション
・テストしたブラウザ名、ブラウザのバージョン
・OSの名前バージョン　など
⇒不具合の原因追及の際に利用します

上に記載した項目を全て利用する必要はなく、ログとして残しておいた方がいいものだけ
を決めて記載すればいいです。

4．まとめ

テストログは、テスト中に起きた出来事をまとめたドキュメント、です。ただ、上記はテストケースに記載する項目とかぶっているので、必ずしも作成しなければならないドキュメントではありません。

そのため、ログとして残した置いた方がいい情報を決めてテストログをどう使うか、を決めた上で必要な項目を検討した方がいいと思います。