ソフトウェア評価/検証(ソフトウェアテスト)テスト自動化ノウハウ

テスト自動化を失敗しないために

ソフトウェア開発のプロセスにおいて工数やコストの削減を目指し、検証業務のテスト自動化を検討されることが増えています。しかし、実際には思っていたほどの成果を出せなかったというお声も少なくありません。Sky株式会社が、長年のソフトウェア評価/検証業務に携わってきた経験を踏まえ、テスト自動化導入のポイントをご紹介します。

01 テスト自動化の検討

テスト自動化の導入を成功させるポイント

過剰な期待による自動化導入によって浮き彫りになる課題

ソフトウェア検証業務の各プロセスにかかるコストの削減を目的として、「テスト自動化」の導入を検討されるケースが増えています。しかし、実際に導入をしても「期待どおりのコスト削減が実現できなかった」というお声も少なくありません。
具体的には「自動化できる範囲が少なかった」「自動化の維持コストが高く、継続できなかった」「プロジェクトからの協力が得られず断念した」といった課題が挙げられます。これらは、自動化に対して過度な期待を持ち、現実に即さない目標を立てて自動化に取り組んでしまったことが原因となっている場合が多いのが実情です。

どうすればテスト自動化の導入に失敗しないのか

逆に言えば、「どのような目標を立て、自動化を導入すれば失敗しないのか」という観点が重要になるということです。テスト自動化は、決して“魔法の杖”ではないので「工数の大幅削減」や「コストを○%削減」を目標とすることは現実的ではありません。「手作業で行っているテスト作業のうち、一部でも自動化する」「本来やりたいことに着手できるよう、定常的なテスト作業を自動化する」といった現実的な効率化を目的として、自動化を推進するプロジェクトのほうが成功しているというのが、弊社が経験を通じて強く実感しているところです。
つまり、テスト自動化によって大幅に工数を削減するといった、過度な期待をすることなく「現在、定常的に行っている手作業を自動化する」ということが、テスト自動化の成功の近道だと言えます。

どんなテスト作業なら自動化できるのか

手作業のテストを自動化することが必須条件に

ソフトウェア検証業務の中で、手作業で行っているさまざまなテスト作業のうち、どのような作業であれば自動化に適しているのかを見極めることが大切です。例えば、個人のスキルに依存している作業の場合、それが手作業で行われていたとしても、対応者個人の判断によって結果が異なるため自動化することは難しいです。
一方、個人スキルに依存せず手順が確立されている作業は、自動化に適しています。手順が明確で、システム的に管理され、見える化している手作業であれば、あとは自動化に必要なツールを導入することで、比較的容易にテスト自動化を実現できます。

個人スキルに依存した属人的な作業は不向き
システム化され管理された作業は比較的容易

テスト自動化のために重要なこと

テスト自動化の導入のために必要な環境とは

ソフトウェア検証業務におけるテスト自動化を成功させるために「システム化され、適切に管理されている状態」が必要なのは前述したとおりですが、実際のプロジェクトの各工程がそのように管理されているケースは限られています。
しかし、トップダウンでこうした状況の改善が求められる上、改善ができなければ競合他社との差が広がり、時代の変化に取り残されてしまいます。だからこそ、テスト自動化を実現するための行動を起こすには、慌ただしい環境のなかで性急に物事を進めようとするのではなく、一つずつステップを踏んでいくことが大切です。以下のステップのうち、<レベル4>が実現できているのであれば、自動化はとてもスムーズに進みます。

テスト自動化のために重要なこと

テスト自動化の導入に失敗しないために

テスト自動化を推進するリーダーシップ

テスト自動化の導入を行うためには、周囲の環境も重要です。プロジェクトの計画当初から自動化の導入を検討し、各工程における導入するツールを選定した上で自動化を実施することは非常に難しいため、プロジェクトを進めながら残る予算の中で少しずつ自動化を進めるのが現実的です。しかし、その限りある予算を使って自動化を進めようとしたとき、思わぬ阻害が生じることもあります。

自動化をプロジェクト内で提案しても、多忙のため導入に必要な人員が確保できない。

どの工程のどの作業が自動化できるのかという具体的な議論が進まない。

専任の責任者を立てることができず、全員が片手間となり思うように進捗しない。

こうした状態を回避するためにも、自動化導入に際しては「強力なリーダーシップを発揮できる人材」と「プロジェクト関係者の賛同」があることが、欠かせない条件となります。リーダーは、プロジェクト全体で協力的な雰囲気を醸成した上で、システム化(見える化)ができていない部分があるならば、まずはそこから着手して改善を行い、その後に自動化に取り組むというフローを作る必要があります。


02 テスト自動化の準備

02 テスト自動化の準備

テスト自動化の導入時に直面する課題

費用対効果(ROI)の観点で考える

自動化への投資は、本当に回収できるのか?

ソフトウェア検証業務のコスト削減を目指してテスト自動化を導入しようとする場合、「○○回のテストを実施すれば」「あの機能やこの機能、すべてのテストが自動化できれば」「ROIの試算結果では」といった、仮定に基づいたお話を耳にすることが少なくありません。自動化ツールなどの導入にかかるコストは本当に回収できるのでしょうか?


ソフトウェア開発には変更や修正が発生することを前提に

ソフトウェアの開発においては仕様変更や修正はつきものです。これに伴って、後工程でのテストについてもテストシナリオの一部や全部を書き換えなくてはなりません。もし、自動テストのシナリオをメンテナンスするよりも、手作業でテストを実施するほうが工数をかけずに済むなら、テストの自動化は長続きしません。

こちらからテスト自動化のROIを簡単に試算できるシートをダウンロードいただけます。

関連資料ダウンロードページ

テスト自動化の効果を最大限に引き出すには

保守性が高いテストタイプを選ぶ

運用時のメンテナンスにかかるコストを抑えるため、自動化に適した「保守性が高いテストタイプ」を選ぶことが、テスト自動化の効果を最大限に引き出すことにつながります。つまり、“自動化が可能な”すべてのテストを自動化しようとするのではなく、まずは、“自動化に適した”テストに絞って自動化に取り組むことが重要です。

考えられるテストのイメージ

自動化できるテストと自動化に適したテストを整理せずに取り組むとROIが下がり、関係者のモチベーションや投資意欲も下がります。最初からすべてを自動化したり、適切なターゲットが見極められていない傾向があります。そこで「自動化に適したテスト」をいかに導出するかが重要です。

保守性が高い自動テストを構築するための考え方

システムテストの自動化を目指すエンジニアのバイブルとも称される書籍『システムテスト自動化 標準ガイド』(翔泳社:Mark Fewster 著 / Dorothy Graham 著、テスト自動化研究会 訳)には、以下のような記述があります。

  • テスト対象の将来的な変更による影響をできるだけ受けない、最も柔軟性のある形式にするべきである
  • テストケースの実行時間は最小化されるべきである
  • テストケースは可能な限り独立しているべきである
  • 命名規則は早い段階で採用すべきである
  • テストケースは可能な限り単純であるべきである
  • テストケースは正確かつ簡潔にドキュメント化されるべきである

特に、テスト対象の将来的な変更による影響を受けないためには、テストに対する理解が必要になるといえます。

ROIを低下させる保守性が低いテストの例

仕様の変更のたび、合否判定 の定義も更新する必要がある

例えば、下記のようなテストを自動化する場合、テスト自動化は可能ですが、「画像比較」機能などを駆使して対応しなければなりません。その際、わずかに画像が異なるだけでミスマッチを起こすことがあります。

  • 画面の表示崩れ(レイアウト崩れ、文字化け)がないことを確認する
  • メッセージエリアで文字のはみ出しや見切れが発生していないことを確認する
  • ステータスバーの色が、赤から青に変わっていることを確認する

これらのテストの場合、1ピクセル異なるだけでもミスマッチが生じたり、画像の解像度が異なると違う画像として認識してしまったりするため、合否判定のチューニングに手間がかかり、メンテナンスコストの増大は避けられません。
こうした事態を避けるためにも、導入前に注意が必要です。なるべくPoCを行うことで想定効果の見誤りを防ぐことが大切です。さらに可能であれば、客観的な評価ができるテスト自動化の有識者をプロジェクトに参画させ、ROIを低下させるような間違いを回避することが望ましいです。


03 テスト自動化の導入

将来を見据えて、拡張性も考慮する

「かゆいところに手が届かない」という問題

意外とやりたいことができない≒うまくいくとやりたいことが増える

「自動化に適したテスト」を抽出して実施したことで一定の成果が得られると、次のステップとして「自動化範囲の拡張」を検討することになると思います。しかし、自動化を行いたいと考えたテストの操作が、実は導入している自動化ツールでは対応できなかったということはよくあります。


標準機能では実現が難しい場合は、プロに相談することも選択肢の一つ

もちろん「できる」「できない」は用いる自動化ツールにもよりますが、例えば、次のようなUI画面テストが、自動化を試したくなる例として挙げられます。

こうしたテストは、ツールの標準機能では実施できなかったり、やりたい操作フローの途中までしか実現できないというケースが少なくありません。しかし、こうしたときも工夫次第で解決することが可能です。どうしても解決できないという場合は、自動化のプロに相談することも選択肢の一つです。

自動化を試したくなるテストパターン(例)

  • ライトが光ったことを確認したい
  • 外部接続機器の電源が入ったことを確認したい
  • DBのレコードの値を直接参照したい。データを書き換えたい
  • Android Debug Bridgeを実行してファイル転送を行いたい
  • batなどの戻り値をチェックしてOK / NG判定を行いたい

ツール単体では実現が難しい自動化の事例

工夫次第で「かゆいところに手が届く」ようになる

弊社がご相談いただいた事例をご紹介します。この案件は、Webカメラの電源状態に応じて、映像が正しく撮影できているかを確認したいというご要望でした。しかし、このケースでは自動判定が難しいことがネックでした。

ご要望

Webカメラの電源がONとOFFを繰り返したときに、電源がONになったときに映像が正しく撮影できている(黒画面にならない)ことを確認したい。


問題点

  • Webカメラ撮影映像(動画)は常に変化するため、通常は自動化ツールでの自動判定には不向き。
  • 単純な「期待値画像との比較」などの手法では、撮影の可否(OK / NG)判定ができない。

解決策

画像の「Average Hash」を比較する方法で判定を実現する。撮影した動画を連続した画像として保存し、連続した画像同士をAverage Hashアルゴリズムを用いて比較し、結果判定する方法を取り入れた。

連続した画像(ハッシュ値)が不一致ならば、映像が正常に撮影できていると判断し、テスト結果を「OK」と判定する。もし一致しているならば、映像が停止している(黒画面になっている)と判断して結果が「NG」だと判定する。

監視カメラネットワーク

テスト自動化ツールの単体機能では自動判定が難しい要望

テスト自動化ツールでは不足している機能を補う「アイデア」と「自作ツール」で自動化を実現

しかし、こうした対処は自動化運用時の保守メンテナンス性が低下するため、十分な検討が必要です。マニアックになり過ぎず、テスト自動化プロジェクト全体のROIを悪化させないバランスを見極めることが大切です。

柔軟にアイデアが組み込めるツールを選ぶ

ツールの柔軟性が導入後の活用の幅を広げる

最近は、多くのUIテスト自動化ツールがリリースされています。これらは適切に活用できれば、画面遷移系のテストには大いに活躍します。しかし、いざ使ってみると、さらに有効活用しようとすると、「画面がないモノ」に対するテストや、外部システムとの接続性を踏まえたテストが視野に入ってくるものです。ですから、外部プロセスが実行でき、後から柔軟にアイデアを組み込むことが可能なツールを選んでおけば、導入後に自動化の活用の幅は広がります。

テスト自動化ツール「SKYATT」

「SKYATT」とは

プログラミング知識不要で、使う人を選ばないツールです。Sky株式会社の25年以上にわたる評価 / 検証の実績を基に自社開発したテスト自動化ツールは、テスト自動化によるメリットを最大限に引き出します。

テスト自動化ツール「SKYATT」

04 テスト自動化の運用

業務系システムのテスト自動化を取り巻く環境

昨今、業務システムの開発や運用時のテストについて「自動化が推進されること」が増えてきていますが、システムの構成に依存する問題により自動化の適用がうまく進められないケースがあります。
その中の一例として、SPA( Single Page Application )開発が挙げられます。ユーザーに対してネイティブアプリのような操作感や、表現力を提供できるなどメリットの多いSPAですが、従来のWebアプリケーションのテスト自動化よりも準備に手間がかかったり、自動化適用範囲が狭くなったりすることがあります。
また、Salesforceやintra-martのようなPlatformが試行時にテスト自動化ツールが使えたとしても、個別のカスタマイズやシステム構成の変更などの影響を受け、当初の計画していたような広い範囲に使えず、計画どおりの費用対効果が得られないことがあります。

業務系システムのテスト自動化を取り巻く環境 業務系システムのテスト自動化を取り巻く環境

標準機能では実現が難しい場合は、プロに相談することも選択肢の一つ

SPA開発に限らず、Name属性やID属性に値が設定されないまま開発が進むことが多く、後々テスト自動化を進めていこうとした際に、操作対象箇所が特定できないことでつまずくことがあります。実は、テスト自動化がうまく運用に乗らない原因のほとんどがこのパターンです。
そのため、開発ライフサイクル全体として効率的になるように、後工程のテスタビリティ(テスト容易性)も考慮して設計・開発しておくことが重要です。この取り組みの有無により、プロジェクト全体のQCDは大きく変わってきます。

UIテスト自動化ツールの基本的な仕組み

例)

  • UI画面の中からテストとして操作したい対象(テキストボックスやボタン)を特定する
  • 特定した対象に対して「クリックイベントの発行」や「テキストプロパティに値を代入」を行う
業務系システムのテスト自動化を取り巻く環境 業務系システムのテスト自動化を取り巻く環境

最初の課題となるのは、上記「①対象を特定する」です。テキストボックスやボタン等、1画面の中で多数のアイテムが配置されている中で操作対象を特定するには、何らかの識別子が必要です。通常のテストの自動化においては、Name属性やID属性を頼りに対象箇所を特定しています。
例えば、ERPシステム 『SAP S/4HANA Cloud』は、すべての画面アイテムにIDを割り振るという画面設計思想により、基本的にはテスト自動化ツールとの親和性は高いといえます。

  • 2021年10月時点でSky株式会社製 UIテスト自動化ツール「SKYATT」での自動テスト操作を確認しています。
  • ご導入検討時は最新バージョンでの調査をお勧めします。ERPユーザー様にはPoCを実施の上、適合性をレポートさせていただきます。
SKYATTのお問い合わせ

このような、テスト自動化を進めやすく効果を得られやすいシステムについては、開発時やその後の運用テストにおいて「テスト自動化」を取り入れない手はありません。
しかし、前述の「操作対象を特定する」という課題を完全に避けて通れるテスト自動化ツールは存在しません。SPA ( Single Page Application )においては全般的に対処し、『 SAP S/4HANA Cloud 』などのERPにおいてはカスタマイズ箇所を部分的に対処しなければなりません。
また、後々のテストのために工数をかけてきちんとName属性やID属性を設定して準備しておくようなプロセスに、急に変更することは難しいと思われます。
このようなケースを考慮して、S k y株式会社では以下の4つのアプローチをご提案しています。

テスト自動化の4つのアプローチ

テスト自動化の4つのアプローチ テスト自動化の4つのアプローチ

1.テスト用の属性を設定する

Name属性やID属性の値を設定することは手間がかかりますが、先々にわたって生じるテストがスムーズに自動化されることを見据えると、結果としては効率的といえます。
しかし、すべての値を設定することが負担になる点が課題です。
そこで、まず繰り返し行うテスト(リグレッションテスト等)において、主要な箇所だけに絞って設定していくということが現実的です。
また、通常Name属性やID属性を使うのが一般的ですが、最近ではテスト用の属性として「data-testid」等を定義してユニークな識別子を設定する方法が広まりつつあります。
現時点では、テスト用属性に対応したツールが少ないながらも出始めているため、この方法を用いる場合は最初に使用できるテスト自動化ツールを選ぶ必要があります。

テスト用の属性を設定する

2.XPathを用いる

画面アイテムの構成上のインデックス値であるXPathを使う方法では、NameやID属性の値は不要となります。ただし、XPathは画面レイアウト変更に弱いため、レイアウト変更によりXPath値が変更された際にテストシナリオ上の画面アイテム識別子であるXPathも書き換える必要があります。このことから、画面レイアウト変更に対してXPath変更量が少なく済むように、画面レイアウト設計の工夫が求められます。
レイアウト変更が少ないシステムであれば、このXPathを用いた特定方法が適しています。

XPathを用いる XPathを用いる

3.操作対象識別に画像を用いる

テスト自動化ツールのアプローチとして、操作対象の識別に画像認識機能を用いる方法があります。これは、ボタンやテキストボックスなどの画像の一致性を自動で識別するやり方です。ただし、テスト自動化ツール側にこれらを実現するための機能が必要となり、一般的な自動化と比べると経験値やチューニングが必要となります。
しかし、一度仕組みを作ることで、自動テストシナリオのメンテナンス性や可読性に優れるメリットがあり、UI系のテスト領域であれば自動化適用範囲を広げることができます。

操作対象識別に画像を用いる 操作対象識別に画像を用いる

4.上記3つの手法を組み合わせる

これまでご紹介した手法のいずれかで課題をクリアできるケースもありますが、複数の手法を組み合わせて効率的に運用していくことも可能です。Sky株式会社では、テスト自動化コンサルタントが現状のテスト自動化状況を診断し、より効果的な方法をご提案させていただきます。
これから自動化を始めたいというお客様に対しては、弊社の今までの経験から最適な方法をご提案いたします。

PoCを行うことで最適なテスト自動化の実現方法が明確になります

お悩みのポイントを早期に解決するには、経験豊富な第三者の見解が有効です。
また、つまずきやすいポイントをあらかじめ知っておくことは重要です。結果的に、最短距離でのテスト自動化の実現を支援します。


実績紹介

情報機器

情報機器

対象システム
機器制御 / 撮影機能の遠隔操作アプリケーション
対応範囲
  • テストツールの選定、自動化フレームワークの開発
自動車(サプライヤー)

自動車(サプライヤー)

対象システム
各種ECU
対応範囲
  • 個別自動化システム開発、自動テストシナリオ作成
流通

流通

対象システム
POSシステム
対応範囲
  • OSSを用いた自動テストシステム開発、マニュアル類作成

関連資料ダウンロード

Sky株式会社のソフトウェア開発に興味を持ってくださった皆さまに向けて、各種資料をご用意しました。下記よりダウンロードいただけますので、ぜひご活用ください。

関連資料ダウンロードページ

関連コラム

お問い合わせ

ソフトウェア開発・評価/検証(ソフトウェアテスト)に関するご依頼・ご質問は、下記フォームよりお問い合わせください。弊社製品・サービスに関するお問い合わせは、各商品Webサイトより受けつけております。

パートナー企業募集

Sky株式会社では長期的なお付き合いができ、共に発展・成長に向けて努力し合えるパートナー企業様を募集しております。パートナー企業募集に関するご依頼・ご質問は、下記フォームよりお問い合わせください。

ページのトップへ