テスト自動化をサクサク進めるためのWebマガジン「SAKUTES(サクテス)」 » テスト自動化ツールの導入におけるフィージビリティスタディとは?

テスト自動化ツールの導入におけるフィージビリティスタディとは?

テスト自動化をサクサク進めるためのWebマガジン「SAKUTES(サクテス)」 » テスト自動化ツールの導入におけるフィージビリティスタディとは?

テスト自動化ツールの導入を検討する以前のテーマとして、まずは「何をもってテスト自動化に成功したと判断するか」という根拠が必要です。しかしながら、テスト自動化の成功・失敗を判断することは、決して簡単ではありません。なぜならば、テスト自動化の実装から結果を得るまでには、ある程度の時間と工数を要するからです。

ある程度の時間と工数をかけ、最終的に一定の費用対効果が得られたならば、成功と判断します。あるいは、実装当初は費用対効果を感じられなくても、将来的に高い確率で費用対効果を得られる予感があるのであれば、「まずは良し」とみなすべきでしょう。

逆に、テスト自動化システムを実装してみたにも関わらず、現在も将来も費用対効果を見込めないならば、残念ながら失敗と判断せざるを得ません。

一定の時間、工数、コストをかけて行うテスト自動化だからこそ、高い確率で成功に導く必要があります。そのために必要となる考え方や手順が、当ページでご紹介するフィージビリティスタディです。

フィージビリティスタディの考え方と手順

フィージビリティスタディの「フィージビリティ」とは、「実現可能性」という意味。ここに「スタディ」という言葉が加わり、全体で「プロジェクトの実現可能性に関する事前調査」という意味になります。 どのようなプロジェクトにおいてもフィージビリティスタディは大事なプロセスとなりますが、時間・工数・コストが膨大で、かつ失敗リスクもあるテスト自動化においては、特に大事な考え方になると覚えておきましょう。

なぜフィージビリティスタディが大切なのか?

テスト自動化を成功させるためには、一定のコスト工数がかかります。
たとえば、テスト自動化の有償ツールを購入すれば、当然、購入費用や更新料などがコストとして発生します。あるいは、無償ツールを利用した場合でも、開発工数のコストが確実に発生します。

また、有償・無償のいずれのツールであっても、テスト自動化ツールの実装に至るまでの工数は、手動テストの3~4倍ほどかかります。
ところが、膨大なコストや工数をかけた一方で、中には費用対効果を得られず、一連のプロセスに投じたコストも工数もムダになってしまうケースは絶えません。逆に、テスト自動化が成功に向かいつつあるにも関わらず、最終的な失敗リスクを恐れるあまり、実装に踏み切れないケースも少なからず見られます。

もちろん、フィージビリティスタディの結果で「実現可能性が高い」と判断された場合でも、必ずしも100%成功するとは言い切れません。ただし、しっかりとフフィージビリティスタディを行えば、成功可能性を大きく高めることはできます。
コスト・工数・時間をムダにしないためには、フィージビリティスタディが大事なポイントの一つであると理解しておくべきでしょう。

以下、フィージビリティスタディの具体的な手順について確認します。大きな流れは次の通りになります。

  1. テスト自動化の適性を量的数値で判定する
  2. テスト自動化の適性が高いテストケースを選ぶ
  3. テスト自動化の適性が高いテストケースを実装する
  4. テスト自動化の効果を判定する

無償ツールでテストを自動化する場合の注意点を見る

テスト自動化の適性を量的数値で判定する

まずは、テスト自動化の適性を客観的な量的数値で判定します。判定には以下の4つのポイントがありますが、それら全てを満たしている場合には次のプロセスへと進むことができます。1つでも満たしていない場合には、ここで一旦、修正を図る必要があるでしょう。

明確な仕様を用意しているかどうか

テスト自動化ツールは、仕様で定義したことしか実行できません。そのため、仕様が不明瞭な場合のテストケースについては、そもそも適性の判定自体が不可能となります。

一般にテスト自動化プロジェクトを進めるためには、複数のスタッフが共同で作業を行います。それら複数のスタッフに認識のズレが存在しては、プロジェクトの流れに齟齬が生じる可能性があるので注意してください。

小さな齟齬が結果として大きなものへと発展する恐れもあるため、プロジェクトを進める上では、担当する全スタッフが正確に仕様を共有している必要があります。そのためには、全体が共有できる明確な機能仕様書を用意しておくことが非常に大切です。

また、仕様書は生ものなので、更新を怠ると使い物になりません。仕様書は、日々更新しながら育てていくもの、という認識を全体で持ちましょう。

仕様が複雑でないかどうか

GUI操作のみで完結するテストケースと、ファイルやDBなどの外的要素が必要となるテストケースを明確に分け、それぞれの比率を確認してみてください。一つの目安ですが、全体の7割以上がGUI操作のみで完結するならば、テスト自動化の適性があると判断して良いでしょう。

GUI操作のみで完結するテストケースであれば、GUI操作を容易に保存することが可能になります。加えて、操作の再現性が高くなります。結果として、大きなコストや工数を要せず自動の実装が可能となるため、最終的な費用対効果の向上へとつながることでしょう。

オブジェクトを正確に識別できるかどうか

オブジェクトとは、ボタンやチェックボックス、テキストボックス、ラベルなどの総称です。これらオブジェクトの適性を満たすためには、全てのオブジェクトに対して「識別可能で他の被らない唯一無二のID」が付けられている必要があります。

もし、各オブジェクトに「識別可能で他の被らない唯一無二のID」が付けられていなければ、各オブジェクトを正確に識別できない可能性があるため、同じ操作を行っても同じ結果になる保証はありません。

有償ツールを利用すれば各オブジェクトを識別できる確率が上がるものの、機能の追加や修正などによりオブジェクトの並びが変更された場合には、やはり識別エラーが生じるリスクがあるでしょう。

各オブジェクトのIDを確認し、重複している場合には早急にIDの振り直しを行うことが必要です。

同じプログラムをどの程度の頻度で使うか

同じプログラムを実行する頻度が高ければ高いほど、当然ながら費用対効果は上がります。そのような製品であれば、自動化に適していると言うことができるでしょう。
逆に、数年に1度しか実行する予定がない製品については、費用対効果が下がるため、あまり自動化には適していません。

自動化を検討する製品については、その製品における自動化の実行頻度(年に数回のリリースする予定ならOK)を確認するようおすすめします。

テスト自動化の適性が高いテストケースを選ぶ

ここまでのプロセスを経て「テスト自動化に向いている」と判定できた場合には、次に、テスト自動化の適性が高いテストケースの選定へと入ります。テストケースの選定におけるポイントは次の2点になります。

基本機能の仕様変更が少ないかどうか

一般的な「操作マニュアル」などに記載されている基本機能を確認し、その仕様変更の頻度が少ないと予想されるテストケースを選択しましょう。

逆に、もし基本機能の仕様変更の頻度が高いテストケースを選んでしまうと、プログラム改修の頻度も高くなってしまうため(改修リスクの増大)、相対的な費用対効果が下がる可能性が生じます。

簡単に実装できそうかどうか

上述した「仕様が複雑でないかどうか」の判定結果を基に、GUI操作のみで完結できる比率が高いテストケースを選定しましょう。

逆に、もしGUI操作のみで完結できる比率が低いテストケースを選んでしまうと、データの登録に時間を要したり、条件によって結果が異なったりなどする恐れがあるため、それらへの対応で費用対効果が下がる可能性が生じます。

なお、いずれのテストケースを選定した場合でも、初期段階では相応の工数を要すると理解しておくようにしましょう。初期段階でのプロジェクト挫折を避ける意味でも、まずは実装に不安を感じるテストケースについて、いったん候補から外しておくことが賢明です。

 テスト自動化の適性が高いテストケースを実装する

ここまでの段階をクリアしたら、いよいよ実装による確認段階へと入ります。机上で「良し」と判定されたテストケースであっても、実装してみなければ分からないリスクが潜在していることは珍しくありません。以下3点のポイントを押さえながら、慎重に実装テストを行っていきましょう。

候補となる複数のスクリプトを実装してみる

実際に実装をしてみなければ、本当に適性があるかどうかを判定することはできません。候補となる複数のスクリプトを選択したら、一つ一つを実装し、各スクリプトにおける全体的な工数、再実行の確実性、チューニングの必要性などを判定してみてください。 とりわけ基本機能の部分については、必ず実装してみるようにしましょう。

「実装しやすさ」の根拠を数量で判定する

「これなら実装しやすそうだ」という印象だけで決めるのではなく、本当に実装しやすいのかどうかの根拠を、数量で明確にすることが大切です。実装しやすそうな印象のテストケースであっても、実際に実装してみた結果、実装しにくいテストケースであることが明らかになることがあるからです。

「実装しやすさ」の根拠を得るためには、実際に要した工数や技術的な難度などを数値化する必要があります。可能な限り、数値のみで「実装しやすさ」を判定するようにしましょう。

画像比較は使わないほうが無難

画像比較でしか実装ができない場合を除き、基本的には画像比較を使わないようおすすめします。理由は、各種の理由でGUIが変わり、結果として作業工数が増大する恐れがあるからです。

たとえば、日常的に行う小さなOSのアップデートであっても、GUIが変わることがあります。あるいは、画像解像度や機種の違いによっても、GUIが変わる場合があります。その他にも、GUIが変わってしまう要素は多く存在します。これらの要素ごとに全てのキャプチャを保存して対応することは、工数の視点から現実的ではありません。

安易に画像比較を使用すると、画像の取り直し作業やメンテナンスの工数を増やす恐れがあります。画像比較を使用する場合には、それらのリスクを十分に考慮する必要があるでしょう。

テスト自動化の効果を判定する

複数のスクリプトを実装した上で、それぞれのテストケースの効果を判定します。希望的な判断を一切排除し、数量化された結果のみを基準に判定しましょう。判定のポイントは次の3点になります。

エラー箇所を特定しやすいかどうか

実装した直後には、必ずと言って良いほどエラーが起こります。この場合、エラーが起こること自体よりも、エラーの箇所を特定しやすいかどうか、また、特定したエラーを修正しやすいかどうかが大事なポイントになります。
特定と修正のしやすさは、のちの工数を大きく左右します。

環境を変えても正しく動作するかどうか

実行する環境が異なる場合、想定した結果を得られないことがあります。環境を変えて実行し、それぞれにおいて自動的に適合化されるかどうかを確認しましょう。

何度実行しても同じ結果になるかどうか

環境を変え、それぞれの環境で何度も実行してみてください。何度実行しても同じ結果を得られるかどうかを確認しましょう。同じ結果を得られない場合には、定義の甘さや条件の不足が潜んでいる恐れがあります。

まとめ

以上、フィージビリティスタディの考え方や具体的な手順について詳しく解説しました。「導入して失敗した」という結果に陥らないためには、十分なフィージビリティスタディが重要であることを理解できたでしょう。

フィージビリティスタディを通じ、「自動化に向いているかどうか」「自動化導入から得られる効果は何か」「自動化導入における課題は何か」を明らかにすれば、より的確に導入に向けた判断を下すことができます。テスト自動化の導入を検討する方々の参考になれば幸いです。

⽇本語のサポートが⼿厚い!
UIテスト自動化ツールを比較

ノンプログラミングで
⽇本語のサポートが⼿厚い

テスト⾃動化ツールを⽐較
商品名 Ranorex
(ラノレックス)
Autify
(オーティファイ)
商品タイプ パッケージ型

膨大なテスト工数を
削減したい企業向け

SaaS型

初期費用を抑えて
導入したい企業向け

対応テスト
  • デスクトップ
  • webアプリ
  • モバイルアプリ
  • デスクトップ
  • webアプリ
  • モバイルアプリ
実行回数
の制限
制限なし 制限あり

400回/1000回/任意 ※プランにより異なる

日本語サポート 導入後のセミナーが充実! ヘルプサイトが充実!
体験版 14日間 14日間

※Googleで「テスト自動化ツール」と検索し上位表示されたパッケージ型、SaaS型のテスト自動化ツール21種類の中から、(1)クロスデバイス、マルチブラウザに対応し、(2)日本語のサポートがあり、(3)ノンプログラミングでシナリオ作成が可能なツールをピックアップ(2021年11月1日調査時点)。パッケージ型、SaaS型それぞれの代表商品を選出しました。

【代表商品の選出基準】
☆パッケージ型:上記の条件の通り。
☆SaaS型:上記の条件に加え、公式サイト上に導入事例がもっとも多かったツールを選出。