趣旨
ここでは、ISTQBにて提供されている"Test Automation Engineer" Syllabusを自分なりに解釈（そのままの翻訳もあり）したものである
そのため、実際の試験と相違がある場合もありますのでご注意
原本↓
https://www.istqb.org/downloads/category/48-advanced-level-test-automation-engineer-documents.html
5 Test Automation Reporting and Metrics
5.1 Selection of TAS Metrics
テスト自動化戦略、効果や効率をモニタリングするためのメトリックスに関するものである。テスト対象のモリタニングに必要なメトリックスとは異なる。テスト自動化のゴールへの進捗や変更の影響度を測る
テスト自動化のメトリックスはexternalとinternalの２つに分類される。
external metrics : テスト自動化がほかの活動へ与える影響度を測る
internal metrics : テスト自動化の効果、効率を測る
テスト自動化メトリックスには以下のようなものを含む
External metrics
- 自動化の恩恵
- テスト自動化を構築する労力
- テスト自動化インシデントを分析する労力
- テスト自動化を維持する労力
- 欠陥による失敗率
- テスト自動化を実行する時間
- テスト自動化のテストケース数
- テスト結果の成功、失敗数
- 偽陽性(false-fail / false-positive)、偽陰性（false-pass / false-negative）の数
- コードカバレッジ
Internal metrics
- ツールスクリプティングメトリックス
- 自動化コードの欠陥密度
- 自動化のスピード、効率
上記を細かく説明する
External-1 Automation benefits
テスト自動化の恩恵を測定しレポートすることは重要である。これにより、コストの見える化ができる。コストはよく見えるが、恩恵を感じにくい。
典型的なものとして、時間効率、テストカバレッジ等がある
測定可能なものとして以下のものがある。
- マニュアルテストの労力を抑えた時間
- リグレッションテストの実行時間削減
- テスト実行の追加サイクル数
- 追加テストの数
- 全体テストケースのテスト自動化のカバレッジ
- カバレッジの増加傾向
- 早くバグを見つけた数
- マニュアルで見つからなかったバグの数
テスト自動化は一般的に、マニュアルテストの労力を抑える。それによりほかの知的作業を行うことができる。追加テストによって見つかった欠陥はテスト自動化の間接的な恩恵でもある。
Effort to build automated tests
テスト自動化構築の工数はキーコストの一つである。
しばしばマニュアルテストより工数が大きくなり、テスト自動化の拡大に障害になる。
テスト自動化実装コストはテストに依存する一方、スクリプティングアプローチ、ツールの親和性、環境、スキル等のほかの要素も影響がある。
大きく、複雑になるテストはシンプルなテストに比べ時間がかかるため、テスト自動化にかけるコストは構築時間の平均がベースになる。これは特定のテストの平均コストからも計算される。もしくは、マニュアルテストの工数をベースにするときもある
Effort to analyze SUT failures
テスト自動化より発見されたテスト対象の欠陥の分析はマニュアルのテストより複雑になりうる。なぜなら、欠陥につながるイベントはテスターがテストすることで見つかる。これは平均欠陥テストケースであらわされる、もしくはEMTE(Equivalent Manual Test Effort)の要素であらわされる。
テスト対象、自動化の実行可能なロギングは欠陥分析において重要なロールである。
ロギングは十分な情報を提供し、効率的な分析をできるようにする
重要なロギングの要素は以下の通り
- テスト対象、自動化のロギングは同期するべし
- テスト自動化は期待値と実際のふるまいをロギングすべし
- テスト自動化は実行をロギングすべし
テスト対象はすべてのアクションをロギングすべしである
Effort to maintain automated tests
テスト対象とテスト自動化を同期し続ける保守工数は重要で、自動化で得られるメリットを上回る場合がある。これが多くのテスト自動化の失敗を引き起こしている。これら工数を抑えたりすることが重要である。
保守工数の測定は各新規リリースにて求められる。テスト自動化の更新やEMTEの平均であらわされる。
保守工数がわかると、この情報が重要な機能の実装、欠陥を修正するかどうかの判断する重要な役割になる。
Ratio of failures to defects
テスト自動化で起きる共通の問題は、同一原因での失敗である。テストの目的は欠陥を明らかにする一方、同じ欠陥を何度も見つけるのは時間の無駄である。テスト自動化では特に各欠陥の分析が重要になる。欠陥の検出数がどこに問題があるかを指し示すものになる。テスト自動化の設計がキーになる
Time to execute automated tests
テスト自動化の実行時間が簡単なメトリックスになる。
テスト自動化の数が増えるにつれ、このメトリックスは重要になる
Number of automated test cases
このメトリックスはテスト自動化プロジェクトの進捗を示す。しかし、この数が多くの意味ある情報を明らかにするものではないことを考慮する必要がある。
Number of pass and fail results
どれくらいテスト自動化がパスし、失敗したかを示す共通メトリックスである。失敗した時、それがテスト対象に欠陥があるのか、環境や自動化自身といった他の原因であるかを分析する必要がある
Number of false-fail and false-pass results
テストの失敗の分析には時間がかかる。テスト対象ではなく、テスト自動化に問題がある時、false alarmが起きる。このfalse alarmを低く抑えることが重要である。
偽陽性（False-fails）はテスト自動化の信頼性を下げる
偽陰性（false-pass）は欠陥を見逃すため危険である
false alarmはテストコードの不具合で起きるが、不安定な実行環境においても起きうる。
Code coverage
異なるテストケースでテスト対象のコードカバレッジを知ることは有効である。適切なカバレッジを示す絶対的な比率は存在しない。１００％コードカバレッジは達しえない。しかし、高いカバレッジはソフトのリスクを減らすことを示す。
Tool scripting metrics
テスト自動化のリリースのモニタリングに使われるメトリックス。
多くはソースコードメトリックスに類似している。ソースコード行数や循環的複雑度はSCRIPTの大きさ、複雑度を示すものである。
Automation code defect density
自動化のコードはテスト対象のコードとそれほど変わらない。
自動化コードはテスト対象のコードより重要性を低く考えるべきではない。コード欠陥密度のようなメトリックスでモニタリングするとよい。
Speed and efficiency of TAS components
同テストステップ数、同環境での実施時間の差異が起きるのは、テスト対象に問題があることを意味する。これは不可によりパフォーマンスが悪化していることを意味しているかもしれない。
Trend metrics
メトリックス測定コストは可能な限り低くし自動化によってとれるようにすべし。
5.2 Implementation of Measurement
テスト自動化戦略はテストウェアを自動化するため、自動化されたテストウェアはそれらの利用に関する情報記録を強化される。
Features of automation that support measurement and report generation
言語のスクリプティングは測定とレポート機能をサポートする。
テスト実施のレポートは分析において過去のテスト実行結果を考慮する。
テスト自動化は実行と検証の両方の自動化が求められる。検証は特定の要素を事前に定義した期待値と比較することである。この比較は一般的な処理である。この比較結果の情報レベルは考慮すべきである。テスト結果、失敗の時は欠陥に関する情報。
期待値の差異を識別することはいつもささいなことではない。
Integration with other third party tools (spreadsheets, XML, documents, databases, report tools,
etc.)
自動化テストの実行の情報をほかのツールで使うとき、ほかのツールに適切なフォーマットで提供する。これは既存のツールでデータのexport機能やユーザーでカスタマイズして出力する。
Visualization of results (dashboards, charts, graphs, etc.)
テスト結果をチャートといったビジュアライズする。マネージメント層はこのサマリ情報を見る。
5.3 Logging of the TAS and the SUT
自動化自身、もしくはテスト対象のロギングは重要である。潜在的問題を分析に使われる。
ロギングには以下のようなことが含まれる
テスト自動化のログ
- どのテストケースが実行中か、そして開始、終了時間を含む
- テスト実行ステータス、結果が成功したか失敗したか、もしくは自動化が失敗したかどうか。
- ハイレベル（どのタイミングで起きたかを含む）の詳細テストログ
- メモリリークといった、テスト対象の動的な情報。問題が起きたときに、実行中のテストケースにその動的情報が必要となる
- 信頼性、負荷試験等において、カウンターを記録する。何回目のテストで起きたかを明らかにするため。
- ランダムなテスト実行の場合、ランダムの番号等、特定する情報をログとしてとる
- テスト実施のすべてのアクションをロギングし、確実に再現できるようにする。
- スクリーンショット等、失敗分析のためのビジュアルなログを残す
- テストケースが失敗した時いつでも、テスト自動化は問題分析に必要なすべての情報を保存しておく。どんなクラッシュダンプやスタックトレースなども保存する。そして上書きされて消されないように。
- カラーは問題分類に役に立つ
テスト対象のログ
- テスト対象が問題を見つけたとき、問題分析に必要な情報を保存する必要がある。タイムスタンプや発生源、エラーメッセージ等
- すべてのユーザー相互操作をログする
- システム起動時、設定情報をロギングする。
すべてのログは探しやすくする必要がある。
5.4 Test Automation Reporting
テストログは実行ステップの詳細な情報を提供する。しかし、ログ単体ではよい情報を提供できない。このため、レポート機能が必要となる。各テストスイート実行後、簡潔なレポートを作る必要がある。
Content of the reports
テスト実行レポートは実行結果の概要、実行したシステム、環境等のサマリを含む
どのテストが失敗し、失敗原因を知る必要がある。トラブルシューティングを簡単にするため、テスト実行履歴や担当者などを知ることが求められる。担当者は失敗原因を調査し、レポートし、問題修正、正しく修正されたことの確認を実施する
Publishing the reports
レポートはテスト結果に興味ある人すべてに提供する。WEBSITEで更新でき、メーリングリストに流し、テストツールにアップロードする。実用的に、実行結果に興味ある人はそれを見て、分析する。