ソフトウェアテストピラミッドを理解して実装するには：実装とテスト手法を解説

TechTargetは「ソフトウェアテストピラミッド」に関する記事を公開した。本稿では、各種テストの量に優先順位を付けるのにテストピラミッドを活用する方法を紹介する。

[Gerie Owen，TechTarget]

　TechTargetは2024年5月30日（米国時間）、「ソフトウェアテストピラミッド」に関する記事を公開した。ソフトウェア開発サイクルではテストが重要な役割を果たす。そのため、テストを実装するに当たっては適切なフレームワークの選択が重要になる。

ソフトウェアテストピラミッドを理解して実装する（提供：TechTarget）

　本稿では、各種テストの量に優先順位を付けるのにテストピラミッドを活用する方法を紹介する。

　ソフトウェアの開発手法がウォータフォール、アジャイル、継続的デリバリーと進化していくにつれ、開発サイクルは短くなってきた。だからといって、テストの手を抜いてよいわけではなく、開発の各サイクルや各イテレーション全体でテストに目を向けなければならない。この課題に対処するのがソフトウェアテストピラミッドで、現在使われている中では最も効果の高いテスト設計フレームワークの一つに挙げられている。

アジャイル開発におけるフレームワーク

　ソフトウェアテストピラミッドは、開発チームがアジャイルの本質的な目標を達成するのに役立つ。

　アジャイルの核となる価値はソフトウェアを迅速に開発することだけではない。開発に関与する全ての関係者のニーズに柔軟に対応するという目標もある。アジャイルの核となる価値観は、アジャイル変革の方向性を示す。具体的には次のような方向性だ。

• プロセスやツールよりも個人との対話を優先する
• 包括的なドキュメントよりも機能するソフトウェアを優先する
• 契約交渉よりも顧客との協調を優先する
• 計画に従うことよりも変化への対応を優先する

　アジャイル手法ではより柔軟で効果的なアプローチを実現するため、開発の短い反復（イテレーション）を取り入れる。アジャイル手法は、フレームワークまたは一連のベストプラクティス、プロセス、ツール、アクティビティーに基づいて構築される。こうしたフレームワークは、日常の作業の流れにアジャイル手法を取り入れる際に開発やテストに関する決定を下すための指針となる。

ソフトウェアテストピラミッド（提供：TechTarget）

　反復的な開発を行い市場へのリリース速度を上げるに当たってはさまざまな側面や課題が生まれる。各種フレームワークではそうした側面や課題にそれぞれ固有の対策が取られる。例えば、次のようなフレームワークがある。

• テスト駆動開発（TDD：Test-Driven Development）：開発者がテストを作り、そのテストに合格するコードを開発するアプローチ
• 動的システム開発手法（DSDM：Dynamic Systems Development Method）：コラボレーションに対処するフレームワークで、製品担当者、開発者、テスト担当者だけでなく、事業支援者やサポートチームなど、開発に関係する全ての関係者が確実にコラボレーションを行うプロセスを実現するアプローチ
• ソフトウェアテストピラミッド（Software Testing Pyramid）：ソフトウェア開発ライフサイクル（SDLC）の中の適切なタイミングで、適切なタイプとアプローチのテストを開発チームが決定するのに役立つアプローチ

ソフトウェアテストピラミッドとは

　ソフトウェアテストピラミッド（別称、アジャイルテストピラミッド）とは、短期のイテレーションに効果的なテストプロセスを取り入れるためのベストプラクティスを提供するフレームワークを指す。アジャイルでは、開発サイクルを複数のイテレーションに短縮することで開発速度が向上する。そのため、テストを各イテレーションに組み込まなければならない。開発を終えてからテストするのではなく、テストと開発を同時並行で実施しなければならない。

　ソフトウェアテストピラミッドでは、各種テストのレベルが示される。テストのレベルは各タイプのテストの量別に整理され、各タイプのテストの量はイテレーション中のレベル単位で計画される。テストのタイプと量はピラミッド型になり、底辺に近いテストタイプほどテストの量が多く、レベルが上がるにつれ、必要なテストの量が少なくなる。ソフトウェアテストピラミッドはシフトレフトのプラクティスで、開発のフェーズが早いほどチームが実行するテストの量が多くなる。その結果、修正が容易でコストもかからない早い段階で欠陥を早期発見できる。

　効果的な同時テストを実現するには、シフトレフトを取り入れ、イテレーションの早期にテストするだけでは不十分で、シフトレフトに加え、プロセスの各段階でどのようなタイプのテストをどの程度の量実行するかにも目を向ける必要がある。そうすることで、アジャイル手法の中でソフトウェアテストピラミッドフレームワークの効果が高まる。

ソフトウェアテストピラミッドの実装

　チームは、テストの自動化にソフトウェアテストピラミッドを応用し、ピラミッドの下位レベルでは自動化するテストケースを最大限に増やし、上位レベルでは自動化するテストケースを最小限に抑えるのが一般的だ。テスト自動化の社内ベストプラクティスとしてソフトウェアテストピラミッドを利用する開発チームは多い。

　テストチームは、特に回帰テストを実施する際に、逆ピラミッド（アイスクリームコーン）型のパターンを作成することもある。逆ピラミッド型パターンでは、ユーザーインタフェース（UI）やユーザーのワークフローに関して自動テストスイートの量を増やす。UIやユーザーワークフローに関する自動テストケースの量は、標準ピラミッドでは少なくなるのが一般的だ。

　ソフトウェアテストピラミッドには、テストのタイプやレベルが異なるバージョンが幾つかある。アジャイルチームは、自社のアプリケーションやIT部門に最適なピラミッドを選択できる。例えば、次のようなバージョンがある。

最も基本的なバージョン

　このバージョンでは、単体テスト、統合テスト、エンドツーエンドのテストなどを実施する。機能が限定される単一のアプリケーションに取り組むアジャイルチームに適している。組み込む機能を最小限に抑え、最低限実行可能な製品をリリースしようとするチームがこのバージョンを使うことがある。このバージョンは、開発サイクルの早い段階にテストを実施することに重点が置かれる。ただし、ユーザー対応の処理が多いアプリケーションのテストには適していない。

一般的なバージョン

　このバージョンでは、単体テスト、コンポーネントテスト、統合テスト、システムテスト、手動テストなどが実施される。また、ユーザーワークフローやユーザーエクスペリエンス（UX）に重点を置くブラックボックステストも実施される。そのため、自社の顧客を直接のユーザーとするアプリケーションに特に適している。

最も包括的なバージョン

　複数のアプリケーションを対象とする完全なエンドツーエンドのテストに対応する。このバージョンでは、単体テスト、コンポーネントテスト、統合テスト、システムテスト、システム統合テスト、ユーザーの受け入れテスト（UAT）などが実施される。ハードウェアとソフトウェアの双方がテストの対象となる複雑なアーキテクチャに適している。このバージョンでは、検証と妥当性確認に別の層を用意できるため、規制の対象となるテストに適用できる。

　ソフトウェアテストピラミッドでの複雑さのレベルは違っても考え方は変わらない。

　ピラミッドの基本レベルは、開発サイクルの早期段階で実施される単体テストとコンポーネントテストだ。この基本レベルで実施されるテストの項目が最も多くなる。ピラミッドの下位レベルほど、自動化にかかるコストが最も少なく、自動化の効果が最も高くなる。

　ピラミッドの上位レベルほど、ユーザーの重要度が高くなる。そのため、各テストケースの対象範囲が最も広くなるように自動テストのテストスイートを最適化することが重要になる。ソフトウェアテストピラミッドのレベルが高くなるほど、必要な自動化のメンテナンス量も増えるため、チームは自動化のメンテナンス方針について綿密に計画しなければならない。

単体テスト

　単体テストとは、コードの個別の単位をテストするプロセスで、テストピラミッドの全てのバージョンの基盤となる。徹底的かつ効果的な単体テストによって、欠陥が早期に発見され解決も容易になるため、単体テストによってプロジェクトの成否が決まる可能性がある。どのようなテスト計画でも、単体テストは重点を置く重要な分野にすべきだ。

　開発者は、コードの一部に対して迅速に実行できるテストを作成するために、「JUnit」や「TestNG」などのオープンソースのフレームワークを使って単体テストを自動化するのが一般的だ。コーディングや単体テストの速度を上げるため、TDDを採用する開発者は多い。TDDとは、開発者がまずテストをコーディングしてから、そのテストに合格するようにコードの単位を作成するプロセスを指す。

コンポーネントテスト

　コンポーネントテストは、ソフトウェアテストピラミッドで単体テストの1つ上のレベルに位置付けられる。コンポーネントテストでは、コードの各単位の統合と相互作用を検証する。コンポーネントテストも重要な手法の一つで、開発プロセスの早い段階でモジュール内の欠陥を特定する。最も重要な点は、統合テストに先立って欠陥を見つけることだ。

　現状、使われているコンポーネントテストには2つのタイプがある。小さなアプリケーションの場合、各コンポーネントを相互に分離してテストする。大きなアプリケーションの場合、他のモジュールの助けを借りて各モジュールをテストする。この2つのアプローチはそれぞれ「小規模コンポーネントテスト（CTIS：Component Testing In Small）」と「大規模コンポーネントテスト（CTIL：Component Testing In Large）」と呼ばれる。

統合テスト

　統合テストはソフトウェアテストピラミッドの中間レベルに位置する。統合テストでは、データの流れに注目してモジュールグループの相互作用を検証する。データは、APIを介してモジュール間を流れることが多い。一般的に統合テストではAPIのテストが重視される。APIにはGUI（グラフィカルユーザーインタフェース）がない。そのため、APIテストには自動化が使用される。「Postman」と「Bruno」はAPIテストに最も一般的に使われるツールだ。

システムテスト

　ソフトウェアテストピラミッドのさらに上位のレベルに位置するのがシステムテストだ。システムテストでは、ブラックボックステスト手法を使って、完全に統合を終えたシステム内のワークフローの相互作用を確認する。システムテストはテスト担当者が設計し、ワークフロー内でデータをくまなく追いかける。システムテストはエンドツーエンドテストともよばれる。エンドツーエンドのシステムテストには、機能のテストと機能以外のテストを両方含める必要がある。それは、ソフトウェアテストピラミッドでは、このレベルで初めてユーザーに主な焦点が置かれるためだ。

　機能テストでは、システムが機能の要件を全て満たしていることを確認する。機能テストは「検証テスト」ともよばれる。機能以外のテストでは、負荷テストやストレステストが実施され、アプリケーションが必要な数のユーザーに対応できるかどうかや、可用性、信頼性、セキュリティ、使いやすさ（ユーザビリティ）などの「特性」（イリティーズ）が確認される。このレベルのテストは、運用環境に可能な限り近い環境で実施することが重要だ。

　システムテストも自動化できる。ただし、このレベルのテストの自動化はコストが最も高くなり、テストスイートを絶えず最適化しなければならない。GUIの自動化に利用できるツールは商用もオープンソースも含め多数提供されている。どのようなツールを選択するかは、アプリケーションやアプリケーションスイートのニーズ、自社のテスト自動化計画、テストチームのメンバーが保有するスキルセット、利用可能な予算に左右される。

　複雑なシステムに使用されるソフトウェアテストピラミッドでは、システム統合テストは別のレベルのテストと見なされることがある。システム統合テストでは、エンドツーエンドのシステムテストを複数のアプリケーション全体に拡張し、統合されるシステム全体でのユーザーのワークフローを最初から最後までくまなく追いかける。

ユーザー受け入れテスト

　ソフトウェアテストピラミッドの最上位レベルに位置するのがユーザー受け入れテスト（UAT）だ。UATは「妥当性確認テスト（バリデーションテスト）」とも呼ばれ、ユーザーのニーズに重点を置き、意図する使用法と機能がユーザーの立場から見て正しいことを確認する。

　UATでは、GUIとUXに重点が置かれる。UATでは、自動テストでは見つからなかった欠陥を見つけることが目的となるため、少なくともテストの一部はテストチームが手作業で実行しなければならない。UATに自動テストを組み込むこともあるが、最小限にとどめる必要がある。

　UATはテストチームが実施してもよいが、製品担当者（可能であれば実際のユーザー）がテストを実行することが重要だ。これまでアプリケーションに接していない実際のユーザーは別の角度から貴重な観点をもたらし、開発サイクル全体でテストをしてきた担当者が見落としている可能性のある問題点を拾い上げることができる。

ソフトウェアテストピラミッドの長所と短所

　ソフトウェアテストピラミッドには長所も短所もある。最も大きな長所は、シフトレフトの原則を実現するフレームワークを提供し、開発サイクルの可能な限り早い段階にテストを組み込むことだ。これにより、テストの効果と効率が高まり、開発サイクルの早い段階で見つかった欠陥はあまりコストをかけずに解決できるため、コストが削減される。

　主な短所は、ピラミッドの各レベルで実施するテストの量について規範的過ぎると見なされることだ。ただし、どのようなフレームワークでも、チーム、アーキテクチャソリューション、自社固有の状況に合わせて変更でき、変更する必要があることを忘れないことが重要だ。