コンテキストベースの自動テスト:テストピラミッドの再考

テスト自動化ピラミッドは、自動化テストを構築するための基準として長い間使用されてきました。しかし、アプリケーションが複雑になった今でも、このモデルを使用する意味はあるのでしょうか?このモデルが登場してから、情況に変化はあったでしょうか?今日の自動化テストでこのモデルと併せて考慮すべきことは何でしょうか?

テスト自動化ピラミッドとは何か?

マイク・コーンは自著 Succeeding with Agileで、プロジェクトの自動化テストにアプローチする方法としてテストピラミッドを考案しました。 このモデルにはさまざまな解釈がありますが、基本的な考え方として、自動化テストには、以下の3つの層があるということです。

(テストピラミッド)

単体テスト(Unit Tests)

単体テストでは、アプリケーションソフトウェアの最小コンポーネントを検証します。最小コンポーネントは、アプリケーションコード内において、何らかの入力に基づいて値を計算する関数である場合があります。そしてこの関数は、コードベースに存在する、複数の関数のうちの一つです。単体テストの最大の利点は、UIの下で高速に実行され、アプリケーションに関するフィードバックを迅速に得られることです。このテストがピラミッドの最下層として示されているように、これがテストの大部分になるはずです。コンポーネントには、アプリケーションと共に、テストデータベース、API、およびサードパーティのツールとサービスを含めることができます。

API/統合テスト(API/Integration tests)

API/統合テストは、ソフトウェアシステムの複数のコンポーネントをまとめて検証します。API/統合テストはバックエンド側で実行されるため、UIテストよりも高速に実行されますが、単体テストよりも時間がかかる場合があります。なぜなら、API/統合テストでは、システムのさまざまな独立したコンポーネント間の通信を確認してシームレスに統合されていることを検証する必要があるからです。

UIテスト(UI Tests)

UIテストは、アプリケーションのUIを検証します。 UIテストは通常、アプリケーションを介したエンドツーエンドのフローをテストするためにおこなわれます。UIテストの最大の制約は、アプリケーションのGUIで実行されるため、単体テストやAPI/統合テストと比べてテストに時間がかかるということです。

このピラミッドは、過去数十年間、自動化テストを構築するための青写真として機能してきました。 しかし、テストとアプリケーションの複雑性が飛躍的に増している現代において、アプリケーションをテストするためにこのモデルを使用し続けるのは適切でしょうか?

テスト自動化ピラミッドを再考する

テスト自動化ピラミッドは再検討する必要があると思います。このモデルの登場以来、顧客のニーズとテクノロジーは劇的に変化しました。テストを素早くおこない、欠陥をより早く発見するために、チームは自動化テスト戦略を変更しました。また、モデルで考慮されていない自動化テストの構築にはさまざまな課題があります。

私は、多くの組織、特に開発とリリースプロセスのない組織では、単体テストをおこなっていないか、既存のテストを保守していないことに気付きました。 これにはいくつかの理由がありますが、重要な要素の1つは、APIおよびUIテストをおこなうためのさまざまなツールが存在することで、単体テストにあまり注意が向けられないことです。

ブロックチェーン、暗号通貨、AI、マイクロサービスの時代を迎え、システムがより複雑になるにつれて、テストの焦点は個々のコンポーネントのテストからより統合されたテストソリューションへと徐々に移行しました。テスターは、リスクベーステストと探索的テストで自動化作業を補完します。 アプリケーションの複雑さが増すにつれて、負荷テスト、パフォーマンステスト、およびセキュリティテストを実行する必要性は欠かせないものとなりました。

現在のアプリケーションは大量のデータを処理し、数秒で数千の異なるシステムとやり取りします。また、システム間のデータ移動を安全なものにし暗号化する必要があります。チームは、さまざまなツールを使用して、負荷、ユーザー、データをシミュレートし、テストをおこないます。

製品の市場での地位を保つために、ポジティブなユーザーエクスペリエンスがアプリケーションにとって重要になりました。企業はユーザビリティテストの実行にさまざまな投資をおこなっており、複数のブラウザー、OS、デバイスにわたるシームレスなユーザーエクスペリエンスに焦点を当てています。 これは、クラウドベースのソリューションが人気を博す理由でもあります。クラウドベースのソリューションであれば、実際のハードウェアデバイスを購入してテストすることなく、さまざまな構成でアプリケーションをテストするためのサブスクリプションを取得できます。

最後に、AI などのテクノロジーを使用したより賢く高度なテストの出現があります。多くのテストを作成せずに、あらゆるレベルでアプリケーションをテストするソリューションはいくつか存在します。 AIは本番環境でのユーザーアクションから学習し、さらにテストが必要なフローを特定できます。そして、実行するテストの増加によって、”Flaky”なテスト (同じコードで成功/失敗の両方が観測されるテスト) の検出と最も重要なテストの自動化において AIがさらに賢くなります。

チーム、アプリケーション、利用可能なツール、時間、コスト、労力に基づいて、自動化テストを現在の時代に合わせて計画し、採用する必要があることは明らかです。自動化テストの計画のコンテキストベースのハブアンドスポークモデルを提案し、以下に示します。

ピラミッドのようなテストの「層」はもうありません。 このモデルでは、テストのタイプに重点を置きます。一部のタイプは、コンテキストに基づいて、他のタイプに優先する場合があります。

これは、自動化テストに関する意思決定に使用できる参照モデルの1つにすぎません。重要なことは、時代のニーズに合わせ、それに応じて自動化テストの手法を採用することです。

作者について:

Raj Subrameyerは、国際的な基調講演者、ライター、およびキャリアコーチであり、技術的なバックグラウンドを豊富に持っています。 彼のBlog(rajsubra.com/blog/)では、読者の生活に役立ち、インスピレーションを与えるニュース、リソースを投稿しています。

(この記事は、開発元 Ranorex 社 Blog 「Context-Based Automated Testing: Rethinking the Test Pyramid」2020年3月26日の翻訳記事です。)