Vietnamese
Englishテストレベルについて
テストは、ユニットまたはコンポーネントからシステムまたはシステムオブシステムズ（銀行などで使われるような複数のシステムから構成される大規模なシステム）まで、さまざまなレベルに分けて実施します。
コードが正しく書けたかを確認するテストと、ユーザーが業務で便利に使えるかを確認するテストは、テストの目的や、テストによって見つかる欠陥も異なります。異なるものを一緒にテストするよりも、それぞれを系統的にまとめ、マネジメントしていく方が効率的です。
テストレベルは、開発を進めていく活動、つまり、要件定義、基本設計、詳細設計といった活動と関連付けることができます。
実際のプロジェクトでは、テスト対象によって開発を進めていく活動はもっと多くの段階を経由していきます。そのため、テスト対象の規模に合わせてテストレベルの定義も数も変わります。
この記事では、多くの組織で使用されている次の4つのテストレベルについて解説をしています。
・コンポーネントテスト
・統合テスト
・システムテスト
・受け入れテスト
1/ コンポーネントテスト
コンポーネントやモジュールといった分離可能なソフトウェアを、モックオブジェクト、サービス仮想化、ハーネス、スタブ、ドライバ、シミュレーターなどを使用して、システムの他の部分から切り離してテストします。このテストは、ユニットテストやモジュールテストとも呼ばれることがあります。
テストの目的
コンポーネントテストの目的は次の通りです。
・テスト対象の欠陥を見つけ出す
・テスト対象の機能が仕様通りに動作するかを確認する
・テスト対象の非機能的な挙動が設計や仕様通りであるかを検証する
・テスト対象の品質が信頼できるものであることを確かめる
・欠陥を見逃さずに発見する
・リスクを最小限に抑える
テスト対象
以下のものがコンポーネントテストの対象として挙げられています。
・コンポーネント、ユニット、モジュール
・コードおよびデータ構造
・クラス
・データベースモジュール
テストタイプ
コンポーネントテストで実施される主なテストタイプは以下の通りです。
・機能テスト
・非機能テスト
・ホワイトボックステスト
・リグレッションテスト
典型的な欠陥と故障
コンポーネントテストでよく見つかる欠陥には次のようなものがあります。
・仕様と異なる不正な機能
・データフローの問題
・誤ったコードやロジック
性能測定を通じてボトルネックを特定し、それを性能欠陥とみなす場合もプロジェクトによってはあります。
コンポーネントテストでは、欠陥を発見したらすぐに修正を行うケースが一般的です。ただし、これは欠陥管理ツールを使用しないという意味ではありません。ツールは活用しつつ、組織標準のワークフローや欠陥分類に厳密に従う必要がない、という意味です。
そのため、「コンポーネントテストでは欠陥管理を行うべきではない」と誤解しないようにしましょう。プロジェクトによっては、コンポーネントテストで欠陥管理を行い、プロセス改善に役立てるケースもあります。
状況に応じて、スピードを重視するのか、それともプロセス改善を目指すのかを判断し、欠陥管理への取り組みを決定することが望ましいです。
テスト実行者（責務の割り振り）
コンポーネントテストは、通常ソースコードを作成した開発者自身が実施しますが、場合によってはテスト専門チームの担当者が行うこともあります。このテストは、開発者単独で進めるというよりも、他の開発メンバーを巻き込みながら実施されます。また、コンポーネントテストで発見された欠陥は、開発者自身が修正を担当します。
固有のアプローチ
アジャイル開発では、テストを自動化することが一般的です。テストリストを作成し、自動化されたテスト実行の仕組みを構築します。そして、テストケースの開発サイクルをもとにソースコードを作成し、コンポーネントテストに合格するまで修正と反復を繰り返します。
近年、アジャイル開発のようにソースコードを継続的に変更するスタイルが主流となってきました。これに伴い、コード変更が既存のコンポーネントに悪影響を及ぼしていないかを確認するため、リグレッションテストによる信頼性の確認が重要な目的となります。
多くの組織やプロジェクトでは、「非機能的な挙動の確認はシステムテストレベルで行う」という考え方が一般的かもしれません。確かに、機能テストで欠陥を十分に検出した後に非機能テストを実施するのが通常の流れです。しかし、コンポーネントテストの段階で重要なモジュールの性能を測定し、適切にチューニングすることも非常に重要です。これを怠ると、システムテストの段階で性能問題が発生し、コード修正に多大な工数がかかり、最終的には製品リリースに影響を与える可能性があります。
したがって、コンポーネントテストにおいても非機能的な振る舞いを確認することがある点を認識しておくことが大切です。
2/ 統合テスト
統合テストは、大きく分けて「コンポーネント統合テスト」と「システム統合テスト」の2種類があります。
コンポーネント統合テスト
コンポーネント統合テストは、コンポーネントテストが終了した後に実施され、コンポーネント間のインターフェースや相互の動作に重点を置いてテストを行います。このテストでは、個々のコンポーネントの機能自体はすでにコンポーネントテストで評価されているため、主にコンポーネント同士の連携部分に焦点を当てます。
特に、イテレーティブ開発やインクリメンタル開発においては、このテストを自動化し、継続的インテグレーションの一環として実施することが一般的です。
コンポーネントテストが完了していることを理由に、多数のコンポーネントを一度に統合してテストを効率化しようとする（いわゆる「ビッグバン統合」）ケースもありますが、これはしばしば誤ったアプローチとなります。なぜなら、統合範囲が広いと、故障が発生した場合に欠陥の原因となったコンポーネントを特定するのが難しくなり、結果としてデバッグや修正に多くの時間がかかるからです。欠陥の特定と修正を迅速に行うためには、統合を段階的に進めることが重要です。
そのため、現在では、一度に統合するのではなく、段階的に統合を進める「体系的な統合戦略」に基づいた統合テストが広く採用されています。この戦略では、システムアーキテクチャ（トップダウンやボトムアップなど）、機能タスク、トランザクション処理シーケンスなどを基準に、統合を少しずつ進めていきます。
段階的統合を実施する際、テスト実行者が統合戦略の構造を正しく理解し、統合による影響を把握していることが理想的です。これにより、統合プロセスがスムーズに進み、欠陥の早期発見と修正が効率よく行えるようになります。
システム統合テスト
システム統合テストは、システムテストの後または並行して実施され、他システムとのインターフェースや相互処理を重点的にテストします。システムテストでは他システムの動作をシミュレートするため、実際に統合された環境でビジネスプロセス全体を確認するテストが必要です。たとえば、受注処理システムを出荷処理システムや請求処理システムと統合し、販売管理プロセス全体をテストします。
テスト対象
システム統合テストでは、以下が主な対象となります。
・他システムとのインターフェースと相互処理
・パッケージやマイクロサービス
・外部組織が提供するWebサービス
外部システムやサービスを統合する際には、テスト環境やスケジュールに制約があり、特に確認テストの調整に時間を要する場合があります。これは開発モデルに関わらず発生し得ます。
テスト目的
統合テストの目的は以下の通りです。
・テスト対象およびインターフェースに潜む欠陥の検出
・インターフェースの機能的振る舞いが設計・仕様通りであることの検証
・非機能的振る舞いが設計・仕様通りであることの検証
・インターフェースの信頼性を確認し、品質を向上させる（信頼の積み上げ）
・欠陥の見逃しを防止
・リスクの軽減
テスト対象
統合テストの対象として、以下が挙げられます。
・サブシステム
・データベース
・インフラストラクチャー
・インターフェース
・API
・マイクロサービス
テストタイプ
統合テストでは、次のようなテストを実施します。
・機能テスト：仕様通りに機能することを確認
・非機能テスト：性能や信頼性などの設計仕様を確認
・ホワイトボックステスト：内部構造やロジックを検証
・リグレッションテスト：変更が既存のシステムやインターフェースに悪影響を与えないことを確認
特にリグレッションテストは重要で、変更がシステムに影響を与えないことを検証します。また、自動化して効率を向上させる場合もあります。性能テストをコンポーネント統合テストの段階で行うこともあります。
テストで見つかる典型的な欠陥と故障
コンポーネント統合テストでの典型的な欠陥と故障
・不正確なデータ、データ不足、または誤ったデータエンコーディング
・インターフェース呼び出しの順序やタイミングの誤り
・インターフェースの不整合
・コンポーネント間の通信エラー
・通信エラーへの対応不足や不適切な処理
・データの意味、単位、境界に関する誤った仮定
システム統合テストでの典型的な欠陥と故障
・システム間で統一されていないメッセージ構造
・インターフェースの不整合
・システム間通信のエラー
・通信エラーへの対応不足や不適切な処理
・データの意味、単位、境界に関する誤った仮定
・セキュリティ規制への非準拠
統合テストでは、これらの欠陥を早期に検出し、システム間の信頼性を確保することが重要です。
テストの実行者（役割の分担）
コンポーネント統合テストは、主に開発者が担当します。システム統合テストは、主にテスト担当者が実施します。
固有のアプローチ
開発前に統合戦略と統合テスト計画を策定することで、ソフトウェアアーキテクチャやシステムアーキテクチャを考慮したテスト計画を立てることができ、テストの効率を最大限に引き出しながら開発を進めることができます。
3/ システムテスト
システムテストでは、マスターテスト計画やシステムテスト計画で定義されたシステム全体のソフトウェアプロダクトにおける機能面と非機能面の両方を確認するために、システムのエンドツーエンドの動作や能力をテストします。
テストの目的
システムテストには、以下のようなさまざまな目的があります。
・テスト対象に潜在する欠陥を検出すること
・テスト対象の機能的な動作が設計および仕様に沿っているかを確認すること
・テスト対象の非機能的な動作が設計および仕様に沿っているかを確認すること
・システムが完成し、期待通りに動作するかを検証すること
・システムが法的または規制上の要求や標準に適合しているかを確認すること
・システム全体の品質が信頼性の高いものであるかを確認すること（信頼性の積み上げ）
・システムテストで見逃すべきでない欠陥が見過ごされないようにすること
・データの品質を検証すること
・リスクを軽減すること
テスト対象
システムテストにおけるテスト対象として、以下の種類があります。
・アプリケーション
・ハードウェア/ソフトウェアシステム
・テスト対象システム（SUT）
・システム構成および構成データ
テストタイプ
システムテストでは、機能テスト、非機能テスト、ホワイトボックステスト、リグレッションテストなどを実施します。システムテストは、システムの機能要件、非機能要件、およびデータの品質特性をテストするもので、これらを検証するためにさまざまなテストタイプが使用されます。
リグレッションテストは、変更によって既存の機能やエンドツーエンドの能力が破壊されていないかを確認するもので、場合によっては自動化されることもあります。
テストで見つかる典型的な欠陥と故障
システムテストで発見される典型的な欠陥や故障には、以下のようなものがあります。
・計算ミス
・システムの機能的または非機能的振る舞いが正しくない、または期待通りでない
・システム内の不適切な制御フローやデータフロー
・エンドツーエンドの機能的タスクを正しくかつ完全に実行できない
・本番環境でシステムが正常に動作しない
・システムマニュアルやユーザーマニュアルに記載された通りにシステムが動作しない
仕様に関する欠陥は、システムの振る舞いに関して誤った期待結果を引き起こし、その結果、偽陽性や偽陰性のテスト結果が発生することがあります。テスト担当者は、動的テストの前にユーザーストーリーのリファインメント（内容のレビューや修正、認識合わせ、見積もりなど）に関与し、静的テスト活動を早期に行うことで、このような状況を回避することができます。
テスト実行者（責務の割り当て）
システムテストは、開発組織内のテスト担当者が実行する場合もあれば、独立したテストチームが担当する場合もあります。
固有のアプローチ
システムテストでは、適切なテスト技法を使用します。例えば、ビジネスルールに基づく機能的な振る舞いの確認にはデシジョンテーブルを活用します。
また、システムテストは、コンポーネント統合テストが行われた開発環境ではなく、できるだけ本番環境に近いテスト環境（ステージング環境）で実施することが理想的です。理由は、開発環境では発見できない環境関連の故障をシステムテストで検出する必要があるためです。
システムテストの結果を基に、リリースの可否を判断することもあります。
4/ 受け入れテスト
受け入れテストは、システムテストと同様に、システムやソフトウェアプロダクト全体の機能的および非機能的な側面を評価します。受け入れテストは、リリース直前だけでなく、ソフトウェアライフサイクルのさまざまな段階で実施されます。受け入れテストには、以下のようなさまざまな種類があります。
・ユーザー受け入れテスト
・運用受け入れテスト
・契約に基づく受け入れテスト
・規制に基づく受け入れテスト
・アルファテストおよびベータテスト
ユーザー受け入れテスト ユーザー受け入れテストは、ユーザーがシステムがビジネスに適しているかを確認するためのテストです。ビジネスの運用環境または模擬運用環境で、ユーザーが実際にシステムを使用し、ニーズや要件を満たしているかどうかを検証します。
運用受け入れテスト 運用受け入れテストは、運用担当者やシステム管理者がシステムの運用面に焦点を当てて行うテストです。本番環境または模擬本番環境で行うことが一般的で、以下のような内容が含まれます。
・バックアップおよびリストアのテスト
・インストール、アンインストール、アップグレード
・災害復旧
・ユーザー管理
・メンテナンス
・データ移行とローディング
・セキュリティ脆弱性のチェック
・性能テスト
契約に基づく受け入れテスト 契約に基づく受け入れテストは、カスタムメイドのソフトウェアを開発する際、契約書に記載された受け入れ基準に従って検証を行うものです。受け入れ基準は契約締結時に合意された内容に基づいて設定され、その基準に適合しているかどうかをテストします。
規制に基づく受け入れテスト 規制に基づく受け入れテストは、政府、法律、安全基準などに従っているかを検証します。会計、セキュリティ、医療など、さまざまな分野で法律や基準が存在し、それらに適合しているかを確認するテストです。
アルファテストおよびベータテスト 市販ソフトウェアの場合、製品を市場にリリースする前に、将来のユーザーや既存の顧客からフィードバックを得るために実施するテストがアルファテストやベータテストです。通常、アルファテストの後にベータテストが行われますが、アルファテストなしでベータテストを行うこともあります。
テスト目的
・システムの機能的な動作が仕様通りであるかを確認するため
・システムの非機能的な動作が仕様通りであるかを確認するため
・システムが完成し、期待通りに動作するかの妥当性を確認するため
・システム全体の品質が信頼性のあるものであるかを確認するため
テスト対象
受け入れテストにおけるテスト対象として、以下の種類があります。
・テスト対象のシステム
・システム構成および構成データ
・完全に統合されたシステムのビジネスプロセス
・運用プロセスおよびメンテナンスプロセス
・レポート
・書式
・保存または変換された運用データ
テストで見つかる典型的な欠陥と故障
受け入れテストで発見される典型的な欠陥や故障として、以下のような例があります。
・システムのワークフローがビジネス要件やユーザー要件を満たしていない
・ビジネスルールが正しく実装されていない
・システムが契約や規制要件を満たしていない
・セキュリティ脆弱性、高負荷時の性能不足、サポート対象プラットフォームでの誤動作など、非機能的特性に関する故障
テスト実行者（責務の割り当て）
受け入れテストは、顧客、ビジネスユーザー、プロダクトオーナー、システムの運用担当者、およびその他のステークホルダーによって実施されます。
受け入れテストの各形態における主なテスト実行者は以下の通りです。
【ユーザー受け入れテスト】
- 顧客
- ビジネスユーザー
【運用受け入れテスト】
- 運用担当者
- システムアドミニストレーター
【契約による受け入れテスト】
- ユーザー
- 独立したテスト担当者
【規制による受け入れテスト】
- ユーザー
- 独立したテスト担当者
- 規制機関（テスト結果を検証または監査する場合）
【アルファテスト】
- 潜在的な顧客
- 既存の顧客
- システム運用者
- 独立したテストチーム
【アルファテスト】
- 潜在的な顧客
- 既存の顧客
- システム運用者
固有のアプローチ
シーケンシャル開発では、受け入れテストは通常ライフサイクルの最後に行われますが、以下のタイミングでも実施されることがあります。
・市販ソフトウェア（COTS）では、インストール時や統合時に受け入れテストを実施
・新機能の開発を委託している場合、システムテスト前に受け入れテストを実施し、インターフェースや相互処理に欠陥がないことを確認
イテレーティブ開発では、各イテレーションの最後や完了後、または複数のイテレーション後に受け入れテストを行います。
受け入れテスト結果に基づき、システムがリリース準備できているか、顧客が使用可能かを評価することがあります。
※練習問題をやりましょう！！