2020年9月18日 / 最終更新日時 : 2020年9月18日 user 事例・ソリューション

テストプロセス全体に自動化がどのように適合するか

アプリケーションが複雑化するにつれ、不具合を早期に発見・修正してリリースするには、テストをシフトレフトすることがさらに重要になってきました。そして、厳しいプロジェクトスケジュールとリリースサイクルに追いつくための方法の１つとして、自動化テストがあります。

しかし残念ながら、「自動化テストは、経験豊富なテスターによって手作業でおこなわれていた既存のテストプロセス（スクリプトベースのテスト、探索的テスト、リスクベーステストなどの組み合わせ）に、取って代わるものである」という、誤った認識を持ってしまう場合があります。自動化は、テストのすべての問題を解決できる万能薬ではなく、むしろ、テストプロセス全体の助けとなるものです。

自動化は、テストプロセスのどこに、そしてどのように適合するのでしょうか ? 段階的に分析してみましょう。

自動化が現代のアジャイルプラクティスにどのように適合するか

現代のアジャイル環境では、要件フェーズから始まり、ユーザーによる受け入れとデプロイメントのフェーズに至るまで、全フェーズで自動化テストを実施することができます。

これは、DevOpsと継続的テストにおいて、特にあてはまります。

DevOpsは、ソフトウェア開発チームと運用チームの連携を強化し、インフラストラクチャ管理も含め、ソフトウェア開発ライフサイクル (SDLC) 全体を通して、定常的な自動化とモニタリングを可能とします。

継続的テストは、テストをシフトレフトするために、SDLCにおいて可能な限り早い段階でテストを開始するために役立ちます。継続的テストを実現するには、開発プロセスの様々なフェーズでの自動化が必要になります。これは、テストの一部としておこなっている作業に対して、さまざまな変更が必要になることを意味します。

ほぼすべてのテストケースが自動化されるように、SDLCの当初から自動化に着手します。
スムーズな CI/CD サイクルを実現するために、すべてのQAタスクを調整します。
本番環境での継続的なモニタリングをおこなうために、高いレベルでのコラボレーションを実現します。
すべての QA 環境を標準化します。
テストについての考え方を「このモジュールのテストを完了した」から「このリリース候補バージョンで低減されたビジネスリスクは何か？」に変えます。

これらすべての変化の鍵は、自動化です。

自動化は、DevOps と継続的テストを結びつける接着剤であり、スマートな人材とツールが、より短期間により信頼性の高いリリースサイクルを実現するために貢献できる場所です。

自動化を利用するタイミング

自動化は、適切な方法で使用すれば、既存の機能テストプロセスを補完することができます。

ここでは、自動化が価値をもたらすであろうユースケースをいくつかご紹介します。

手動で行うには時間のかかる平凡で反復可能なタスクを自動化します。
特に DevOps環境で、SDLCの開始からリリースおよび本番環境でのモニタリングフェーズまで自動化を使用します。
新しいコードがチェックインされたとき (新機能が実装されたときなど) にシステムに関する迅速なフィードバックを受け取ることができ、コードのチェックインのたびに自動化テストを実行できます。
システムの既存機能が期待通りに動作していることを確認するために、日常的に回帰テストを実行します。
手動での探索テストで使用する、手動で作成するには時間がかかるテストデータを、自動的に作成します。
データ駆動型テストを使用して、何百ものデータセットを使用して異なるフィールドをテストします。

すべてを自動化できるわけではない

自動化を最大限に活用するには、自動化が必要となるシナリオを検討することが重要です。多くの場合、手動でテストした方が簡単なタスクなど、間違ったタスクの自動化に多くの時間が費やされており、「自動化は役に立たない」という誤った結論につながっています。

ここでは、間違ったタスクに自動化を適用した場合、自動化がどのように不安定になり、実際に上手く活用できなくなるかについて例を挙げて説明します。

アプリケーションの表示に関する問題 (ルックアンドフィールなど) を見つけるために自動化を使用するのは理想的とは言えません。視覚的な検証をおこなうためのツールは存在しますが、この検証においては、人間の代わりになることは困難と言えます。たとえば、ある携帯電話ではモバイル Web ページが白く見え、別の携帯電話では濃いグレーに見えるということがありました。このテストの自動化を試みることは確かにできますが、アプリケーションのルックアンドフィールの微妙な違いを見つけるのは人間の方が得意です。

ページ上の要素の位置を把握するために自動化を使うのも理想的ではありません。もし、要素の x,y 座標に基づいたテストを作成した場合、自動化テストは不安定なものになります。なぜなら、Web ページは、異なるブラウザー、デバイス、OS で表示される可能性があり、x,y 座標は画面サイズに基づいて変更されます。つまり、自動化テストが不正確で一貫性のないものになってしまいます。

ソフトウェア、ハードウェア、Web サービス、API、クラウドサービスのすべてがリアルタイムで通信している場合に、これらすべてが統合されたシステムをテストするために自動化を使用するのは、複雑すぎて価値がないかもしれません。たとえば、フィットネストラッカーのエンド・ツー・エンドのすべてのシナリオを検証する自動化テストをどのように書けばいいのでしょうか ? 実際の人間の動きやモックサービスをシミュレーションするためにできる限りの努力をすることはできますが、フィットネストラッカーの全プロセスを自動化するのは難しい作業になりそうです。それよりも、いくつかの自動化されたテストと並行して、実際の人間が探索的テストを行う方が効果的でしょう。