はじめに
テスト自動化戦略のシラバスが今年2024年に公開された。
このシラバスを読みまして、各章をDailyで読めるようにしてみた
6 Implementation and Improvement Strategies for Testing
Automation を今回は翻訳・解説する
手動テストからテスト自動化への移行における要因と計画活動
手動テストからテスト自動化への移行の最も簡単な機会は、リグレッションテストをターゲットにすること。
リグレッションテストスイートは、今日の機能テストと非機能テストが明日のリグレッションテストになるにつれて成長します。
リグレッションテストの数が、従来の手動テストチームが利用できる時間とリソースを超えるのはすぐきます。
移行コスト
手動テストから自動テストへの移行中、両方が同時に実施されるため、プロジェクトのコストが増加する可能性がある。
自動テストが手動テスト実行活動を十分に置き換えるか上まわれば、より多くの労力を探索的テストやテスト自動化のための追加テストケースの定義に移すことができます。
これは、手動回帰テストと比較して異なるコストがかかります。
機能重複と解決策
機能重複とは、テストスクリプト開発者が異なるテストケースに同じテスト自動化ステップを何度も記述してしまうことです。
例えば、ログイン処理は多くのテストに含まれる。
これを各テストケースに個別に記述すると、メンテナンスが非常に煩雑になります。
ログイン処理に新たなステップを追加する必要がある場合、すべてのテストケースを修正しなければなりません。
より良いアプローチは、ログイン処理を再利用可能なテスト自動化コンポーネントとして作成し、すべてのテストケースからその機能を参照することです。
これにより、メンテナンス性が大幅に向上します。
データ共有
テストはしばしばテストデータを共有します。
これは、テストが異なる SUT 機能を実行するために同じテストデータレコードを使用する場合に発生します。
例として、テストケース「A」が従業員の利用可能な休暇時間を検証し、テストケース「B」が従業員がキャリア開発目標の一部として受講したコースを検証する場合があります。
各テストケースは同じ従業員を使用しますが、異なるパラメーターを検証します。
手動テスト環境では、従業員のテストデータは通常、この従業員を使用して従業員のテストデータを検証する各手動テストケースで何度も複製されます。
しかし、自動テストでは、共有されるテストデータは、可能な限り単一の情報源から保存およびアクセスされ、重複やエラーの導入を回避する必要があります。
テスト相互依存
複雑なリグレッションテストを実行する場合、あるテストが 1 つ以上の他のテストに依存することがある。
たとえば、新しい「注文 ID」がテストステップの結果として作成されます。
後続のテストでは以下の確認が行われる
a) 新しい注文がシステムに正しく表示されているか
b) 注文の変更が可能か
c) 注文の削除が成功するか
いずれの場合も、最初のテストで動的に作成された「注文 ID」の値をキャプチャして、後続のテストで再利用する必要があります。
TAS の設計によっては、これを解決できます。
後続のテストケースで「注文 ID」が見つからない場合、それらは失敗します。
テスト実行の前提条件
TAE がテストスクリプトの開発をすぐに開始し、テストケースを確実に実行するための前提条件を理解しないことがよくある。
これは、複数のテスト環境で同じ SUT に対してテストケースを実行しようとするときに非常に困難になります。
前提条件の例には、ユーザー名、アカウントロール、データテーブルの値、およびテストケースを繰り返すために必要なその他の特定のデータエントリが含まれます。
良い戦略には、特定のテストケースを自動化する前に SUT にどのような情報が必要かを理解するための事前分析が含まれます。
さらに、実際のテストケースの実行前に前提条件の作成を自動化して時間を節約することで、戦略を強化できます。
これには、UI から SUT を移入する前提条件テストスクリプトの実行や、テストデータをデータベースにロードする自動バッチプロセスの実行が含まれる場合があります。
機能カバレッジ
テスト自動化の候補となるテストにおける機能ギャップの特定に、テスト自動化の対象となるテストケースを特定します。
手動テストケースの 100% を自動化することは、テストツールで自動化できるすべての可能なテストケースの 100% を表すものではありません。
より多くのテストが自動化されるにつれて、テスターはテスト実行時間を節約し、カバレッジを向上させるために追加の SUT テストを特定するために使用できます。
実行可能なテスト
手動リグレッションテストを自動化する前に、手動テストが正しく動作することを確認することが重要です。
手動リグレッションテストが正しく実行されない場合、それは不適切に記述されているか、無効なテストデータを使用しているか、最新ではないか、現在の SUT と同期していないか、または SUT の欠陥が原因である可能性があります。
問題の含むテストを自動化すると、機能しない自動リグレッションテストが作成され、無駄で非生産的になります。
古い手動テストに取って代わる自動テストに対する信頼感を伝えるために、新しい自動テストがもたらす同等の機能を実証することが重要です。
テスト自動化から継続的テストへの移行における要因と計画活動
継続的テストは、従来のSDLCよりもはるかに頻繁にテスト資産を利用することを伴う。
これは、コードの変更が行われ、テスト環境で利用可能になった直後に、テストスイートを継続的に実行し始めることによって実現されます。
これにより、即時のフィードバックを提供し、プロセス早期の欠陥の検出により欠陥コストを削減できます。
これは、高度な開発ツールと、ビルドプロセスの早期テストすることが求められる。
継続的テストのために TAS を適応させるには、以下が必要です。
- テストスイートの変更 : テストスイートを更新して、更新された TAS で実行できるようにする。 テストスイートに必要な変更を行い、TAS にデプロイする前にテストする。
- スタブ、ドライバ、およびインターフェイスの変更 : テストハーネスに必要な変更を行い、TAS にデプロイする前にテストする。
インフラストラクチャの変更 : 変更が必要なインフラストラクチャコンポーネントの評価を行う - 更新された TAS に追加の欠陥またはパフォーマンスの欠陥がある場合 : リスクとベネフィットの分析を実行。 検出された欠陥により TAS の更新が不可能な場合、更新を続行しないか、次のバージョンの TAS を待つのが最善策かもしれません。 欠陥が修正する利点に比べて無視できる場合、TAS は引き続き更新できます。
- 既知の欠陥のリリースノートを作成し、TAE とその他のステークホルダーに通知し、欠陥がいつ修正されるかの見積もりを取得する。
ポイントは、CI/CD を利用する場合に特に重要になります。
ビルドプロセスを自動化することは、開発中の TAS と自然に適合します。
ビルドオーケストレーションツールが正しいテスト環境にある場合、パイプラインを拡張して、デプロイ直後に SUT を検証する自動テストを含めることができる。
これには、テスト自動化ツールが適切に構成され、SUT にアクセスでき、コードリポジトリにアクセスし、データプロビジョニングスクリプトにアクセスできる必要がある。
テスト自動化資産とプラクティスの評価による改善領域の特定
テスト自動化ソリューション（TAS）の開発では、リファクタリングの機会を見つける戦略が重要です。
初期実装、メンテナンス、反復可能性を評価し、開発や修正にかかる時間、手動テストとの時間節約を追跡します。
デプロイ前に、TASが独自環境で実行でき、ランダムな変更から隔離され、テストケースの更新・管理が可能であることを確認します。
TASとそのインフラの維持も必要です。
初めてのデプロイの場合、次の基本的な手順が必要です。
- コードカバレッジツールでコンポーネントテストスイートによってどの程度のコードが実行されているか、および追加のコンポーネントテストでカバーできるギャップを示します。
- 要件トレーサビリティマトリックス（カバレッジ）を作成することで、どの機能がまだテストケースでカバーされていないかを明らかにします。
- TASの一貫したインフラストラクチャ使用をプロジェクト全体または組織全体で定義する
- テストスイートの一貫した構成管理戦略を開発
- TAS 開発ガイドラインを作成
- テストデータなどの前提条件設定を自動化する。 これにより、テストを実行する前にこれらのステップをスキップできない場合に、より信頼性が高く依存性の高いソリューションを実現できます。 リグレッションテストがテスト自動化に変換されるとき、これらの前提条件はテスト自動化プロセスの一部である必要があります。
新しい機能やメンテナンス目的で TAS を増分的に更新する場合、以下の点に注意する必要があります。
- テストツールの評価 : TAS の機能を拡張できるテストツールの更新を評価
- TASの最適化 : TAS の機能とパフォーマンスをさらに最適化する方法を検討
- テストスクリプトのモジュール化 : テストスクリプトをさらに分解し、モジュール化して再利用性を向上させる
- 再利用可能なコンポーネントの共有 : 再利用可能なコンポーネントの知識と認識を共有し、一貫した利用を確保
- 改善領域の特定 : 潜在的な改善領域に関する証拠を収集し、推奨事項とその利点を提供
- 機能重複の評価と修正 : 既存の回帰テストを自動化する場合、テストケース間に機能の重複がないかどうかを特定し、可能な限り以前に開発されたテスト自動化コンポーネントを再利用
- 追加の自動化対象の特定 : 自動化の機会がある追加の手動テストケースを特定し、実装のためのバックログアイテムを作成
- テスト設計とデータ管理の改善 : テスト設計とテストデータ管理の改善機会を強調
- テストスイートの適応 : すべての既存のテストスイートが最新バージョンの TAS に適応していることを確認
- パイプラインのキューイング対策 : テスト自動化によりパイプラインがキューイングされる場合、統合テストの範囲を最も重要なもの（スモークテストスイート）に絞り込みます。 より大規模なリグレッションテストスイートは、別途トリガーするか、オンデマンドで実行します。