Ranorexのテスト構成の作り方
Ranorexをこれから導入される方や、現在利用中の方に、以下のような質問をいただくことがあります。
- どのようにテストケースを作成していけばいいのか？
- テスト構成の正解やモデルはあるのか？
- ソリューションやプロジェクトはどのように分けたらよいのか？
これらの質問は、テスト要件やテストの規模、シナリオ作成者の人数、テスト対象アプリの仕様といった様々な状況によって異なるため、残念ながら一律の答えはありません。しかしヒントはあり、Ranorexのテスト構成に関連するトピックを知っておくことで、より適した構成を効率的に作ることができます。そこで今回は、テスト構成の考え方と、テスト構成のタイプについて解説してみたいと思います。
はじめに：テストデザインの三原則
テスト自動化において、作成したテストを繰り返し使用することでコストパフォーマンスが出る、という点はテストの内容や規模にかかわらず共通しています。したがって、テスト構成を作るにあたっても、長期間の運用に向けメンテナンスや担当者変更に耐えうる構造になっているか？というポイントは重要です。
「誰が見てもわかりやすい」「メンテナンスしやすい」テスト構成を作成するために、以下の原則を頭に置いておきましょう。
1. シンプルにする (Keep it simple)
テスト構成、テスト ケース、モジュール、その他すべてについて、可能な限りシンプルに、必要に応じて複雑にしてください。2. ロジカルにする (Keep it logical)
テスト構成、テスト ケース、モジュールなどは、テスト要件と照らし合わせて意味のあるものでなければなりません。項目を不用意に分割しないでください (例: ユーザー名/パスワードの入力と、”ログイン”ボタンのクリックを、別のモジュールに分けている)。あるいは、別々にすべきものを混ぜないでください (例: Web ショップのエンドツーエンドのワークフローを、1 つのモジュールにまとめている)。3. 怠ける (Be lazy)
Ranorex ユーザーガイド：構成に関するベスト プラクティス
可能なものはすべて再利用してください。常に再利用性を意識してください。
テストスイートの構成
Ranorexでテスト構成を決める上で、まずは現行のテスト仕様書をそのままRanorexのテストスイート上で再現するところから考えてみてください。
１つのケースに対し明確な検証結果が存在する形になっている場合、仕様書のケースをそのままRanorexのテストケースとして作成し、検証内容をValidateアクションで作成するのがよいでしょう。以下の例では、各行をテストケースとして作成し、スマートフォルダを使って「画面」ごとでテストケースをまとめています。
★Point
Ranorexレポートの右上に表示される円グラフはテストの成功率を表しており、テストケースの数を分母として算出されます。これまでテスト仕様書で、ケース数からバグの発生率を算出されている場合は、同じように、テスト仕様書の1ケースに対しRanorexのテストケースを作成することで、この円グラフを利用できます。詳しくは、ユーザーガイドをご参照ください。
一方、以下のようなケースでは、そのままRanorexのテストスイートには落とし込めないため、工夫が必要となります。
- テスト仕様書の１つのケースが他の詳細なテスト仕様書と紐づいている
対応例：詳細なテスト仕様書をもとにテストケースを構成し、スマートフォルダを利用して、それらの細かいケースをまとめる - Ranorexでは確認できない項目が含まれている
対応例：確認(検証)事項を具体化する
手動テストで実施する内容と自動化する内容を分ける など
構成のタイプとその選択方法
Ranorexのユーザーガイドでは、以下の3つのテスト構成タイプについて紹介しています。
- ソリューションベースの構成
テストの種類ごとにソリューションを分ける構成。大規模で複雑なテストに適している。
ソリューションごとでそれぞれの設定、リポジトリ、レコーディングモジュールなどのファイルが存在するため、それらの管理が課題となる。 - プロジェクトベースの構成
推奨されている構成。1つのソリューションにテストをまとめることができ、メンテナンスが楽におこなえる。 - テストスイートベースの構成
テストの種類ごとにテストスイートを分ける構成。小規模なテストに向いている。プロジェクトベースと同じくファイルがまとまっているため、メンテナンスがしやすい。一方で、１つのプロジェクトにファイルが増えすぎてしまう傾向があり、テストのパフォーマンスに影響が出ることがある。
※詳細は、ユーザーガイド：構成のタイプとその選択方法をご参照ください。
これからRanorexを使い始める、あるいはまだRanorexに慣れていないという場合、１つのソリューションにファイルがまとまっているプロジェクトベースやテストスイートベースの構成が、使いやすさ/管理しやすさという観点で適しているといえます。
注意点として、プロジェクトあるいはソリューションに含まれる、リポジトリやモジュールをはじめとしたデータ量が多くなってくると、Ranorexそのものの動作が重くなってしまうことがあります。そのため、当初から大規模なテストを想定されている場合、テスト対象アプリの画面数や自動化する操作が多い場合には、ソリューションベースのテスト構成を検討した方がよいでしょう。
作成したテストは、後からプロジェクトや複数のソリューションに分割することも可能です。どの程度の規模になるか不明な場合は、まずはテストスイートベースで作ってみて、テストケースが増えてきたらプロジェクト/ソリューションベースに移行する方向で取り組んでみてください。
具体的な分割の手順についてはこちらのBlog記事をご参照ください。
複数人でテストシナリオを作成する場合の注意点
テスト構成を考える上でもう一つ重要なのは、テストシナリオを何人で作成するのかという点です。複数人でテスト作成を行う場合、一般的なシステム開発時と同じく、競合の発生に注意が必要です。
前提として、複数人で作成を行う場合は担当者ごとに編集するテストやモジュールを決めるなど、競合自体がなるべく発生しない運用を推奨しています。Ranorexではノーコードでシナリオ作成ができますが、自動生成コードで競合が発生した場合、マージが複雑になってしまうケースが多いからです。
複数人での開発を想定している場合、小規模のテストでも、あえてプロジェクトベースのテスト構成を選択し、担当者ごとに作成するプロジェクトを分割するという方法も有効です。
まとめ
今回は、Ranorexのテスト構成についてご紹介しました。テクマトリックスが提供しているプレミアムサポートでは、このようなテスト構成に関するご相談にも対応しております。より具体的なアドバイスが欲しいといったご要望がございましたら、お気軽にお問い合わせください。
