テスト自動化シラバスver2.0解釈 No.2

Last updated at 2024-09-13Posted at 2024-09-01

Outline

ISQTBのテスト自動化のシラバス「Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) 」が 2024年5月に v2.0 にバージョンアップしました。

英語翻訳、自己解釈したものをつらつらと記載しました No.2
長いので、分割して記事にした。

なお、本記事に使用した図はISTQBシラバスのものである。

4.1 テスト自動化開発

4.1.1 効果的なテスト自動化パイロットと開発活動を支えるガイドライン

テスト自動化のパイロットで検証スコープを定義することは重要です。
パイロットは時間を長く時間をかけるものではないが、得られる結果はプロジェクトの方向性に大きな影響を与える。
SUTとプロジェクトの要件の情報収集に基づき、テスト自動化作業の最適化するためのガイドライン構築のため、以下の点が評価される必要がある。

プログラミング言語
ふさわしい商用既成ツール、OSS
カバーするテストレベル
用いられるテストケース
テストケース開発アプローチ

上記項目をもとに、TAEは初期アプローチを定義できる。
要件に基づき、いくつか異なる初期プロトタイプを作成し、Pros/Consを整理する。
これらより、TAEはどのアプローチにするかを決めることができる。

タイムラインを決めることは、スケジュール通りに進め、パイロットを成功させるために重要です。
共通認識として、定期的にパイロットプロジェクトの進捗を確認して、リスク認識と軽減を行う。

パイロット期間中、ソリューションと実装されたコードをCI/CDに統合することを推奨する。
これによって、SUTやTAS、組織で使う異なるツールの統合の中で、問題を早く見つけることができる。

テストケースの数が増えるにつれて、TAEは、初期のCI/CDセットアップを変更して、テストを異なる方法や異なるタイミングで実行することを考えることができる。

また、パイロットプロジェクト期間中、他の非技術的側面も評価すべきである。

チームメンバーの知識と経験
チーム構造
ライセンスと組織規則
計画されたテストの種類と対象となるテストレベル

パイロットプロジェクトが完了すれば、TAEやテストマネージャーによって成果を評価し、成功または失敗を判断し、適切な意思決定を行う必要がある。

4.2 テスト自動化開発に伴うリスク

4.2.1 デプロイリスク分析とテスト自動化のリスク軽減戦略

SUTへのTAFのインターフェース設計は、アーキテクチャ設計の一部として重要です。
パッケージ、ロギング、テストハーネスツールが選ばれうる。
パイロットの実装において、テスト自動化コードの拡張と保守を考慮する必要がある。
これらは、パイロットの評価フェーズに重要な要素で、最終決定の大きな影響を与える。

パイロットでさまざまなデプロイリスクが検出される。

ファイアーウォールの開放
リソース使用状況

デプロイリスクに対する準備は必要です。例えば、ファイアーウォール問題、リソース利用率、ネットワーク接続、信頼性など。
厳密にテスト自動化と関係しないが、TAEは全ての条件が満たしていることを確認して、開発プロセスの中で信頼性があり、有益な品質ゲートを提供できるようにする。
モバイルテスト自動化で実機を使う時、モバイルデバイスは電源をオン、テストを行うに十分なバッテリー、ネットワークに接続、SUTにアクセスできる条件を満たしておくこと。

技術的な、デプロイリスクは以下のものが含まれる

パッケージ
ロギング
テスト構造化
更新

パッケージング

パッケージングは、テスト自動化のバージョン管理において、SUTと同様に重要です。
テストウェアは、オンプレミスまたはクラウドのいずれかのリポジトリにアップロードして（構成管理）、組織で共有する必要がある場合があります。

ロギング

テストロギングは、テスト結果に関する情報を大部分提供します。テストロギングにはいくつかのレベルがあり、それらはすべてテスト自動化においてさまざまな理由で有用です。

Fatal: テスト実行を中止する可能性のあるエラーイベントを記録するために使用
Error: 条件または相互作用が失敗し、テストケースも失敗した場合に使用
Warn: 予期しない条件またはアクションが起きているが、テストケースが中断しない場合に使用
Info: テストケースの基本情報や、テスト実行中の出来事に関する情報として使用
Debug: 一般的に普段ログとして必要とされないが、細かい情報を含んでおり、テストの失敗を調査する際に使用。
Trace: デバッグと類似しているが、さらに多くの情報が含む。

テスト構造化

テスト構造化において最も重要な部分は、テストハーネスとそれに含まれるテストフィクスチャです。
これらの要素は、テストを実行するために必要不可欠です。
テストフィクスチャとは、テスト環境とテストデータを制御する自由度を提供する。
テスト実行の前提条件と事後条件を定義でき、テストケースを複数の方法でテストスイートにグループ化できます。
これらの側面は、パイロットプロジェクトの評価においても重要です。
さらに、テストフィクスチャによって、繰り返し可能で不可分操作として、自動テストの作成を可能にします。

更新

技術的リスクの最も共通点の一つはテストハーネスの自動更新やデバイスのバージョン変更である
これらリスクは適切な電源供給、適切なネットワーク接続、適切なデバイス構成計画を備えることでリスク軽減できる。

4.3 テスト自動化ソリューション (TAS) の保守性

4.3.1 TASの保守性をサポートし、影響する要因

保守性は、プログラミング標準と、TAE同士の期待に大きく影響されます。
黄金律は、Robert C. Martinのクリーンコード原則が参考になります（Robert C Martin, “Clean Code: A Handbook of Agile Software Craftsmanship”, 2008）。
クリーンコード原則は、以下の点を強調しています

命名規則: クラス、メソッド、変数へわかりやすい名前をつけることで、コードの可読性を上げる
論理的で共通のプロジェクト構造: 論理的な構造を採用することで、プロジェクトの管理と理解を容易にする。
ハードコーディング禁止: 定数を変数として管理することで、コードの柔軟性を高める。
多くの入力パラメータ禁止: メソッドに渡すパラメータの数を適切に管理することで、コードシンプルに
長く複雑なメソッド禁止: メソッドを短くシンプルにすることで、理解しやすく、保守しやすくなる。
ロギング: テストの実行状況を記録することで、問題の調査やトラブルシューティングを容易にする。
有益で必要とされる箇所への設計パターン: 適切な設計パターンを使用することで、コードの品質と保守性を向上させる。
てスタビリティ: テストが容易に実行できる構造にすることで、テストの品質と効率を高める。

命名規則は、特定の変数が対象とするものを識別するのに非常に役立つ
わかりやすい変数名（CamelCaseを使った、「loginButton」、「resetPasswordButton」など）を使用すると、TAEはどのコンポーネントを使用すべきかを理解しやすい。

ハードコーディングは、値をソフトウェアに直接埋め込み、直接変更できないプロセスです。
これは、データ駆動型テストを使用して回避でき、テストデータはより簡単に管理できる共通のソースから取得される。
ハードコーディングは開発時間を短縮しますが、データは頻繁に変更される可能性があり、保守に時間がかかるため、使用しない方がいい。
頻繁に変更されることが予想されない変数には定数を使用することも推奨されます。
これにより、保守が必要なソースや場所を減らすことができる。

設計パターンの活用も強く推奨される。
3.1.5で説明されているように、設計パターンを適切に使用すれば、構造化され、適切に保守可能なテスト自動化コードを実装できます。

高品質なテスト自動化コードの確保するために、静的分析を使用するとよい。
IDEで一般的に使用されるコードフォーマッタは、テスト自動化コードの可読性を向上させます。

クリーンコード原則に加えて、バージョン管理で合意されたブランチ構造と戦略を使用するとよい。
機能、リリース、および欠陥修正のために異なるブランチを使用すると、ブランチの内容を理解するのに役立ちます。

5 テスト自動化の実装とデプロイ戦略

5.1 CI/CD パイプラインへの統合

5.1.1 パイプラインでさまざまなテストレベルにテスト自動化を適用

テスト自動化の主なメリットの1つは、実装されたテストが無人でも実行でることで、パイプライン内で実行するのに理想的手段である。
これは、CI/CDパイプラインまたはテストを定期的に実行するために使用されるパイプラインを通じて実行される。

テストレベルは通常、次のもので統合される。

TAF、TASの構成テストは、ビルドする際に実行されるテストの一種です。これは、テストスクリプトで使用されるファイルのパスが正しく設定されているか、ファイルが存在するかを確認するためのテストです。
コンポーネントテストは、個々のコンポーネント (ライブラリクラス、Webコンポーネントなど) を対象としたテストです。ビルドプロセスの一部として実行され、パイプラインの品質ゲートである。つまり、コンポーネントが正しく動作することを確認する重要なテストです。
コンポーネント統合テストは、SUTの低層のコンポーネントやシステム全体を対象としたテストの場合、コンポーネントテストと一緒に実行される。つまり、複数のコンポーネントが連携して動作することを確認するためのテストです。
システムテストは、システム全体を対象としたテストです。継続的デプロイメントパイプラインの最後のSUT品質ゲートとして実行されることが多く、システムが要求どおりに機能することを確認します。
システム統合テストは、異なるシステムコンポーネント間の連携をテストします。継続的デリバリーパイプラインの品質ゲートとして実行されることが多い。異なるタイミングでデプロイされたシステムコンポーネントが正しく連携することを確認します。

多くのモデルのCIシステムはCDパイプラインのビルドとデプロイのフェーズを区別する。
この場合、コンポーネントテスト、コンポーネント統合テストは最初のビルドフェーズの一部である。
この最初のフェーズが成功すると、コンポーネント、SUTがデプロイされる。

システム統合テスト、システムテスト、受入テストでは、２つの主要なアプローチで統合する

テストケースは、コンポーネントのデプロイ後にデプロイフェーズの一部として実行されます。これは、テスト結果に基づいてデプロイが失敗し、ロールバックできるため、有効である。ただし、この場合、テストを再実行する必要がある場合、再デプロイする必要がある。
テストケースは、成功したデプロイによってトリガーされる別のパイプラインとして実行される。これは、各デプロイで異なるテストスイートとテスト自動化コードが実行されると予想される場合に有益です。この場合、テストは品質ゲートとはならない。そのため、失敗したデプロイをロールバックするには、通常、手動のアクションが必要です。この場合、いくつかの単純な自動化されたテストスクリプトをデプロイチェックとして使用して（スモークテスト）、SUTがデプロイされていることを確認できますが、これらの自動化されたテストスクリプトは広範囲にわたって機能の適合性を検証するものではない。

パイプラインは他のテスト自動化の目的にも使われる

さまざまなテストスイートの定期実行:　リグレッションテストスイートを毎晩実行することで、特に長時間のテストスイートの場合、チームは朝の時点でSUTの品質を明確に把握できる。
非機能テストの定期実行:　CDパイプラインの一部として、または個別に、システムのパフォーマンス効率などの特定の非機能品質特性を定期的に監視します。

5.1.2 テストウェアの構成管理

構成管理はテスト自動化の不可欠なもので、いくつかのテスト環境や異なるバージョンのSUTで自動化が実行される。

テスト自動化の構成管理は以下のようなものを含んでいる

テスト環境設定
テストデータ
テストスイート、ケース

テスト環境設定

開発パイプラインで使用される各テスト環境は、さまざまなURLや認証情報などの異なる構成を持っている。
テスト環境の構成は通常、テストウェアと一緒に保存される。
しかし、複数のプロジェクトまたは同じプロジェクトの複数のTAFで使用するテスト自動化の場合、テスト環境の設定は共通のコアライブラリまたは共有リポジトリの一部にすることができる。

テストデータ

テストデータもテスト環境やリリース、SUTの機能セットごとに固有となる。
テスト環境の設定のように、テストデータは小さいTAFに保存されることがあるが、テストデータ管理システムで管理されうる。

テストスイート、ケース

テストケースの目的（スモークテストや回帰テストなど）に基づいて、異なるテストスイートを設定するのが一般的である。
これらのテストスイートは、通常、異なるテストレベルで実行され、異なるパイプラインとテスト環境を活用する。
SUTの各リリースは、テストケースとテストスイートを含む機能セットを決定し、特定のリリースの品質を評価する。
テストウェアには以下のことを対処するためのさまざまなオプションがあります。

機能トグル設定が各リリース、テスト環境にて定義される。各機能のテストを行うテストケースやスイートもある。与えられたリリース・テスト環境で実行されるテストスイートを識別することに機能トグルは使われる
テストウェアは、同じリリースバージョンを使用してSUTと一緒にリリースすることもできる。これにより、SUTバージョンとそれをテストできるテストウェアが完全一致される。このようなリリースは、通常構成管理システムでタグやブランチを使用して実装される。

5.1.3 APIインフラのテスト自動化依存

APIテスト自動化実行では、適切な戦略を構築するために、依存に関する次の情報を知ることが重要です

API接続：自動的にテストできるビジネスロジックとAPI間の関係を理解する
APIドキュメント：すべての関連情報（パラメータ、ヘッダー、オブジェクトの異なるタイプの要求/応答など）を含むテスト自動化のベースラインとして機能する

統合自動APIテストは、開発者またはTAEによって実行される。
ただし、シフトレフトでは、さまざまなレベルでテストをサポートおよび分離されることがおすすめ。
ISTQB CTFLシラバスでは、コンポーネント統合テストとシステム統合テストが言及されていますが、これらはコントラクトテストと呼ばれるベストプラクティスに拡張できます。

コントラクトテスト

コントラクトテストは、サービス間の通信が正しく機能し、サービス間で共有されるデータが指定された一連のルールに準じていることを検証する統合テストの一種です。
このコントラクトテストで、2つの個別のシステム（たとえば、2つのマイクロサービス）が互いに通信するための互換性を提供します。
これは、スキーマ検証だけでなく、両当事者が将来の更新に対しても対応できる、一連の相互作用について合意する必要がある。
これは、各サービス間で交換される相互作用をキャプチャし、それらをコントラクトに保存し、その後、両当事者がそれに従っていることを検証するために使用することができます。
このテストタイプの主なメリットの1つは、基礎となるサービスから発生する欠陥をSDLCの初期段階で発見し、これらの欠陥の原因をより簡単に特定できることです。

コントラクトテストの消費者駆動アプローチでは、消費者（API呼び出し側）がその期待を設定し、提供者がこの消費者からの要求に応答する方法を決定します。
コントラクトテストのプロバイダー駆動アプローチでは、プロバイダー（API側）が契約を作成し、そのサービスの動作を示します。

6.1 テスト自動化データの収集、分析、レポーティング

6.1.1 TASやSUTからデータ収集方法

集められるデータには以下のようなものがある

SUT logs
- Web/mobile UIAPIs
- Applications
- Web servers
- Database servers
TAF logs : 監査ログになる
Build logs
Deployment logs
Production logs : 本番のデータ監視 (ISTQB CT-PT Syllabus, section 2.3)
- トレンド分析のためのパフォーマンス監視
- パフォーマンステスト環境のパフォーマンス効率テストログ (load, stress, spikeテスト)
Screenshots , screen recordings (テスト自動化ツールや3rd partyに組み込まれている)

TASはテストウェアのコアを自動化しているため、自動化されたテストウェアが拡張されて利用状況を記録できるようになる。
基礎テストウェアに対して拡張されたテストウェアは全てのハイレベルなテスト自動化スクリプトに使われる。
たとえば、テストの実行の開始時間と終了時間を記録するように基礎テストウェアを強化することは、すべてのテストに適用できる。

テスト自動化における測定とテストレポート生成をサポートする機能

多くのテストツールのスクリプト言語は、個々のテストやテストスイート全体のテスト実行の前、中、後に情報を記録およびロギングに使用できる機能で、測定とレポートをサポートしている。
一連のテスト実行のそれぞれに関するテストレポートには、前回のテスト結果が考慮する分析機能を持ち、トレンド（テスト成功率の変化など）をハイライトする。
テスト自動化は、通常、テストの実行とテストの検証の両方を自動化する必要がある。テスト検証は、実際の結果の特定の要素と期待値を比較で行われる。
この比較は、アサーションを使用してテストツールによって最もよく行われる。
報告される結果のレベルを考慮する必要があります。
重要なのは、テストステータス（合格または不合格）が正しく決定されることです。
失敗ステータスの場合は、失敗の原因に関する詳細情報、例えばスクリーンショットが必要になる。
テストの実際値と期待値の差分は常にクリアではなく、ツールはこの期待値との差分（日付や時刻など）を無視する比較を定義し、予期しない違いをハイライトする。

テストロギング

テストログはTASやSUTの潜在的欠陥を分析するために使われる。

TASロギング

TAFやテスト実行では、以下のような情報をロギングする必要がある。

実行テストと実行時間 : どのテストケースが実行されているのか、そしてそのテストの開始時刻と終了時刻はいつか？
ステータス : テスト実行のステータスは、テストログで簡単に識別できる失敗だけでなく、TAFもこの情報を持ち、ダッシュボードで報告する必要があります。テスト実行のステータスは「合格」「失敗」「TASの失敗」のどれかです。ステータスが不確定な場合もあり、チームで一貫した定義を持つことが重要です。SUTに欠陥がないとき、TASの失敗である。
詳細情報 : 低レベルの詳細なテストログ、テストステップや、タイミング情報が含まれる
動的情報 : SUTのメモリリークなどの動的情報で、3rd partyツールで取得できる。失敗が検出された時、実行したテストスイートと共に、実際の結果や失敗がロギングされる
実行回数 : 信頼性テストやストレステストのように多くのテストが行われるとき、何回実行されたかのカウンターを記録する
ランダム : ランダム要素を持つテストケースでは、ランダム値、ランダム選択された情報を含む
テストステップ : テストケースで実行されたすべてのアクションを記録し、テストログやその一部を再生して、同じテスト手順とタイミングでテストを再現できる。これは、特定された失敗を再現し、追加情報を取得するのに役立つ。テストケースのアクション情報は、ユーザーが見つけた失敗を再現するためにSUTによっても記録されることもある。ユーザーがテストスイートを実行すると、テストログ情報がキャプチャされ、開発チームが欠陥をトラブルシューティングする際にリプレイとして使う。
スクリーンショット : テスト実行中にスクリーンショットを保存することで、根本原因の分析時に役立つ。
その他情報 : テストスイートが失敗を引き起こした場合、TASは欠陥を分析する必要なすべての情報を保存し、必要に応じてテストの継続に関する情報も保存する必要がある。TASは関連するクラッシュダンプやスタックトレースも保存する。また、上書きされる可能性のあるテストログ（例えば、循環バッファ）も後で分析できるように保存する必要がある。
色 : 色を使うことで、異なる種類のテストログ情報を区別するのに役立つ。例えば、欠陥情報を赤で表示し、進行状況を緑で表示する。

SUTロギング

テスト自動化の結果とSUTのログを関連付けることで、SUTやTASの欠陥の根本原因を特定するに役立つ。

SUTで欠陥が特定された時、欠陥分析に必要な情報を全てログに残す必要がある。それには日付、タイムスタンプ、欠陥発生箇所、エラーメッセージなどが含まれる
システム起動時、校正情報をロギングする。さまざまなソフトウェア、ファームウェアのバージョン、SUT構成、OSなどが含まれる
テスト自動化を使うと、SUTログが簡単に探せる。TASのテストログから特定された失敗は、SUTのテストログでも簡単に特定される。逆も同様。さまざまなテストログをタイムスタンプで同期することで、失敗が検知された時に何が起こったかを関連付けることが容易になる。

3rd partyツールとの結合 (spreadsheets, XML, ドキュメント, データベース, レポートツール)

自動化されたテストケースの実行結果を他のツールで追跡や報告に使用する場合（例えば、トレーサビリティ情報）、その情報を3rd partyツールに適した形式で提供することが可能。
既存のテストツールの機能（例えば、テスト報告のエクスポート形式）を使用するか、他のソフトウェアと一貫性のある形式で出力されるカスタマイズされた報告を作成することで実現される。

テスト結果の可視化

テスト結果はチャートを使って視覚化することができる。
信号機のような色付きのアイコンを使って、テスト実行やテスト自動化の全体的なステータスを示すべきです。
これに基づいて意思決定を行うことができます。
特にマネージャは、テスト結果を視覚的にまとめたレポートで簡単に意思決定できるようになる。
さらに情報が必要なときには、詳細を掘り下げて確認することもできる。

6.1.2 TASやSUTのデータ分析でテスト結果をさらによく理解する

テスト実行後、重要なことはテスト結果分析で、SUTやTASの潜在的失敗の認識である。
分析のため、TASのデータ収集が最優先で、SUTのデータ収集は２番目である。

テスト環境データの分析で、テスト自動化の最適なサイズ化をサポートする
- クラスターやリソース（CPU,RAM）
- 単一、マルチブラウザテスト実行
前回実行のテスト結果との比較
どのようにWEBログを用いるかを決めて、ソフトウェアの利用状況を監視する

潜在的な課題があるため、テスト実行失敗を分析する

過去のテスト実行で同様な失敗が発生しているかをチェックする。これはSUTもしくはTASの既知の欠陥でありうる。TASはテストケースのテスト結果履歴をログに残すことで、分析に役立つ
欠陥が既知でないとき、テストケースとどんなテストが行われたかと特定する。テストは自己説明型にする、もしくはテストケースのIDをテスト実行と合わせてテスト管理システムに記録することで、テストケースを特定することができる。
失敗が起きたテストケースのステップを探す。TASはこれをログに残す
SUTの状態に関するテストログ情報を分析し、スクショ、APIログ、ネットワークログ、SUTの状態を示すログを用いて期待値と一致するかを確認する
SUTの状態が期待値でない場合、欠陥管理システムに欠陥をロギングする。全ての必要な欠陥情報と欠陥である証拠のログが含まれていることを確認する

失敗であるが、SUTの実際値と期待値が一致することがある（偽陰性）。この場合、TASが修正すべき不具合、もしくは見えない不一致が存在する可能性がある。

他のケースとして、テスト実施中、テスト環境が全部、もしくは一部が利用不可能の時である。
この場合、全てのテストケースが同じ欠陥で失敗するか、一部システムダウンで見かけ上の失敗するかである。
このような欠陥の根本原因を特定するため、SUTログを分析し、テスト環境が実行中に動かなかったかどうかを示す。

SUTがUIの監査ログを実装していると、テスト結果の分析に役立つ。
ユニークIDを付与し、システムの全ての呼び出しや結合に同じIDを用いる。
これにより、リクエストや操作のユニークIDを知ることで、システム動作を観察でき、追跡できるようになる。

このユニークIDはコリレーションIDやトレースIDと呼ばれ、TASによってロギングされ、テスト結果の分析に役立つ

コリレーションID：異なるシステムやサービス間、マイクロサービスアーキテクチャにおいて、リクエストを追跡するのに使われる
トレースID：特定のリクエストや操作の流れを追跡するために使われる

6.1.3 テスト進捗報告書の作成と公開方法

テストログは、テストケースやテストスイートのテスト手順、実行するアクション、応答の期待値についての詳細な情報を提供する。
しかし、テストログだけでは全体的なテスト結果の概要を把握することはできない。
そのためには、テスト報告機能が必要です。
テストスイートの実行後、簡潔なテスト進捗報告書を作成し、公開する必要がある。
これには、レポートジェネレーターが使われる

テスト進捗レポートのコンテンツ

テスト進捗報告書には次のものが含まれる必要がある

テスト結果
SUTの情報
テストが実行された環境のドキュメント

これらは、各ステークホルダーに適した形式で提供される。

また、どのテストが失敗したか、その理由を知ることが必要です。
トラブルシューティングを容易にするためには、テスト実行履歴と報告者（通常は作成者または最後に更新した人）を知ることが重要です。

責任者は、失敗の原因を調査し、関連する欠陥を報告し、その修正をフォローアップし、修正が正しく実装されたかをテスト（確認テスト）する必要がある。

さらに、テスト報告は、TAFコンポーネントの失敗を診断するためにも使用される。

テストレポートの公開

テストレポートは、すべての関連するステークホルダーに公開されるべきです。
公開方法の例

WEB
クラウド
オンプレミス
メーリングリストに送信
テスト管理ツールなどの他のツールにアップロード

個々がメールやチャットボットなどのメッセージで受信するように登録していれば、レポートがレビューされ、分析されるように促される。

SUTの問題のある部分を特定し、テスト報告書の履歴を保持することで、頻繁にリグレッションが発生するテストケースやテストスイートに関する統計を収集し、トレンド分析を行うことができる。

レポート対象者

管理ステークホルダー : ソリューションまたはエンタープライズアーキテクト、プロジェクト/デリバリーマネージャー、プログラムマネージャー、テストマネージャー、テストディレクター
運用ステークホルダー : プロダクトオーナー/マネージャー、ビジネス代表者、ビジネスアナリスト
技術ステークホルダー : チームリーダー、スクラムマスター、ウェブ管理者、データベース開発者/管理者、テストリーダー、TAE、テスター、開発者

テストレポートの内容などは受け手によって変化する。
技術者は低レベルな詳細情報に興味がある。
管理層は傾向、例えば最後のテスト実行で追加されたテストケース、合格・不合格比率の変化、TASやSUTの信頼性に興味を持つ。
運用者は製品の利用に関するメトリクスに興味を持つ。

ダッシュボード

モダンなレポートツールはダッシュボード、カラフルなチャート、詳細なログコレクション、自動化されたテストログ分析など、さまざまなレポートオプションがある。

これらのツールは、パイプライン実行テストログ、プロジェクト管理ツール、コードリポジトリなどのソースからデータを集約することをサポートする。
これにより、データの可視化が可能となり、ステークホルダーがトレンドを把握し、それに基づいて意思決定を行うことができる。
これらのトレンドには、欠陥のクラスター、特定のテスト環境へ引き起こした欠陥増減、SUTのパフォーマンスの低下、ビルドの信頼性などが含まれる。

テストログのAI・機械学習分析

近年、一部のテスト自動化ツールには、機械学習（ML）アルゴリズムが含まれているか、それに基づいています。
テストログの大量のデータを自動的に分析することで、TAEは次の運用作業にかかる時間を短縮できます：

壊れたロケーターの特定: テストスクリプト内の要素(XPathなど)が見つからない場合の原因を特定
テスト失敗の原因分析: テスト失敗の原因がSUTかTASにあるのかの分析
共通の欠陥のグループ化: テスト報告のために共通の欠陥のグルーピング(ISTQB CT-AIシラバス)

続く

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up