テスト自動化における 10 のベスト プラクティス #1: 何を自動化するか
今回は「テスト自動化における 10 のベスト プラクティス」の第 1 回目をお届けします。テストに割けるリソースは限られており、テストを行う上で一番、考慮することとして「作業労力をどこに集中するか」が挙げられます。テストに費やした時間と労力に対して見返りが最も大きいテスト ケースはどれでしょうか ? この記事では、以下の3 種類のテスト ケースについて推奨するテスト方法を提案します。
- 自動化すべきテスト ケース
- 自動化が難しいテスト ケース
- 自動化すべきでないテストケース
1. 自動化すべきテストケース
理論上、あらゆるソフトウェア テストは自動化することができます。
問題は、テスト自動化で削減できるコストや時間より、開発や保守に掛かるコストや時間が大きいかどうかです。最大限の効果を得るには、以下のいずれかに当てはまるテストの自動化から行うことです。
〇 安定した機能のテスト
不安定な機能のテストを自動化すると、保守作業のコストが跳ね上がる可能性があります。
これを避けるには、機能が開発中の段階では、テストツールによる自動化を行なわずに、打鍵によるテストを行うことです。
〇 回帰テスト
ソフトウェアのリリースサイクルの中で、回帰テストを行うことにより、「リリースの際にデグレードが無いこと」、「新しいバグが無いこと」を検証するのに役立ちます。
回帰テストは頻繁に行われるテストのため、優先的に自動化を行うべきです。
〇 ハイリスク機能
リスク分析により、影響度が最も大きい機能を特定し、その機能に対してテスト自動化を重点的に実施します。そして、そのテスト資産を使用し、回帰テストを行います。
※リスクに基づくテスト ケースの優先度付けについては、「Ranorex GUI Testing」の「リスク アセスメントのセクション（英語）」をご参照ください。
〇 スモーク テスト
スモーク テストはアプリケーションの起動やログインの許可、その他主要な機能をチェックします。回帰スイートの規模によっては、システムのビルドを更新するたびに回帰スイート全体を実行するのは無意味な場合があるため、スモーク テストを回帰テストのサブセットとして使用し、初めにスモーク テストを行うことで、テスト対象のアプリケーションが良いビルドかどうかをチェックします。継続的インテグレーション (CI) プロセスにスモーク テストを組み込んで、新しいビルドが作成されるたびにスモーク テストを自動化します。
〇 データ駆動型テスト
繰り返し実行するテストはすべて自動化に向いています。
テストシナリオにおける、ユーザー名とパスワードやメール アドレスと支払い種類といった入力操作は、手動で何度も打ち込むのではなく、データ駆動型テストによる自動化に任せるべきです。
〇 負荷テスト
負荷テストは理論上の負荷に対してシステムの応答をテストすることです。
望ましい負荷をシミュレーションするには、テストを並行実行できるツールなどとデータ駆動型テストを併用します。
〇 クロス ブラウザー テスト
クロス ブラウザー テストは、アクセスする Web ブラウザーのバージョンに関係なくアプリケーションの動作が一貫していることを保証するのに役立ちます。通常、デバイスとブラウザーのすべての組み合わせに対してテスト スイート全体を実行する必要はありません。代わりに、ハイリスクな機能と最もよく使用されているブラウザーを集中的にテストします。
現在、Google Chromeはデスクトップとモバイルの両方で最もよく使用されているブラウザーであり、タブレットでは Safari に次いで 2 番目によく使用されています。そのため、Google Chrome に対してテスト スイート全体を実行し、その後 Safari、Firefox、Internet Explorer、Microsoft Edge に対してハイリスク テスト ケースを実行するのが合理的でしょう。
〇 クロス デバイス テスト
モバイル アプリケーションは、さまざまな画面サイズ、解像度、OS バージョンにわたって実行できる必要があります。
2018 年の Software Testing News によると、手動テスト部隊を新規に立ち上げる場合、可能性のある組み合わせの 80% を達成しようとするだけで約 50 個のデバイスが必要だそうです。クロス デバイス テストを自動化すれば、テストにかかるコストを削減し、時間を大幅に節約できます。
2. 自動化が難しいテストケース
以下で紹介するのは自動化が難しいテスト ケースです。
「自動化すべきでない」ということではなく、自動化にかかる時間と労力が他のテスト ケースよりも大きいものとなります。
特定のテスト ケースの自動化が難しいかどうかは、テスト対象アプリケーションに依存します。テストツールの評価や、PoC (Proof of Concept) を実施している場合、自動化が難しい状況を克服する上でツールがどのように役立つかを把握する必要があります。
▲ 動的なコンテンツ
動的なコンテンツにはさまざまな種類があります。たとえば保存されたユーザー設定に基づいて作成される Web ページや、PDF 文書、データベース行などです。この種のコンテンツのテストは、実行時にコンテンツの状態が不明なため、テストの自動化が困難です。詳細については Ranorex Blogの「自動テストと動的ID（英語）」をご参照ください。
▲ 複数の技術を組み合わせたテスト
ハイブリッド モバイル アプリケーションやバックエンド データベース サービスを利用する Web アプリケーションなどのように、複数の技術を使用したアプリケーションがあります。
このような環境でエンドツーエンド テストの自動化を簡単にしたい場合、これらの技術に対応したテストツールを使用することです。
※Ranorexがテスト環境に適しているかどうかについては、コチラをご参照ください。
▲ イベントの待機
テスト実行時に、テスト対象のシステムから期待する応答がない場合、テストが失敗することがあります。
システムの応答の遅延によるテストの失敗が起きないように、待機時間を適切に処理することが重要です。ただし、決して発生しないイベントを待機してテストが停止することがないように、妥当な待機時間を指定する必要があります。
※Ranorexでの待機時間の設定方法については、「Ranorex ユーザーズ ガイド」の「追加の編集オプション」をご参照ください。
▲ アラート/ポップアップの処理
予想外のアラートやポップアップが原因でテストが失敗することがあります。
テストを安定させるために、この種のイベントを処理するロジックを用意する必要があります。
※Ranorexのオートメーション ヘルパー（ポップアップウォッチャー）は、アラートとポップアップの処理を容易にします。
▲ 複雑な業務フロー
一連の業務フローを自動化する上で、以下の課題があります。
- 通常、業務の操作を順番に実行する必要があるため、テスト実行時に、ある業務の操作に失敗すると、その後の操作は実行できません。
- テスト自動化を行うために、複数ある業務フローをテストする必要があります。そのため、リリース後に、テストされていないフローが実行された場合に、問題が見つかる可能性があります。
これらの課題を軽減するには、テスト ケースをできる限りモジュール化し、そして、キーワード駆動型テストを使用することです。
▲ 特定の種類のWeb アプリケーション
Web アプリケーションを自動化する上で、以下の課題があります。
- 動的 ID を利用する UI 要素の認識：Ranorexでは、UI要素の認識をDOM情報によるパス情報（RanoreXPath）で認識し、動的 ID であっても確実なオブジェクト認識を可能にします。
- 複数ウィンドウとインライン フレーム (特にクロス ドメイン コンテンツがある場合) との切り替え：Ranorexでは、Web セキュリティが有効な場合でも、クロス ドメインのインライン フレーム内のオブジェクトを検出して自動化できます。
▲ 特定の種類のモバイル アプリケーション
Web アプリケーションを自動化する上で、以下の課題があります。
- 電話の着信やバッテリー容量低下のメッセージといった割り込みに応答できる必要があります。
- 対象デバイスを選定する必要があります。Androidアプリケーションの場合、画面サイズ、解像度、OS のバージョンなどが多岐にわたるため、選定が特に難しい問題です。
- iOS と Android の違いにより、一方のプラットフォームのテストを他のプラットフォームで実行するには、調整が必要となります。
自動化が難しい他のテストと同様に、テスト対象アプリケーションが利用する技術に対応したテストツールを使用することが非常に重要です。
3. 自動化すべきでないテストケース
以下で紹介するのは、自動化できない、あるいは自動化を推奨できないテストです。自動化に必要な時間と労力が自動化のメリットを上回るテストが該当します。そのようなテストは手動での実行を計画してください。
× 1 回しか実行しないテスト
開発において、1度しか実行しないテストであれば、打鍵でテストを実行した方が早いでしょう。
× 予測できない結果をともなうテスト
テスト結果を客観的で簡単に測定できる場合、テストを自動化してください。
たとえばログイン処理は自動化に適しています。なぜなら、有効な (あるいは不正な) ユーザー名とパスワードが入力されたときに何をすべきかが明確だからです。明確な成功/失敗条件がテスト ケースにない場合は、テスターが打鍵でテストする方が良いでしょう。
× 自動化を拒む機能
機能の中には自動化を拒否するように設計されたものもあります。
たとえば Web フォームの CAPTCHA があります。この場合、CAPTCHA を無効化するか、CAPTCHA を迂回するシナリオをテスト用に用意する方が良いでしょう。
もしくは、打鍵で CAPTCHA を行い、その後、テストを自動化する方法があります。「テスターが CAPTCHA を完了するまでテストを一時停止し、ログインの成功が返ったらテストを再開する」ロジックをテストに追加します。
× 不安定な機能
不安定な機能は打鍵でテストするのが一番です。機能が安定した状態になってから自動化を開始しましょう。
× モバイル デバイス上のネイティブ OS の機能
特にiOS では、ビルトイン セキュリティのために、インストルメントされないネイティブ システム アプリケーションを自動化することは、非常に難しいものとなります。
まとめ
テスト自動化を成功させるためには、適切なテスト ケースを選択して自動化することが重要です。また、探索的テストと UX/ユーザビリティ テストは、その特性上、自動化できない、あるいは自動化すべきではないテストであるため、時間を掛けて実施してください。
（この記事は、開発元 Ranorex 社 Blog 「10 Best Practices in Test Automation #1: Know What to Automate」2018年4月18日の記事を元にしています。）
