テスト自動化のこれまで

テスト自動化はこれまで「難しい」「ハードルが高い」と言われ続けてきました。要因は、ノウハウやスキルの不足に加え、専門性の高い外部人材が見つからないことだと考えられます。さらに、自動化に対する理解不足も一因です。例えば「ツールさえあれば誰でも自動化できる」といった誤解から安易な気持ちで自動化を試みてはみたものの、開発終盤のテストフェーズで手動テストをそのまま自動化しようとして失敗するケース、または導入に至ってもメンテナンスの費用や工数がかかりすぎるといったケースが多数見られました。これらの結果として、テスト自動化は難しいという認識が広まったと考えられます。

こうしたハードルを乗り越えるためのアプローチとして進化してきたのが、テスト自動化ツールです(図表1)。進化の波は3段階に分けられます。第1の波は2000年頃です。WinRunnerやSilk Test、QTPといったベンダーツールを用いたテスト自動化が進みました。第2の波は2010年頃で、SeleniumなどOSSのテスト自動化ツールが普及していきました。ベンダーのツールが高価なのに対してOSSのツールは無料のため、テスト自動化へのチャレンジが活発になったのがこの頃です。しかし、OSSのツールを使いこなすにはプログラミングのスキルが必要で、自動化のハードルは依然として高いままでした。
その後、やってきたのが現在（2020年～）の第3の波です。AIと機械学習を利用した自動テストツールの登場です。

こうしたツールの進化に加え、テスト自動化に取り組んでいる企業におけるナレッジの蓄積・公開、さらにはテスト自動化のさまざまな手法の進歩などによって、テスト自動化のハードルは次第に下がっていきました。

テストを自動化すること、また、自動化したテストをメンテナンスして使い続けることが容易になった今、テスト自動化に取り組むことは、もはや「当たり前」になりつつあります。

テストを自動化した後の課題

テスト自動化のハードルが下がり、それが当たり前になったことで発生した新たな課題があります。質の低い自動テストの増加です。
要因は何でしょうか。私は普段、テスト自動化に関してさまざまな企業から相談を受けていますが、課題を抱える企業によくみられる3つの要因を挙げてみます（図表2）。

1. ①似たようなテストをそれぞれ別に自動化してしまう
   高いスキルを持った専門のエンジニアだけがテストを自動化していた時代は、自動化する対象も一人で選定することが多く、無駄のない自動化が行われていました。しかし、自動化のハードルが下がり、誰でも自動化に関われるようになったことで、自動化に取り組む担当者間の連携が取れないままに、それぞれが似たようなテストを個別に自動化してしまうといったことが起こりやすくなっています。
2. ②「心配だから」「念のため」とテストケースが増える
   テストを自動化することで実行コストが一見ゼロになるように思えるためか、万が一に備える意味合いでテストケースを増やしてしまいがちです。
3. ③「自動化ハイ」になる
   テスト自動化という武器を手にしたことによって、全てのテストが自動化できるような気持ちになってしまうケースもあります。いわゆる「自動化ハイ」と呼ばれるものです。

結果として引き起こされるのが、質の低い自動テストの増加です。またそれによって、自動テストの保守・運用コストが増える、あるいは自動テストを実行しているのに観点が抜け落ち、結果的に不具合が見逃される事態も見られるようになりました。さらに、自動で大量のテストを実行すると、そこで得られるテスト結果やログが膨大になり、ひとたびテストが失敗したときに人の目で確認する手間が自動化前より逆に増えるということまで起きてきます。

AI自動テストツールを提供するmabl（メーブル）社のJapan Lead 藤原 大氏は、「E2Eテスト^※1 自動化の本質^※2 」というプレゼンテーションで、「本当に必要なテストを作る、自動化する」ことの重要性を指摘しています。テストが簡単に作れることでE2Eのテスト（あるいはシステムテスト）が増えすぎる傾向にあり、そのため質の低いテストがたくさん作られてしまうわけですが、当然このような質の低いテストは品質に貢献しないばかりかコストの増加にもつながります。この指摘からも分かるように、システムテストの自動化では、自動化するテストそのものの「質」にこだわることが非常に重要となります。

※1：End-to-End-Testing 本番相当の環境で、ビジネスプロセスを最初から最後まで実行するテストの一種。（出典：https://glossary.istqb.org/jp/）
※2：https://speakerdeck.com/daipresents/the-essence-of-e2e-test-automation

テスト自動化の「前」を考える

自動テストの質の低下・量の増加という課題への対処方法についてはさまざまな考え方がありますが、ここではテスト自動化の「前」を考えるということを紹介します。

そのポイントは「テスト自動化を行う前提でテスト設計を行う」です。どういうことでしょうか。

既存の手動テストを自動化する際の問題点

テスト自動化がうまく行っていないという企業から話を伺うと、次のようなパターンが多いようです。「手動で行っているテストケースシナリオをそのまま自動化している」、さらには「手動テストからの自動化率100％という目標を立てている」などです。これらは実はテスト自動化のアンチパターン（失敗の典型例）です。手動テストを単純に自動化しても自動テストにはなりません。
その理由を、具体的な作業の流れで説明しましょう。既存の手動テストを自動テストに変換する際にたどりがちなフローを示したのが図表3です。

図表3左側のフローを私たちは「テストケースの加工作業」と呼んでいます。左上から、既存のテストケースが一定量あり、それらに対してまず自動化の対象とするかどうかの選別を行います。選別されたテストケースに対し、今度は「自動化実現可否」を判断します。実現できるテストケースについては、図右側の「本質的な自動化の作業」に入っていきます。
つまり、既存の手動テストをそのまま自動テストに置き換えようとすると、自動化の本質とは異なる部分にかなりの時間や労力を割くことになるのです。

左側のフローを経る場合の問題点はいくつかあります。例えば、「加工」という過程によって、もともとテストしたかった観点が抜け落ちてしまうことが挙げられます。

また、自動化のタイミングが遅くなる問題もあります。テストケースの加工が終わってから自動化作業をしようとすると、プロジェクトの後半に自動化のためのリソースが集中することになり、最悪の場合、必要な時期に自動テストの実装が間に合わない可能性もあります。

ベリサーブの取り組み事例

テストを自動化した後の課題を避けるために、ベリサーブでは自動テストの実施を前提としたテスト設計を行っています（図表4）。
自動テストに限らない一般的な品質保証のプロセスにおいては、通常、テストベースとQA方針をインプットとして主にQAエンジニアがテスト分析を行い、テスト設計よりも後の段階で自動化エンジニアがテストを自動化します。これに対し、自動テストを前提とするプロセスでは、テスト分析の段階から自動化エンジニアとQAエンジニアが連携し、さらにその先のテスト設計、テストケース設計と行っていきます。このようなフローで自動化を進めることにより、自動テストと手動テストの両方が最適化され、目的に沿ったテストを実施することができます。

テスト自動化の今後

ここからはテスト自動化の今後について考えていきます。

図表5は、テストエンジニアが提唱するテストの自律性レベルを、クルマの自動運転レベルと対比させて表したものです。この図表を作成したのは、1970年代から40年以上ソフトウェアテストの品質保証に携わり、ソフトウェアテストの歴史と動向に精通している辰巳敬三氏です。テスト自動化ツールがAIなどによって進化し、自律的にテストできるようになる段階を、自動運転のレベルに照らし合わせて整理されています。

本講演の前半で、AIと機械学習を利用した自動テストツールが登場した現在は、テスト自動化の第3の波の状態にあるとお話ししました。AIの活用度合いを図表5に当てはめるとレベル2相当です。
今後はレベル5の「完全な自動化」、つまり人が何もしなくても、機械が自動テストを行ってくれる方向に進化することが予想されます。それは、いい意味で誰でもテスト自動化ができる状態に近づくことを意味します。

そうなると、本来テスト自動化エンジニアやSET（Software Engineer in Test）^※3 が自動化を担当していたところへ、PM（プロジェクトマネージャー）やPdM（プロダクトマネージャー）、開発者、QAといった他のロールの人たちが関われるようになります。
PMやPdM、開発者は、不具合の早期検知やリスクの軽減、プロダクトの魅力など、テストの専門家とは違った観点でそれぞれプロダクトに向き合っているため、自動テストもそれぞれの観点から実施が可能になり、一定の効果が期待されます（図表6）。

※3：テスト容易性の向上や、プロダクトコードの品質を高めることで開発やテストをスムーズに進め、生産性と品質の向上に貢献することを期待される役割。主に、テストフレームワークや開発インフラの整備などを担当する。

テスト自動化が誰にとっても容易になることは、テスト自動化の専門家がいない組織にも大きなメリットがあります。こういった組織では、
QAやテストエンジニアが自動化の推進やメンテナンスを行っている場合がありますが、こうした人たちがテスト自動化に割いていたリソースを本業に集中させられるようになるからです。

もっとも、誰もがテスト自動化をできるようになったとしても、専門家が不要になるわけではありません。自動テストの質の低下や量の増加といった諸問題を解消するためには、やはり高度なスキルや知識を持った専門家の関与が必要です。

ここまで見てきたように、AIの活用などによって、テスト自動化や自動化したテストのメンテナンスは今後一層、楽になっていくと考えられます。
そこで重要なことは、テストプロセスや開発プロセス全体でどのように品質を担保していくかという視点です。自動テストで何を担保するのか、そのためにどんなテストを自動化するのか、自動テストで得た結果・情報をどう活用するのかということを念頭にテスト自動化を行う必要があります。これからの組織には、自動テストという便利な道具を活かすためのテスト・品質に関する知見が求められます。

おわりに

技術の進歩によりテスト自動化が当たり前になる一方で、質の低いテストが量産されてしまうという負の側面が新たに発生しています。それを解決するための1つのアプローチとして、自動テストを前提としてテスト設計を行う、あるいは設計以前の分析段階からQAと連携してテストプロセスを実施する取り組みをご紹介しました。
テスト自動化を推進する上では、「テスト自動化をどのようにうまくやるか」という閉じた視点に留まることなく、開発プロセス全体を効率的に回すための道具の1つとして、テスト自動化を位置付けることが重要です。本講演が、皆様のテスト自動化における課題解決の一助になれば幸いです。

この記事をシェアする