プログラミングスキルなしでテストを自動化する方法 – 実行編

この記事は、プログラミング経験のない手動テスターによるテスト自動化に関する、3回にわたる連載記事の2回目です。この記事では、自動テストの実行領域で手動テスターが実践できることについて説明します。

まだ、第1回「準備編」をお読みでない場合、この「実行編」の前にお読みいただくことをお勧めします。

  • テスト自動化の領域
  • テスト自動化でどのようにオブジェクトが認識されるかを理解する
  • オブジェクトリポジトリの操作と整理
  • 一からテスト自動化アクションを構築する
  • 次回に向けて

テスト自動化の領域

ここでは、手動テスターが自動化を始めるにあたって検討すべき3つの領域について概要を説明します。準備、実行、分析各領域に、手動テスターがすぐに貢献できる3つの固有のセクションがあります。このブログ記事は、2つ目の領域である「実行」を取り上げます。 

テスト自動化でどのようにオブジェクトが認識されるかを理解する

これは機能テストアナリストが理解するべき重要な領域であり、テスト自動化担当者やテスト自動化ソリューションが、どのようにオブジェクトやコントロールを識別するかに関連します。「アクセシビリティ」レイヤーという、一部にはなじみがないかもしれない用語が使用されます。この用語が指すものは、開発チームからのアクセスを可能にする属性やプロパティです。たとえば、オブジェクト名、オブジェクトインデックス、インナーテキスト、キャプション、ラベルなどが該当します。テスト自動化ソリューションは、これらのプロパティの1つに着目して、テストステップが繰り返し成功するよう正確にオブジェクトを識別します。

テストを毎回適切に再現するために、テスト自動化アナリストがどのように作業するか、またテスト自動化ソリューションがどのように機能するかを理解するのは、非常に重要です。

オブジェクトリポジトリの操作と整理

アプリケーションには、多数のフォーム、ウィンドウ、画面が含まれる場合があります。さらに、フォームには30個以上のコントロールやオブジェクトが含まれていることもあります。自動化ソリューションがそれらのオブジェクトを操作する場合、オブジェクトリポジトリ自体が非常に大規模になる可能性があります。オブジェクトリポジトリとは、テスト自動化ソリューションがクリックしたり、押下したり、データを入力したり、その他のイベントを実行する対象となるオブジェクトのコレクションです。

前のセクションの例で言えば、テスト自動化ソリューションが使用する属性があり、その情報はリポジトリに格納されます。この情報は一元化されているため、別のテストを記録したり作成しなくとも、同じオブジェクトを操作することができます。しかし、リポジトリには、さまざまなコントロールがずらりと表示されており、わかりやすいオブジェクト名や他のプロパティが付けられていることもあれば、そうでない場合もあります。たとえば、アメリカ合衆国のすべての州に対応するラジオボタンがある場合、RadioButton1 から RadioButton50のようなオブジェクト名が付けられているかもしれません。

そこで、オブジェクトに関する最初のレコーディングやコーディングを行った後、オブジェクト名がわかりにくければ、編集してより意味のある名前に変えることが推奨されます。Ranorexには、この作業を支援するRanorex Spyというオブジェクト探索ツールがあります。何週間、ときには何か月も前に行ったテストのオブジェクト名を知るために、オブジェクトリポジトリを確認し直すようなことは、できれば避けたいでしょう。

一からテスト自動化アクションを構築する

どんな作業にも言えることですが、テストの自動化を始めるにあたって重要になるのは計画です。テストをどのような構造にするかをあらかじめ思い描いておくことは、必須ではありませんが、有益です。たとえば、次のような自動テストケースを構築するとします。

Login TC – Administration TC – Work Order TC – Checkout TC

もし、Administration TCに追加したいステップがあり、それがWork Order TC 、最終的にはCheckout TCにも影響を与えるとしたらどうでしょうか? 再度テストケースを記録したり、コードを作り直さなければならないのでしょうか? そうではありません。

なすべきことは、最初から最後まで、質の高いレコーディングになるよう集中することです。適切なオブジェクトをクリックし、ステップが無駄なく流れるようにします。そうすれば、テスト自動化アナリストは、柔軟性が高く、新しいテストロジックを追加しやすいテストケースを構築できるため、機能テストアナリストは、新たなテストケースを作り直す必要はなく、必要に応じてテストケースを修正できるでしょう。手動テストケースに新たなテストステップを追加する際に、一からテストケースを作成し直す必要がないのであれば、自動テストケースでもその必要はないはずです。

次回に向けて

これで、手動テスターがテスト自動化を始める方法についての第2回、「実行編」は終わりです。次回は最後の「分析」を扱った記事になります。間もなく更新されますので、どうぞご注目ください。

(この記事は、開発元 Ranorex 社 Blog 「How to Automate Your Tests Without Programming Skills – Execution」2015年11月5日の翻訳記事です。)