はじめに
テスト自動化エンジニアのシラバスを再度読み直し、各章をDailyで読めるようにしてみた
8 Continuous Improvement の中で「 Discover opportunities for improving test cases through data collection and analysis」と「Analyze the technical aspects of a deployed test automation solution and provide
recommendations for improvement」を今回は翻訳・解説する
ここでは、テスト自動化自身の改善を行なっていくことに関して書かれている
データ収集と分析でテストケース改善
テストヒストグラム
テストヒストグラムとは、テストの結果をグラフにして視覚的に表したものです。
今まで見えなかったテストに関する様々な情報を可視化します。
テストの傾向がひと目でわかる
- 成功率 : どのくらいのテストが成功しているか
- 失敗率 : どのくらいのテストが失敗しているか
- 失敗の推移 : 時間経過とともに、テストの成功率や失敗率がどのように変化しているか
改善点を探しやすい
- 不安定なテスト : 同じテストを何度も実行しても、結果が安定しないテスト（flaky テスト）を特定できる。
- 問題が多い領域 : 特定の機能やモジュールに関するテストで、頻繁に失敗が発生している場合は、その部分に問題がある可能性が高いことを示唆しています。
テストケースの改善に
上記で改善点を見つけたら、テスト自動化の改善を行なっていくと良い
- リファクタリング : 不安定なテストケースを見つけて、より安定するように書き直す
- テストデータの改善 : テストデータに問題があるために失敗しているケースを特定し、テストデータを改善
- テストケースの追加 : カバーできていない部分を見つけ出し、新しいテストケースを追加する
このようにテストヒストグラムは、テストの現状を把握し、改善すべき点を明確にするための強力なツールです。
この情報を活用することで、信頼性の高いテストを構築することができます。
人工知能 (AI)
従来のUIテストでは、ソフトウェアの画面が変わると、それに合わせてテストケースも手動で修正する必要がある
例えば、ボタンの位置が変わったり、新しい要素が追加されたりした場合、テストケースのコードを書き直さなければならなかった。
これはとても手間がかかる作業で、人的ミスも起こりやすかった。
ここに、AIが活躍する場面が登場します。
以下のような、自動化の運用の支援をしてくれます。
- ロケータの自動検出 : ボタンやテキストボックスなどの要素を特定するロケータが変更された場合、AIが自動的に新しいロケータを見つけ出します。
- テストケースの自動修復 : 新しいロケータを使って、テストケースのコードを自動的に修正します。
- テストレポートの自動更新 : 変更されたロケータをテストレポートに自動的に反映します。
このように、AIによって作業効率の向上、テスト品質の向上が見込まれる。
スキーマバリデーション
スキーマバリデーションとは、APIやデータベースのデータが、事前に定義されたルール（スキーマ）に従っているかを確認することです。
主な確認項目は次のとおり
- データの一貫性 : データが正しい形式であることを保証し、エラーを防ぐ
- ビジネス仕様の確認 : レスポンスがビジネスの要件に合っているかをチェックする
自動化することで手動でチェックする必要がなくなり、テストコードが短くなります。
不具合でスキーマが壊れた場合、すぐにエラーを返してくれるので、問題の原因を特定しやすくなります。
テスト自動化ソリューションの技術的側面の分析と改善
テスト自動化の改善は、高い効率化、より良い使いやすさ、追加機能、およびテストの改善されたサポートなど、さまざまな利点を達成するために実施していくことが望ましい
それぞれの視点での改善ポイントを以下に示す
スクリプティング
改善すべきポイントの例として以下のようなところがあります
テストスクリプト/テストケース/テストステップの重複
同じアクションシーケンスのテストステップは関数にしてライブラリに追加し、再利用することが望ましい。
これらのライブラリ関数を再利用させることでメンテナンス性が向上します。
TASとSUTの障害回復プロセスを確立
テストスイートの実行中に障害が発生した場合、TASは、次の可能なテストを続行するために、この状態から回復できる必要があります。
SUTで障害が発生した場合、TASは、可能かつ現実的な場合に、SUTで必要な回復アクション（SUTの再起動など）を実行する必要があります。
待ち(wait)メカニズム
3つの一般的な待ちメカニズムがあります。
-
ハードコーディングされた待ち (一定のミリ秒待つ) : ソフトウェアの応答時間の予測不可能性を考えると、多くのテスト自動化の欠陥の根本原因となる可能性があります。
-
ポーリングによる動的待機 (特定の状態変化やアクションが発生したかどうかをチェックする) : はるかに柔軟で効率的です。
TASは必要な時間だけ待機し、テスト時間は無駄になりません。
尚、タイムアウトメカニズムを忘れると、欠陥がある場合、テストは永遠に待つ可能性があります。 -
SUTのイベントメカニズムにサブスクライブ : これは他の2つのオプションよりもはるかに信頼性がありますが、テストスクリプト言語はイベントサブスクリプションをサポートする必要があり、SUTはこれらのイベントをTASに提供する必要があります。
テスト実行時間
テスト実行時間が長引く場合、以下の方法で効率化を図ることができます。
- 並行実行 : 複数の環境で同時にテストを実行する。
- テスト分割 : 大きなテストを小さなテストに分割する。
- 重複排除 : 同じ処理を繰り返すテストを減らす。
- CI/CD : CI/CDツールなどを活用し、テストの依存をパイプラインを組み込み、テスト実行を自動化する。
これらの手法を組み合わせることで、テスト時間を短縮し、開発のスピードアップに貢献できます。
検証ロジック
よく使われる検証処理を、ライブラリ・共通化を考えると良い。
これにより、複数のテストで検証アクションを再実装するのを避けることができます。
検証方法が同一ではないが類似している場合、パラメータ化を使用し、関数を複数のタイプのオブジェクトで使用できるようになる。
例えば
- 共通の検証関数を作成 : 頻繁に使う検証処理（例えば、要素の存在確認、テキストの比較、クリックなど）を関数化
- パラメータ化 : 検証対象の要素や期待値を関数のパラメータとして受け取るように設計
- ライブラリ化 : 複数のテストケースから共通して使えるように、検証関数をライブラリ化
TAA（テストアーキテクチャアプローチ）
テストのテスト可能性を向上させるために、TAAを変更する必要がある場合がある。
これによりテスト自動化を大幅に改善できますが、SUT/TASに大きな変更と投資が必要になる可能性が高い。
そのため、TAAの改善は、ソフトウェア開発ライフサイクルの初期段階から検討することが重要です。
後から変更を加えることは、コストや工数の面で大きな負担になることがあります。
また、TAAとSUTは密接に連携する必要があります。SUTの変更に合わせ、TAAも柔軟に調整する必要があります。
TAF（Test Automation Framework）
TAFのコアライブラリは、定期的にアップデートされます。
しかし、新しいバージョンがリリースされた直後に、すべてのチームがすぐにアップデートすることは現実的ではない。
新しいバージョンが原因で既存のテストが壊れてしまうリスクがあるからです。
そこで、段階的なアップデート戦略が有効です。
- パイロットプロジェクトの実施
一部のチームで新しいライブラリバージョンをテストし、影響を評価します。 - インパクト分析
新しいバージョンへの移行に伴うリスクや課題を特定します。 - アップデート計画の策定
全チームが同時にアップデートするか、各チームが個別にアップデートするかを決定します。 - 段階的なアップデート
全チームが新しいバージョンに対応できるようになったら、コアライブラリレイヤーの依存関係を更新します。
コアライブラリレイヤーは、複数のチームが共有する共通のライブラリを提供します。
このレイヤーのバージョン管理が重要になる。
新しいバージョンへの移行は慎重に行い、チーム間の連携を密にしてスムーズなアップデートをしていく。
セットアップとティアダウン
繰り返し実行されるアクションや設定は、セットアップまたはティアダウンメソッドに移動することが推奨する。
Webテストの例
- セットアップ : テスト開始前に、ブラウザを起動し、ログイン処理を行う。
- ティアダウン : テスト終了後に、ブラウザを閉じ、テストデータのクリーンアップを行う。
APIテストの例
- セットアップ : テスト開始前に、必要なデータを作成したり、APIエンドポイントに接続する。
- ティアダウン : テスト終了後に、作成したデータを削除したり、接続を切断する。
セットアップとティアダウンの処理は、テストの実行に必要な最小限のものにする。
また、エラーが発生した場合に適切な処理を行い（主にティアダウンの役割）、次のテストが中断しないような処理を組み込むことが良い。
セットアップとティアダウンの処理を適切に設計することで、テスト自動化の効率性と信頼性を向上させることができます。
ドキュメンテーションの重要性
テスト自動化の成功には、適切なドキュメンテーションが欠かせません。
ドキュメントは、テスト自動化の理解、メンテナンス、トラブルシューティング、さらには知識の継承に役立ちます。
ドキュメンテーションの対象
- テスト自動化コードのドキュメント
コードの目的、機能、使い方を明確に説明
コメントやドキュメントツールを活用して、コードの可読性を向上 - TASのユーザードキュメント
TASの使用方法、設定方法、トラブルシューティングの方法などを説明
ユーザーマニュアルやチュートリアルを作成することで、新しいユーザーの学習コストを下げる - テストレポートとテストログ
テストの実行結果、エラーログ、スクリーンショットなどを記録
テストの分析や問題の特定に役立てる
TASの機能拡張
TASの機能を拡張することで、テスト自動化の効率性と効果性を向上させることができる。
ただし、実際に必要とされる機能のみを追加することが重要です。
不要な機能を追加すると、システムの複雑性が増し、信頼性とメンテナンス性が低下します。
機能拡張の注意点
- 必要性と優先度 : 実際に必要な機能を優先して実装
- シンプルな設計 : 機能はシンプルでわかりやすく設計
- メンテナンス性の考慮 : 機能の追加によるメンテナンスコストが増加しないようにする
TAFの更新とアップグレード
TAFを更新またはアップグレードすることで、新しい機能が利用可能になり、エラーが修正される可能性があります。
ただ逆に、このアップデートによって、既存のテストケースに悪影響が出るリスクがあります。
新しいバージョンを導入する際の注意点
-
サンプルテストの実行
新しいバージョンのテストツールを導入する前に、代表的なテストケースを実行して、問題がないか確認します。
さまざまなSUT、テストタイプ、テスト環境でテストを行うことで、リスクを最小限に抑えます。 -
段階的な導入
新しいバージョンを段階的に導入し、影響を最小限に抑えます。
一部のテストケースで新しいバージョンを試用し、問題がないことを確認してから、全テストケースに適用します。 -
バックアップの確保
新しいバージョンを導入する前に、既存の環境をバックアップします。
万が一問題が発生した場合に、元の状態に戻すことができます。 -
ドキュメントの更新
新しいバージョンのテストツールの使い方や注意点などをドキュメントにまとめておきます。