![株式会社ヒューマンクレスト 取締役 浅黄友隆氏](http://cz-cdn.shoeisha.jp/static/images/article/15627/15627_001.jpg)
10年前といまではソフトウェアテスト自動化の認識が変わってきている
ソフトウェア開発で欠かせないのがソフトウェアテストだ。10年前は、まず手動テストをつくり、それをいかに自動化するのかがソフトウェアテストの自動化だと考えられていた。浅黄氏が10年前に抱いていた自動テストのイメージも「人間の手で操作しているテストを自動化する」というものだった。しかし現在ではまったく違い、自動テストを作ることが普通になっている。つまり、手動テストをもとに自動化するのではなく、テストそのものが自動で行われるものと、意識が変わっている。実際、ヒューマンクレストでも「開発会社の方とテストを行うときに、そもそも自動テストしか行っていないというお客様が非常に増えてきています」と浅黄氏は語った。
なぜこのような変化が起こったのかというと、「この10年でテストへのアプローチがものすごく変わった」からだと浅黄氏は言う。要因はソフトウェア開発における環境の激しい変化だ。アーキテクチャや開発プロセス、インフラ、デバイスなどが変化し、ビジネスのスピードが大幅にアップした。これにより、テストのスコープとスピードが変わり、テストの自動化が進んだのである。
![テストの自動化が進んだ背景](http://cz-cdn.shoeisha.jp/static/images/article/15627/15627_002.png)
スコープの対象と範囲もこの10年間で大きく変わった。かつてはUIテストを自動化することが非常に多かったが、いまではそれもAPIに変わっている。ほかにもWebからモバイル、オンプレミスからクラウドなどテストの対象が変わったものは少なくない。受け入れテストではシステム全体をテストするのが一般的だったが、いまはフロントエンドとバックエンドで分けてテストを行うのがスタンダードだ。
テストの範囲も大きく行っていたものを小さく、広く行っていたものをより狭くしていくことが増えている。モノリスからマイクロサービス、要件から機能へといった周りの変化が激しいので、テストのスコープもそれに合わせて変わっていったのである。
テストのスピードも大きく変わってきている。まずテストを行うタイミングが10年前とは違う。かつてはプロジェクトの中で自動テストを3回実施したらもとが取れるなどという考え方もあったが、いまでは数回しか自動テストを行わないなんてことはあり得ない。毎日テストを行うのは当たり前で、マージごと、プルリクエストごとに自動テストが行われるのも珍しくはない。
さらに自動テストの実行時間も、かつてはUIのテストを自動化すると数時間かかっていたものが、いまでは数分、数秒で終わる。テストの並列実行が主流になってきているのも、実行時間短縮の要因のひとつである。そしてテストのフィードバックも可視化されて、テスト結果を誰でも見られる環境が整ってきているのも影響として小さくない。
ソフトウェア開発のスピードとスコープを変えた「ピラミッド」と「4象限」
浅黄氏は、「スピードやスコープが変わってきた一番の要因は、ソフトウェア開発やソフトウェアテストに関する概念が日本に多く入ってきたのが要因だと考えています」と指摘した。
浅黄氏がまとめたソフトウェアテストの概念に関する年表を次のスライドに示す。
![ソフトウェア開発やソフトウェアテストに関する概念の年表](http://cz-cdn.shoeisha.jp/static/images/article/15627/15627_003.png)
テスト駆動開発(TDD)などに関する翻訳書が出版されたことで、開発者がそれをもとにテストを行ったり、QAやテスターがUIのテストを自動化したりといったことが増えていった。そういった背景がある中で浅黄氏はもっとも大きな影響を与えたのが、「テストピラミッド」と「アジャイルテストの4象限」の図だと指摘する。
![テストピラミッド](http://cz-cdn.shoeisha.jp/static/images/article/15627/15627_004.png)
テストピラミッドとは、ユニット、サービス、UIで三角形のピラミッド型になり、その頂点にマニュアルテストがあるという構造である。このピラミッドは望ましい自動テストの量を示している。ユニットテストはテストの高速化や分離性の向上によって早く実行できるようにしていき、上位にあるUIテストはスコープを拡大することによって全体が正常に動作するという自信につながっていく。
![アイスクリームコーン型](http://cz-cdn.shoeisha.jp/static/images/article/15627/15627_006.png)
アンチパターンとして、アイスクリームコーン型というものがある。ユニットテストをやっていない中でテストの自動化を進めていくと、GUIのテストがたくさんあり、マニュアルテストも多くある、という状態だ。手動テストしかないときに、テストを自動化すると、UIの自動テストにしかならず、アイスクリームコーン型になってしまう。
そして「アジャイルテストの4象限」はイテレーションごとに、都度、どんなテストを行うべきか、皆で考えるためのツールである。
![アジャイルテストの4象限](http://cz-cdn.shoeisha.jp/static/images/article/15627/15627_005.png)
開発者であれば、左下にあるユニットテストなどで自動テストを行っている。このあたりは技術面でチームをサポートするテストとなる。縦軸の上の方はビジネス面からのテスト、製品を批評するテストは右側で行われている。主に開発側が左下を担当し、右上をQAが担当するのが、大まかなイメージである。
変わってきた開発エンジニアの領域と変わらない目的の重要性と人への依存
現在、開発の中やデプロイメントパイプラインに自動テストを入れ込まないと、もうソフトウェア開発が進まなくなってしまっている。さらに開発エンジニアが担う領域が拡大している。従来であればテストはテスト担当のエンジニアが行い、開発は開発エンジニアが行うものだった。しかし現在だと開発エンジニアも一緒にテストに参加する必要があり、それにともない理解しておくべき技術領域も増えている。開発環境におけるOSSや仮想化、コンテナ化、テスト技術における技法や設計を知らなければ、テストそのものがうまく行えない。
この10年でさまざまなことが変わっていったが、その一方で変わらないものもある。それが目的を明確にすることと、継続して運用することの重要性である。浅黄氏は「目的が明確であればあるほど、それを自動化することで継続して運用していけば必ず成果が出ると思っています」と述べた。なぜこのテストをしているのかが明確であれば、これを継続して運用していくことでデグレも必ず見つけることができると言う。この目的の重要性は、10年経っても変わらない。
ここで浅黄氏は、自動化の導入支援で活用している「Test Automation Circles」を紹介した。これは、真ん中の「コア」から外側に向かって順に実行することで、テスト自動化の助けになるものだという。まずは「コア」となる目的「なぜテストをするのか」を決める。そして、その目的に対し「どんなテストをするのか」という「コンセプト」を決めていく。具体的には、目的に対し、どのような戦略を立て、どんなスコープで、どういった設計をしていくのかという具合だ。続いて「アーキテクチャ」、つまり「何を使って実現するのか」という具体的な手法、円の最も外側には「モニタリングとコントロール」、実現された自動テストを実際に実行・分析していくことにつながっていく。最後に、この円が作られている「ベース」、すなわちリソースや文化などの自動テストを築くための土台も重要であると付け加えた。
![Test Automation Circles](http://cz-cdn.shoeisha.jp/static/images/article/15627/15627_007.png)
自動テストを導入する4つのパターンと自動テスト導入による効果
自動テストを導入するときのパターンを分類すると次の4つになる。
- システムの価値をテストする
- 繰り返す必要があるテスト
- スピードを重視するテスト
- インターフェースをテストする
一つ目の「システムの価値をテストする」は、システムが提供する主要な要件や機能が正常に動作することを確認するために導入するパターンである。シナリオテストやリグレッションテストの自動化が行われる。システムとして変わらない部分をテストする。これが自動テストになっていればずっと使われるし、また自動テストが動いていれば、自信をもってリリースすることができる。
二つ目の「繰り返す必要があるテスト」は、繰り返し操作するテストのために自動テストを導入するパターンである。インプットするデータのパターンが大量にあるものの操作が同じというものや、複数あるアウトプットのパターンを確認するために操作が必要になるといったものは自動テストが適している。ほかにはテストケースを繰り返すパターンもある。操作は同じだがブラウザやスマートフォンごとに確認が必要というテストである。また何らかの修正をしたときに、再び一括してテストを行う必要がある場合も自動化が望ましい。
三つ目の「スピードを重視するテスト」は、テストのスピードを速めて開発者へのフィードバックの時間を短縮するために自動テストを導入するパターンである。テストは速ければ速いほど良い。これはTDDやATDDの概念と同じである。開発者へのフィードバックを早めることによって、修正するスピードも速くすることが可能になる。そのために、独立性や冪等性(べきとうせい 同じ操作を何度おこなっても同じ結果であること)の確保、スコープを絞ったファンクショナルテストを自動化するなどテスト設計の見直しが必要になる。
四つ目の「インターフェースをテストする」は、バックエンドの動作を確認するために導入するパターンである。バックエンドの動作確認のテストを分割するほか、APIの動作や機能を確認するテストの自動化を行う。
自動テストがこれからどのように変わっていくのか――予想できること
今後の自動テストがどのような変化や進化を遂げていくのか、浅黄氏は「正直なところ、自分でもどうなるかわかりません。しかし、軸であるスコープとスピードはまだまだ変わり続けていくだろうと思っています」とコメントした。
スコープについては、ユニットテストやインテグレーションテスト、UIテストなどテストのレイヤーによって自動化が進んできている。最近ではアーキテクチャによってより細分化がされており、UIのテストであっても単体で動き、かつわざわざブラウザを表示しない、Headlessで動かすのが標準になっていると言う。また、海外ではシフトライト側のテストの自動化が進みつつあるなど、自動テストだけにフォーカスするのではなく、全体を俯瞰することが求められている。そしてスピードは、常により速くなっていくことは間違いない。
そして浅黄氏が今気にかけているのが、スケールである。特にテスト環境の大規模化が進んでいて、DockerやKubernetesなどがあるため、冪等性が担保できるような環境が常に作れるようになっている。これまであったような、環境が用意できなくて並列テストが実行できない、ということがなくなり、テスト対象が並列化で用意されて、テストも順次実行できるという状態になってきているという。今後はこのあたりが常に進んでいくだろうと、自動テストの今後について締めくくった。