Facebook x

ジャンル

「成功するテスト自動化導入」のコツ① ~事前にやるべき5つの準備~
第1回 「成功するテスト自動化導入」のコツ
「成功するテスト自動化導入」のコツ 2024.04.17
x hatenabookmark
0

「成功するテスト自動化導入」のコツ① ~事前にやるべき5つの準備~

執筆: 宮北 裕子

バルテス株式会社 Web・IoT品質サービス事業部 マネージャー

これからテストの自動化を導入される皆さんにお聞きします。テストの自動化導入は簡単だと思いますか?

すでに導入された皆さんにお聞きします。テストの自動化導入は、滞りなく、計画どおりにサクサクできましたか?順調に費用対効果を上げられているでしょうか?

私は、医用システムを開発している会社に13年務めました。その間に検証部門や品質管理部門を立ち上げ、最終的にはテストの自動化導入を担いました。10年以上前からテストの自動化に興味を持ち、無償ツールを使ってパフォーマンス検証や負荷検証などを実施してきました。

そして、2015年に有償ツールの選定を本格的に開始し、2017年からテストの自動化を本格的に推進して、また実装担当者としても邁進してきました。振り返ってみると、自動化への過度な期待や、失敗、そこからの改善など学ぶことがたくさんありました。

そこで、本記事では、実際の経験から学んだ 『 テストの自動化導入を成功させるポイント 』 を、全4回に分けて解説したいと思います。

連載一覧

まず、今回は 「導入前にやっておきたい5つの準備」を紐解いていきましょう。私が考えるテストの自動化導入前に整えるべきことをまとめてご紹介いたします。

もくじ
  1. テスト自動化を導入する前に事前準備が大切
  2. 事前調査(テストの自動化導入の目的とリスクの確認)
  3. 開発者含む関係者全員で認識を共有する
  4. 製品開発者に仕様変更による影響を伝えておく
  5. 製品開発・仕様変更のプロセスを共有する
  6. テスト関係者で共通認識を合わせる
  7. まとめ

テスト自動化を導入する前に事前準備が大切

皆さんは、テストの自動化に対するリスクを十分に把握し、理解し、その対策を念入りに準備されましたか?また、リスクを考慮して、目標設定をされましたか?

テストの自動化には夢があります。皆さんも自動化のメリットについては、十分に把握されているはずです。しかしその夢ばかりに焦点があたり、リスクに対しては無頓着になっていないでしょうか?

私は、4年ほど前、テストの自動化導入の稟議を通すために、ツールの選定には十分な時間と労力をかけました。しかしながら、リスクへの備えは不十分だったと反省せざるを得ません。リスク分析が足りないまま、当たり前のように明るい未来ばかりを想像していました。

「自動化したら、効率化できそう♪」
「自動化したら、楽ができそう♪」
「テストケースの自動化って有料ツール使えば、サクッとできそう♪」
「よーし、どんどん自動化していこう♪」

確かに、テストの自動化に対する稟議が承認され、ツールのライセンスを購入し、最初は順調かと思いました。しかし、度重なる仕様変更の嵐に揉まれ、改修が度々発生し、徐々に大変さに気づき始めるのでした。製品の仕様変更以外にも、OSのバージョンアップなど様々な要因がありました。現実を目の当たりにして愕然としたのを今でも覚えています。

それまでの私は、「実行ボタンを押下するだけで結果がでるし、これからは楽できそう♪」と、本気で信じていました。安易で間違った情報を疑わず、テストの自動化導入を推し進めていました。今思えば、夢を見すぎていたのです。しかし、時すでに遅く、自動化ツールの稟議書は、夢を描いたまま「業務効率化を実現できる」といった内容で承認されたため、社内に多大な期待を抱かせてしまいました。

後悔先に立たずと言いますよね。やはり稟議後、ましてや導入後にリスクに気づくのでは遅すぎるのは言うまでもありません。結果として、リスクに対する要素が全くといっていいほど漏れていた結果は悲惨で、役員や幹部メンバーから、テストの自動化に対する批判中傷が大いに降って湧いてきたのでした。

このような事態を避けるためにも、テスト自動化を導入する前には以下のような準備が必要です。

  1. 事前調査(テストの自動化導入の目的とリスクの確認)する
  2. 開発者含む関係者全員で認識を共有する
  3. 製品開発者に仕様変更による影響を伝えておく
  4. 製品開発・仕様変更のプロセスを共有する
  5. テスト関係者で共通認識を合わせる

次章から詳しく解説していきます。

1:事前調査(テストの自動化導入の目的とリスクの確認)

事前調査.png

まず、「何のために自動化を行うのか?」といった自動化の目的を定め、目的にそぐわない工数は発生しないように注意します。そして、どの範囲を、どの機能を、どのテストケースを自動化するのかといった目標設定を定めてください。

テストの自動化を進める上で、考慮すべき内容に工数超過があります。別項(第4回.費用対効果を上げるための戦略)で具体的に解説しますが、手動テストにくらべて、テストの自動化の方が手順が多いため、特に、導入時期は手動テストに比べて3倍以上の工数がかかります。環境要因でエラーとなるケースも多様にあります。さらには、メンテナンスにかかる工数も同様に嵩むため、工数超過のリスクを十分に考慮しなければなりません。

また、テスト対象となる製品、製品を開発している体制に対する自動化導入のリスクを十分に把握し、理解しましょう。そして、そのリスクにどう対応していくかを、関係者全員で話し合い、対策を取り決め、現実的な目標設定をしましょう。

別項(第4回.費用対効果を上げるための戦略)にて、リスクに対する対策方法を数多くご紹介しますが、会社の体制によって、対象の製品によって、製品が動作する環境によって、様々なリスクがあります。リスクを理解しないまま、目標設定をすることは無謀であり、絶対に達成できません。途中で困惑することになるはずです。

2:開発者含む関係者全員で認識を共有

共有.png

テスト自動化の「目的」を明確に、「目標」を具体的に

初期検討の段階でも、できる限り定量的な目標や方針を掲げられることをお勧めします。悪い例として「○年以内にテストを○○%自動化する」などという目標を見かけることもありますが、これではテストを自動化すること自体が目的となってしまいます。テストの自動化は単なる手段であり、自動化によって、なんらかの効果を得ることが目的であるはずです。曖昧な、又は妥当でない目的や目標を設定することは誤りの元です。

例えば、自動テストによって「◎◎◎◎したい」「△△△△したい」という目的があるはずです。更に、その目的(効果)が得られるように、さまざまな準備や工夫を施すようにすることが、テスト自動化を成功させるための第一歩です。

そのため、「○年以内にテストを○○%自動化する」では目標として曖昧です。○年も先のことまで視野に入れていることは、それはそれで好ましいことではありますが、大きな目標を達成するためには、ロードマップ途中の中間目標も必要です。なぜなら、目標は具体的でなければ、目標の意味を成さないからです。

目の前にある具体的な目標を着実に達成していくことで、実現の可能性は高まります。翻って、抽象的な目標を設定するだけでは、それを現実のものにするのは難しいものです。広いビジョンを持ちつつ、身近で具体的で達成可能な目標を立て、それらを確実に達成できるように計画を立てることが重要です。

このように、具体的な目標を立てるためには、自動テストで実現したい目的をはっきりさせる必要があります。目的を整理するために、テスト自動化による「効果」を整理してみましょう。

まず、私が考えるテストの自動化による効果は主に5つあります。

効果1.時間の有効活用(24時間フル稼働)

人には時間の制限があります。例えば、利益を上げるためにも、労働法を準拠するためにも、社員の健康維持のためにも、時間外労働は控えたいでしょう。子育てをしている方、介護のされている方は、急な呼び出しで家に帰らないといけない状況もあるでしょう。しかしながら、テストを自動化した場合、ツールが実行できる環境さえあれば、24時間テスト実行が可能となります。帰る前に実行したら、翌朝には結果が出ていることが当たり前となります。

効果2.ヒューマンエラーの解消

テストケースの作成者と検証者が異なる場合、検証者は検証目的の勘違いを起こして(テストケースを誤認して誤った目的で)テストを実施してしまう場合があります。しかしながら、自動化した場合には、決められた行程が設定されたとおりに間違いなく実行されます。定義エラーが発生することはあっても誤認は起きえません。

効果3.錯覚の解消(画像キャプチャーの比較)

比較検証を行う場合、人には目の錯覚が発生する可能性があります。概ね同じ場合には差異を見落としてしまうことや、気づけない場合が多様にあります。その点においても、自動化ツールは正確です。ツールによりますが、ピクセル単位で、さらにはパーセントを指定して差異を識別できます。さらにどこの部分に差異があるのか、パーセント等の数値も含めた結果が具体的に出力されます。

効果4.繰り返しテストの安定実施(モチベーション低下によるバグ見落としの解消)

人間には良くも悪くも感情があります。体調や疲労、余裕の有無によっても、モチベーションが異なります。繰り返し値を入れ替えて検証する場合等、何度も何度も同じ操作を繰り返す作業が好きな人は例外として、人は飽きてしまう生き物です。飽きると、動きは鈍くなり集中力は極端に低下します。集中力が低下した状態ではバグの見落としを起こす可能性があります。しかしながら、自動化ツールには感情はありません。常に正確です。例え、何日もかかる何万パターンというテストケースでも休むことなく、正確に実行してくれます。

効果5.費用対効果を得る

最終的に求めなければならないのは、費用対効果です。満足できる費用対効果を得られてこそ、成功と言えるはずです。
ただし、それは導入時期には得られにくいということを理解し、認識していただかなければなりません。

テストの自動化を導入したら、夢物語のような錯覚に陥りがちですが、現実はそんなに甘くありません。テストの自動化には手動テストよりも手順が多く、工数が嵩む傾向があります。そのため、安易に導入しただけではよい効果は絶対に得られません。効果を最大限に得るためには、戦略が必要不可欠です。別項(第4回.費用対効果を上げるための戦略)で詳しく解説いたします。

他にもテスト自動化の効果は様々ありますので、皆さんも整理してみてください。そして、テスト自動化の「目的」を明確に、 「目標」をできる限り定量的に具体的に定め、関係者全員で掲げましょう。

テスト自動化に対する 「対策・方針」

自動化の効果を最大限に得るためには、戦略が必要不可欠です。別項(第4回.費用対効果を上げるための戦略)で具体的に解説しますが、戦略を共有し、関係者全員が同じ目的、目標を掲げて、同じ方向に突き進むことがとても重要です。

1つの解決策として、ナレッジベースの使用をお勧めします。ナレッジベースには、リアルタイムに更新を通知する機能を有しており、情報共有の利点を格段に広げてくれます。共有できる環境を整えたら、テストの自動化に関わるメンバー全員で、リスクに対する対策や方針を含む自動化に関するすべての情報を集約して、いつでも閲覧できるようにしましょう。

3:製品開発者に仕様変更による影響を伝えておく

説明.png

自動化する上で、仕様変更が少ないであろうテストケースを選定することはもちろん重要ですが、それだけでは不十分です。会社の体制として、仕様変更による影響を考慮する必要があります。

もちろん、仕様変更は必要です。不具合の解消・製品のリニューアル等、製品にとって必要不可欠な作業であることは理解しています。しかしながら、テストの自動化を担う担当者にとっては、工数が増える大きな要因となることを補足しておきます。

一般的に、手動テストよりも行程が多いテストの自動化には、手動テストの3倍以上の工数がかかると言われており、工数が嵩む傾向にあります。そのため、仕様変更が多い機能を自動化対象とした場合、メンテナンスの度に3倍以上の工数(コスト)がかかります。仕様変更が多い製品への自動化導入は、とても険しく困難です。工数超過の懸念があるため、費用対効果を上げにくいです。このような悪循環が続くと、期待した費用対効果を得られず、経営層から問題視される可能性がでてきます。

そのため、製品の開発者に対して、「仕様変更により、テストの自動化工数が必要になる」 と認識していただくことがとても重要です。自動化スクリプトの改修には、手動テストの数倍の工数が必要であることの理解があるだけで、安易な仕様変更の回避につながります。

仕様変更に対する意識と開発プロセスを、テストの自動化導入を良い機会にして、どう対応するのがベストかを検討し、リスクがある場合には見直していきましょう。

4:製品開発・仕様変更のプロセスを共有する

仕様変更が発生した場合、情報共有をしましょう。

例えば、実行エラーが発生した際に、そのエラーが何に起因しているか、事前にわかっているのといないのとでは調査時間に大きな差が生じます。仕様変更に対するプロセスが全くなく、開発者個人の判断で容易に仕様変更できてしまう体制では、自動化導入はとても困難です。仕様変更に対する承認フローを構築し、仕様に変更が生じる際の情報共有を徹底しましょう。

余談ですが、私が以前在籍していた医療系システムの会社では、他社との差別化対策として仕様変更が頻繁に発生していました。

しかし、ある出来事がきっかけとなり、仕様変更の概念が変わりました。そのきっかけはISO規格の取得、さらには薬事法(現:薬機法)の改正でした。ISO規格取得のために開発業務のルール改善を行った事、さらには薬事法の改正によって、仕様変更した場合のリリースプロセス等に変更が生じたことが良い効果をもたらしました。一番効果をもたらしたのは、仕様変更をする際に承認フローを導入したことでした。これらにより、安易な仕様変更は確実に減りました。皆さんの組織において、自動化導入がプロセス改善へのより良いきっかけとなることを願います。

5:テスト関係者で共通認識を合わせる

ツール共有.png

使用する自動化ツール、開発言語、開発規則を統一する

テストケースを容易に自動化するために、私は自動化ツールの使用を推奨しています。自動化ツールがなくても、スクリプト言語の知識や経験が十分にあれば実装できますが、フルスクラッチでの自動化は優れた技術者しか選任できなくなってしまう懸念があるからです。

ツールを利用する場合、無償の自動化ツールを使うこともできますが、有償の自動化ツールであれば、開発スキルがなくても使用できるという利点があります。

そして、自動化ツールを複数人で使用する以上、開発規則の策定は必要不可欠ですが、開発言語も自動化ツールも1つに絞ることをお勧めしています。ツールが変われば、開発言語も変わり、共通スクリプトも使用できなくなってしまうからです。ノウハウを蓄積しやすくするためにも、他のメンバーが実装したスクリプトの改修をしやすくするためにも、自動化ツールも、ツールで使用する開発言語も、1つに絞ることでリスクを軽減しましょう。

しかしながら、心配すべき点があります。自動化ツールを1つに絞ったことで後悔しては本末転倒です。自動化をスムーズに促進するためには、テストの自動化を導入する製品に対して最適なツールを選定することをお勧めします。

選定については別項(第2回.ツールの選び方)にて詳細に解説いたしますが、数日では選定困難です。選定期間には十分な期間を確保することをお勧めします。もし、選定期間を自社で用意できない場合には、ツール選定(自動化のフィージビリティスタディ)の業務委託をご検討いただくことをお勧めいたします。私は、複数のツールを選定したため、数か月を要しました。最低でも1月は考慮期間を見ておくと良いと思います。

自動化ツールと開発言語が決定したら、開発規則を検討し実装メンバーで共有しましょう。

自動化ツールに対するノウハウを共有する

自動化を実現する手段についても認識を合わせる必要があります。

自動化ツールに対するノウハウを共有するなら、勉強会を開くことをお勧めします。ナレッジベースにまとめることもお勧めしていますが、実技に勝るものはありません。自動化ツールの設定、使い方を実装メンバー間で切羽琢磨しながら、よりよい手法を模索しつつ、共有していきましょう。

自動化する上で、仕様変更が少ないであろうテストケースを選定することはもちろん重要ですが、それだけでは不十分でテストの自動化導入に対する戦略を立て、より良いツールを選定したとしても、基盤となる体制が自動化に向いていなければ、費用対効果は低くなってしまいます。

皆さんの組織がより良い体制となることを願いつつ、テストの自動化が成功へと導かれることを願っています。

PR
ローコードテスト自動化ツール T-DASH

T-DASHサムネイル

T-DASHはWebアプリケーションの動作確認・検証をコードを書かずカンタンに作成・実行できるテスト自動化ツールです。

初期設定からテストの実行まで、T-DASHのすべての機能でコードを書く必要はありません。そのため開発を担当していない非エンジニアの方でも手軽にご利用いただけます。

他のテストツールを導入している企業さま、まだ自動化ツールを試してみたことがない企業さまもこの機会にT-DASHにぜひ触れてみてください。

まとめ

今回は、基盤となる 「導入前にやっておきたいチェックポイント」 について解説いたしました。

事前準備としてのポイントは以下の通りです。

  1. 事前調査(テストの自動化導入の目的とリスクの確認)する
  2. 開発者含む関係者全員で認識を共有する
  3. 製品開発者に仕様変更による影響を伝えておく
  4. 製品開発・仕様変更のプロセスを共有する
  5. テスト関係者で共通認識を合わせる

目的や目標が曖昧のまま自動化導入を進めてしまうと、リスクを考慮できず失敗してしまうこともあります。

事前にきちんと準備をして基盤を整えてからテスト自動化を推進していきましょう。

次回は、テストの自動化導入前に躓いてはいけない 「ツールの選び方」 について解説したいと思います。

連載一覧

「成功するテスト自動化導入」のコツ
x hatenabookmark
0

執筆: 宮北 裕子

バルテス株式会社 Web・IoT品質サービス事業部 マネージャー

医用システム開発会社にて、検証部門や品質管理部門の立ち上げや検証ルールの策定、テスト自動化の担当など多岐に渡るプロジェクトに13年間携わった後、バルテスに入社。バルテス入社後もテスト自動化に関与し、パフォーマンス検証や負荷検証を実施した実績がある。取得資格はJSTQB Advanced Level(テストアナリスト)など。JSTQB ALテスト自動化エンジニアの日本語翻訳WGメンバーでもある。