受け入れテストは、ソフトウェアを導入する前の最終的なテスト作業です。受け入れテストの目的は、ソフトウェアが導入できる状態になっていることの確認と、エンド ユーザーがそれを使用することによりそのソフトウェア開発の目的だった機能と作業を実行できることの確認です。受け入れテストの実行には、次のように、通常 3 つの戦略があります。

通常どの戦略を選ぶかは、契約上の要求、組織、企業の標準、アプリケーションの分野によって決まります。

公式の受け入れテスト ページの先頭へ

公式の受け入れテストは、厳密に管理されたプロセスであり、往々にしてシステム テストの拡張されたものとなります。このテストはシステム テストと同じように慎重に、また詳細に計画、設計します。選択するテスト ケースは、システムテストで実行されるものの下位グループとします。選択したテストケースからは、決して逸脱しないことが重要です。多くの組織では、公式の受け入れテストは完全に自動化されています。

作業や成果物は、システム テストと同じです。一部の組織では、開発組織 (またはその独立したテスト グループ) がエンド ユーザー組織の代表と共に受け入れテストを実施しています。また、エンド ユーザー組織やエンド ユーザ組織が指定する対象グループと共同で受け入れテストを実行する場合もあります。

このような公式のテストのメリットは次の通りです。

  • テスト対象の機能と特徴が分かっている。
  • テストの詳細が分かっており、評価することができる。
  • テストを自動化することができ、それにより回帰テストも可能である。
  • テストの進捗を測定、監視することができる。
  • 受け入れの基準が分かっている。

またデメリットには次のようなものがあります。

  • かなりのリソースと計画を必要とする。
  • システム テストの再実装となる可能性がある。
  • ソフトウェアの中の特定の障害のみに注目するあまり、主観的な障害を発見できない可能性がある。

非公式の受け入れテスト ページの先頭へ

非公式の受け入れテストでは、テスト実行のための手順は公式の受け入れテストほど厳密に定義しません。調査すべき機能やビジネス上のタスクは明らかにした上で文書化しますが、特に注目すべきテスト ケースはありません。何をするかは、個々のテスト担当者が判断します。このテストでは、公式の受け入れテストほど厳しい管理は行われず、また公式の受け入れテストよりも主観的です。

通常、非公式の受け入れテストはエンド ユーザー組織によって実行されます。

このテストのメリットは次のとおりです。

  • テスト対象の機能と特徴が分かっている。
  • テストの進捗を測定、監視することができる。
  • 受け入れの基準が分かっている。
  • 公式の受け入れテストよりも、多くの主観的な障害を検出できる。

またデメリットには次のようなものがあります。

  • 計画と管理にリソースが必要。
  • 使用するテスト ケースを決定できない。
  • エンド ユーザーは、システムの機能を確認するだけで、障害を検出できない可能性がある。
  • エンド ユーザーは、障害に目を向けず、古いシステムと新しいシステムの比較に熱中してしまう可能性がある。
  • 受け入れテストのリソースは、プロジェクトの管理外となるため、制約が生じる可能性がある。

ベータ テスト ページの先頭へ

ベータ テストは、3 つの受け入れテスト戦略の中で最も制御ができないテストです。ベータ テストでは、詳細、データ、アプローチは個々のテスト担当者の判断に完全に委ねられます。各担当者は、独自の環境を構築し、独自にデータを選択し、どの機能、特徴、タスクを調査するかを独自に判断します。各担当者は、現状でこのシステムを受け入れるかどうか、自分の責任で独自の基準を設定します。

ベータ テストはエンド ユーザーが実施し、その際、開発組織 (または他のエンド ユーザー) の管理はほとんど、またはまったく介在しません。ベータ テストは、すべての受け入れテスト戦略の中で最も主観的なテストです。

このテストのメリットは次のとおりです。

  • テストはエンド ユーザーが実行する。
  • 大量のテスト リソースを利用できる可能性がある。
  • 参加した顧客は、顧客満足度が増す。
  • 公式、非公式の受け入れテストよりも、多くの主観的な障害を発見できる。

またデメリットには次のようなものがあります。

  • すべての機能、特徴についてテストできない。
  • テストの進捗の測定は難しい。
  • エンド ユーザーは、システムの機能を確認するだけで、障害を確認、報告できない可能性がある。
  • エンド ユーザーは、障害に目を向けず、古いシステムと新しいシステムの比較に熱中してしまう可能性がある。
  • 受け入れテストのリソースは、プロジェクトの管理外となるため、制約が生じる可能性がある。
  • 受入れ基準が分からない。
  • ベータ テスト担当者を管理するためのサポート リソースの追加が必要となる。


Rational Unified Process   2003.06.15