はじめに

テスト自動化エンジニアのシラバスを再度読み直し、各章をDailyで読めるようにしてみた

6.1 Collection, Analysis and Reporting of Test Automation Data を今回は翻訳・解説する

テスト自動化システム(TAS)やテスト対象システム(SUT)では、プロダクト品質やテスト自動化品質、効果などを推し量るための情報ログを多く持っている。
これら情報を収集し、分析することで、今後の開発・品質活動に役立てることができる。

データの収集

テスト自動化システム(TAS)のログ

TASが残すログ情報として、以下のようなものがある

テスト実行の開始と終了時間 : テストの実行時間を把握し、パフォーマンスを評価や、不具合の原因調査に使われる
テスト実行結果のステータス : テストケースが成功、失敗、もしくは自動化（TAS)の失敗（不具合）かを記録。TASの失敗として、自動化スクリプトの不具合や、環境不安定など、SUTの不具合以外で失敗したものが該当する
詳細なテストログ : テストステップごとのログや、重要なイベントのタイムスタンプなど。不具合分析に重要な情報である
SUTの動的情報：サードパーティツールなどで取得した、メモリリークなど動的情報。不具合原因の特定に使う
実行回数 : 信頼性テストやストレステストのように多くのテストが行われるとき、何回実行されたかのカウンターを記録する
ランダム要素：ランダムパラメータや状態遷移テストのランダムテストステップなど、ランダムな番号や選択肢。分析に、その時に使ったテストデータを特定する必要がある
テストステップ : テストケースで実行されたすべてのアクションを記録し、再現・確認テストで活用する。これは、特定された失敗を再現し、追加情報を取得するのに役立つ。
スクリーンショット : テスト実行中の画面キャプチャを保存し、問題分析に活用
エラー情報の詳細記録 : テスト失敗時のエラーメッセージ、スタックトレース、クラッシュダンプなど
色 : 色でステータスを表現すると、直感的に判別できる。例えば、欠陥情報を赤で表示し、進行状況を緑で表示する。

テスト対象システム(SUT)のログ

SUT側で残すログで不具合分析に役立つものとして、以下のようなログがある

欠陥分析のためのログ情報 : 日付と時刻のスタンプ、欠陥の発生場所、エラーメッセージなど
システム起動時のログ記録 : システムの起動時の、ソフトウェア/ファームウェアのバージョン、SUTの構成、オペレーティングシステムの構成などの構成情報
テストログとSUTログの同期 : 双方のログが同期できるようにしておく。テスト自動化により、SUTログを簡単に検索できるようになる。TASのテストログで特定された障害は、SUTのログでも簡単に特定でき、その逆も同様です。

TAS、SUTのデータ分析

テスト実行後、SUTとTASの両方における潜在的な障害を特定するために、テスト結果を分析する。

失敗分析の手順は一般的に以下のとおりである。

過去のテスト結果の確認
　同じ失敗が以前のテスト実行でも発生していないか確認。SUTまたはTASの既知の欠陥である可能性がある。TASのテストケースの過去のテスト結果をログを残しておくと良い
失敗したテストケースの特定
失敗したテストケースを特定する。テストケースのIDやテスト管理システムの情報を参照することで、失敗したテストケースを特定できます。
失敗ステップの特定
テストケースのどのステップで失敗が発生したかを特定する。
SUTの状態の分析
テストログやスクリーンショット、APIログ、ネットワークログなどを使用して、SUTの状態が期待どおりであったかどうかを確認する。
欠陥の報告
SUTの状態が予想と異なる場合、欠陥管理システムに欠陥を報告します。欠陥の情報を詳細に記録し、ログを添付します。

特殊な状況として、以下のようなこともある

偽陰性
テスト結果が失敗であるが、SUTの実際値と期待値が一致することがある。
この場合、TASが修正すべき不具合、もしくは見えない不一致が存在する可能性がある
環境問題
テスト実施中、テスト環境が全部、もしくは一部が利用不可能の時である。
この場合、全てのテストケースが同じ欠陥で失敗するか、一部システムダウンで見かけ上の失敗するかである。
SUTログを確認して、テスト実行時にテスト環境の障害が発生していないかを確認する。

テストレポート

テスト結果をわかりやすくまとめたレポートを作成し、関係者に公開する。

レポートの内容

テストの概要 : テストの目的、範囲、実行環境など
テスト結果 : テストケースの成功率、失敗率、実行時間などの統計情報
失敗したテストケース : 失敗したテストケースの詳細、原因分析、対応策
トレンド分析 : 過去のテスト結果との比較、問題の傾向の把握
改善提案 : テスト自動化の改善点や、SUTの品質向上のための提案

レポートの公開方法

メール配信 : 関係者にメールでレポートを送信
ウェブサイト公開 : テストレポートをウェブサイトに公開
テスト管理ツールで連携 : テスト管理ツールにレポートを統合し、一元管理

テストレポートの対象者と内容

テストレポートは、プロジェクトに関わる様々なステークホルダーに共有されるべきです。

主な対象者

経営層 : ソリューションアーキテクト、プロジェクト/デリバリーマネージャー、プログラムマネージャー、テストマネージャー、テストディレクターなど
運用担当者 : プロダクトオーナー/マネージャー、ビジネス代表者、ビジネスアナリストなど
技術担当者 : チームリーダー、スクラムマスター、ウェブ管理者、データベース開発者/管理者、テストリーダー、TAE、テスター、開発者など

レポートの内容と詳細レベルは、読み手に合わせて調整する必要がある。

経営層 : テストの全体的な成功率、失敗率、トレンド、リスクなどの高レベルな情報
運用担当者 : 製品使用に関する指標（例えば、ユーザーの行動パターン、エラー率）
技術担当者 : テストケースの詳細、エラーログ、デバッグ情報などの低レベルな詳細情報

ダッシュボード

現代のテスト自動化ツールは、ダッシュボード機能を備え、視覚的にわかりやすいレポートを提供します。これにより、テスト結果を詳細に分析し、全体的な傾向を把握しやすくなる。

ダッシュボードのメリット

多様なデータの集約: パイプライン実行ログ、プロジェクト管理ツール、コードリポジトリなど、様々なソースからデータを収集し、一元管理できる
視覚化による理解促進: グラフやチャートを用いて、テスト結果を視覚的に表現することで、複雑なデータを簡単に理解できる
トレンド分析: 過去のテスト結果と比較することで、テストの成功率や失敗率の推移、欠陥の発生傾向などを把握し、問題の早期発見に役立つ

ダッシュボードができること

欠陥のクラスタリング: 似たような原因で発生した欠陥をグループ化し、分析を効率化
テスト環境への影響分析: 特定のテスト環境での欠陥発生率の変化の分析
SUTのパフォーマンス評価: システムのパフォーマンス低下を検知し、原因の特定
ビルドの安定性評価: ビルドの品質を評価し、問題のあるビルドの特定

テストログの活用

テストログを有効に活用することで、問題の分析と解決を効率化できる。

テスト実行の再現　: テストログを分析することで、テスト実行を再現し、問題の原因を特定できる。
障害の特定 : テストログからエラーメッセージやスタックトレースを抽出し、障害の原因を特定できる。
パフォーマンス分析 : テストログからパフォーマンス情報を抽出し、ボトルネックを特定できる。

AI/MLによるテストログ分析

近年、AI/MLを活用したテストログ分析が注目されています。AI/MLにより、大量のテストログから自動的にパターンを見つけ、問題を検出することが容易になっている。

例えば、以下のような分析が可能になる

異常検知 : テスト結果の異常な変化を検出
根本原因分析 : 障害の原因を自動的に特定
テストケースの自動生成 : テストケースの自動生成を支援