2024.04.17
これまでの記事を読まれた皆さんは、自動化導入のノウハウをご理解いただいたと同時に、初期に費用も工数も大幅にかかりそうと感じられたのではないかと思います。実際、テストの自動化導入における失敗事例は確実に存在しますが、反対にどのような結果が成功と言えるでしょうか。
私は、満足できる費用対効果を得られたら「成功」だと考えています。ただし、結果が出るまでには、多少のまとまった期間が必要です。つまり、自動化が成功するか失敗するか、ある程度の時間とコストをかけないと分からないことがあるのです。
仮に、近い未来に費用対効果が向上するとの確証を得られていれば、確固たる信念のもとで継続できるでしょう。しかし、見切り発車で自動化導入をすすめ、本当に実現できるのかわからず、途中で挫折してしまい、費用だけでなく時間も無駄にしてしまったというような、とても残念な経験をお聞きすることがあります。
そこで第3回となる本記事は、遠回りをしないための策として、費用対効果を最大限に得られるか否かの実現可能性を調査する際のポイントをご紹介いたします。
「成功する自動化導入」の連載では、ソフトウェアテストの自動化を導入するためのポイントを紹介してきました。
第3回では、ソフトウェアテスト自動化のフィジビリティスタディ（実現可能性の調査）について解説します。
- もくじ
1．フィージビリティスタディとは？
フィージビリティとは、いわゆる「実行・実現の可能性」を指します。また、「プロジェクトの実現可能性がどの程度かを事前に調査すること」も意味します。
テストの自動化を成功させるためには、多少なりともコストがかかります。たとえば、有償の自動化ツールを購入する場合には、初期投資として購入料、次年度より年度別に更新料がかかります。
また、ツールの有償/無償に限らず、開発工数等の別途コストが必ずかかります。自動化実装は、手動テストに比べて３～４倍の工数がかかると言われており、メンテナンス工数もかかります。
時間とコストをかけたのに、結果的に費用対効果が得られなくてせっかくの投資が無駄になってしまうこともあり得ます。また、ソフトウェアテストの自動化によって効果が得られる可能性があるのに、失敗した時のことを考えて導入になかなか踏み切れず、機会損失してしまうことも考えられます。
そこで、対象のシステム製品が自動化にどの程度向いているか、テスト自動化の効果がどの程度得られるか、フィージビリティスタディにより定量的数値で把握してから、テスト自動化を本式に推進することをお勧めしています。
テスト自動化環境を1ヵ月で構築し、効果検証する「フィージビリティスタディ」
テスト自動化に踏み切りたいが、導入コストに対して成果が出るのか確信を持てない。自動化したスクリプトをメンテナンスできないなど、テストの自動化プロジェクトの懸念はありませんか。「フィージビリティスタディ」では、実際に自動テスト環境を構築し、効果・プロジェクトに対する自動化適正を評価・検証するフィージビリティスタディ（効果検証）で、自動化の効果を見える化します。
2．フィージビリティスタディの主な4つの手順
フィージビリティスタディの主な手順は以下の通りです。
- 手順1. 既存のテストプロセスに対して、自動化が適しているかを量的数値で採点する
- 手順2.「自動化が適していそうなテストケース」を選定する
- 手順3.「自動化が適していそうなテストケース」を実際に実装してみる
- 手順4. 自動化の効果を評価する
それぞれ詳しく解説していきます。
手順1. 既存のテストプロセスに対して、自動化が適しているかを量的数値で採点する
まずは、既存のテストプロセスに対して、自動化が適しているかを量的数値で採点するという手順です。
以下の4つのポイントを採点していきましょう。
- 仕様の正確さ（資料の有無・更新の必要）
- 仕様の複雑度（テストケースの有効性）
- オブジェクト識別可能なIDの有無（メンテナンスコスト軽減率）
- 製品のリリース頻度/テストの実行頻度（コスト削減率）
仕様の明確さ (資料の有無・更新の必要）
自動テストに限らず、手動テストでも機能仕様書は必要です。当たり前ですが、テストの自動化は定義したことしかできません。仕様が不明確のテストケースは作成できません。あくまで把握できた仕様しかテスト対象にできないのです。
だからと言って、仕様理解した一人だけでテスト自動化を進めるのは、とても困難です。大きなシステムともなれば、数名または数十人で自動化にあたる場合があります。その際、複数人で仕様を理解するためには、仕様レビューを行うための資料が必要不可欠であり、認識のズレを最小限にとどめるための必須アイテムは機能仕様書といえます。
代わりのものとして、手動テストのテストケースから拾うことも可能ですが、テストケースが膨大過ぎるため、簡潔にまとめられた資料を別途準備する方が更新しやすく管理しやすいです。
ドキュメント作成やその更新作業は、地味な作業だと思いますがとても重要視しています。そのため、開発者と検証者が異なる場合には、機能仕様書を作成されることをお勧めいたします。
もし、ドキュメントに組織基盤に問題がある場合には、どのような資料なら作成できそうか、どのような組織体制にしたら資料の更新がスムーズになるかを検討してみましょう。
仕様書にはざっくりしたものから詳細にまとめられているものまで、さまざまなレベルがありますが、数か月前、数年前から更新されていない資料では使えない場合が多いです。資料は生ものであり、更新しなければ腐ってしまうということを理解してください。作成したら終わりといった代物ではなく、日々更新し、育て上げ、そして最新であることを維持していくものです。
したがって、資料の有無だけではなく、その資料が更新されているか確認してみましょう。もし資料に問題を感じた場合には、自動化導入をよい機会とし、自社の体制にとって可能な資料作成とはどういった手段か、どこまでなら仕様の整理ができるかを前向きに検討してみてください。
仕様の複雑度（テストケースの有効性）
GUI上の操作だけで完結できるテストケースと、DBやファイルなどの外部的要因が関与する割合を比較してみましょう。GUI上の操作だけで完結できるテストケースとは、GUI上のオブジェクトから実行結果としてOKかNGかを判別できるテストケースを指します。
このようなテストケースであれば、GUI上の操作を容易に記録することできる他、操作の再現性も高いです。そのため、高い開発スキルを必要とせず、比較的容易に自動化の実装が可能で、費用対効果を向上させやすくなります。
システムの特性やツールの機能にも依存しますが、目安として7割以上がGUI操作で完結できる場合、自動化に向いていると判断できます。
このチェック項目では、スクリプトを使用せずに自動化できるテストケース割合を算出しましょう。
オブジェクト識別可能なIDの有無（メンテナンスコスト軽減率）
オブジェクトとは、ラベル・テキストボックス・チェックボックス・ボタンなどを指します。ここでは、すべてのオブジェクトに対して、識別可能な唯一無二の他と被らないIDが付与されていることを確認しましょう。
識別可能な唯一無二の他と被らないIDが付与されていることで、オブジェクトの識別レベルが格段に向上します。
これらオブジェクトを正確に識別できない場合、同じ操作をしても同じ結果とならず、メンテナンス工数もかさみます。
有償ツールは認識できる確率が高いですが、機能の追加や修正によってオブジェクトの順序が変わってしまった場合には、識別エラーが生じる場合があります。正しく識別できなくなってしまうというリスクは、回避しておくべきでしょう。
この指標はメンテナンスコストの低減率にもつながるため、もしオブジェクトIDが被っている場合にはオブジェクトIDの振り直しをご検討ください。
製品のリリース頻度/テストの実行頻度（コスト削減率）
よい費用対効果を得るためには、実装した同じスクリプトを何度も何度も繰り返し実行できるかが、大きなポイントの１つです。例えば、数年に1回しかリリースしないような製品は自動化による費用対効果は得にくいため、自動化に適さない製品と言えます。
年に数回のリリースがあり、何度もテストを実行する可能性がある製品を大前提として選定してみましょう。
手順2.「自動化が適していそうなテストケース」を選定する
手順1.で自動化に適しているという評価が得られたら、次は自動化に適したテストケースを選びましょう。
この手順で選定すべきポイントは以下の2点です。
- 仕様変更の少ないテストケースを選ぶ（改修リスクの削減）
- 簡単に実装できそうなテストケースを選ぶ（実装工数の削減）
仕様変更の少ないテストケースを選ぶ（改修リスクの削減）
まず、選定対象としたいのは基本機能です。操作マニュアルに記載されているような主に使われる機能です。その中で、仕様変更が少ないであろう機能を選択します。
簡単に実装できそうなテストケースを選ぶ（実装工数の削減）
手順1の「仕様の複雑度(テストケースの有効性)」の結果を考慮して、GUI操作のみで完結できそうなテストケースを優先的に自動化対象とされることをお勧めします。例えば、データ登録に時間を要する場合、条件によって結果が多々異なる場合等は自動化に向いていないため、自動化すべきではないです。
初期は工数がかさみます。初期段階から躓くことがないように、実装が困難であろうテストケースは後回しにしましょう。
手順3.「自動化が適していそうなテストケース」を実際に実装してみる
次は実際に自動化に適したテストケースの実装です。範囲を絞って実装してみてください。
ポイントは以下の3点です。
- 実際にいくつかのスクリプトを実装してみる（ツールの有効性）
- 実装しやすいテストケースを見極める（工数見積もりの指針）
- 画像比較はできる限り使わない（改修工数の削減）
実際にいくつかのスクリプトを実装してみる（ツールの有効性）
時間を要する作業だとは思いますが、とても重要なポイントです。第2回の「ツール選定の基準」でもお伝えしたとおり、実際に使ってみないことには実装のしやすさ、大変さ、チューニングの必要度、再実行の確実性を判別できないからです。
特に基本的機能は必ず実装してみることをおすすめします。
実装しやすいテストケースを見極める（工数見積もりの指針）
「簡単に実装できそうなテストケース」が本当に簡単に実装できるのか、根拠を得ることが大切です。実際に実装してみると、案外できなかったりするからです。
実装してみることで初めて、「簡単に実装できそうなテストケース」の選定基準が明らかになる場合があります。
実装した結果（使用した工数、苦戦度合など）を定量的に比較していきましょう。
画像比較はできる限り使わない（改修工数の削減）
過去にWindowsアップデートによりフォントが微妙に変わったことがありました。
OSやOSのバージョンが変わると、日々の些細なOSのアップデートによっても、GUIが変わる場合があります。また、機種や画像解像度によっても、GUIが変わる場合があります。GUIに差異が生じる要因は数多く存在するため、些細な変化によるNGの多発につながる可能性があります。
これら要因ごとにすべてのキャプチャー画像を用意しておくことはとても困難であり、現実的ではありません。
自動化ツールの中にはピクセル単位または％の指定により合致度合を微調整できるツールもありますが、合致度合を低くした場合にはNGの見落としにつながる可能性があります。安易な画像比較の使用は画像の取り直し作業を増やし、後々メンテナンスに苦しむ可能性がありますので、画像比較を使用する場合にはリスクを十分に考慮した上での使用をご検討ください。
以上を踏まえ、画像比較でしか実装できない場合を除き、極力使用しないことをお勧めしています。
手順4. 自動化の効果を評価する
最後に、実際に自動化に適したテストケースを実装してみた結果、正誤の判定が可能であること、数回実行しても結果が正確であること等、自動化による効果を念入りに評価します。
主なポイントは以下の3点です。
- エラー箇所の特定をする（改修しやすさ）
- 実際にいくつかの環境で実行してみる（対象システムの自動化適合性）
- 何度も実行してみる（ツールの正確性）
エラー箇所の特定をする（改修しやすさ）
実装直後、エラーは必ず起きます。エラーログを参照して、エラー箇所の特定がしやすいか否か、修正しやすいか否かも判断基準にしてください。実際にこの作業のしやすさが工数削減に大きく影響します。
実際にいくつかの環境で実行してみる（対象システムの自動化適合性）
いくつかの環境で実行してみましょう。
なぜなら、実装した環境と実行する環境が異なる場合、想定した通りに動作せず、想定した結果が得られないことがあるからです。
有償ツールであれば、微調整の機能が備わっていることが多いですが、チューニングしても解決しない場合があります。
何度も実行してみる（ツールの正確性 ）
毎回同じ結果になることを確認してください。条件が足らない場合、定義が甘かった場合等、時に同じ結果とならない場合があります。数回実行しても結果が正確であることはとても重要です。
まとめ
本記事では、テストの自動化導入を成功へ導くための「テストの自動化に対するフィージビリティスタディ」の秘訣をご紹介しました。
テストの自動化を導入して、すぐに効果を得られる部分もあるでしょう。しかし、満足できる費用対効果をえるためには時間を要します。そのため、根拠を得るためにも、「フィージビリティスタディ」を行うことをお勧めします。
導入前に行うことで 「自動化導入に対する課題」 と 「自動化導入で得られる効果」 を十分に理解し、正しい導入目的を定め、自動化に適した導入基盤を整えることができます。
また、フィージビリティスタディを実施すれば、テストの自動化にどの程度向いているのか、課題・問題点にどう対応したらよいのか、明確になり、導入の判断を的確に下すことが可能になります。
「導入前に、もっと調査しておけば良かった・・」と後悔しないためにも「テストの自動化に対するフィージビリティスタディ」を実施して、テストの自動化を成功へと導きましょう。
次回は、テストの自動化導入に対する「戦略の必要性」について解説したいと思います。
ローコードテスト自動化ツール T-DASH
T-DASHはWebアプリケーションの動作確認・検証をコードを書かずカンタンに作成・実行できるテスト自動化ツールです。
初期設定からテストの実行まで、T-DASHのすべての機能でコードを書く必要はありません。そのため開発を担当していない非エンジニアの方でも手軽にご利用いただけます。
他のテストツールを導入している企業さま、まだ自動化ツールを試してみたことがない企業さまもこの機会にT-DASHにぜひ触れてみてください。
