概念: テストのレベル
テストは、作業のさまざまな段階やさまざまなレベルで、さまざまな対象に対して実施されます。テストのレベルは、一般に、テストを設計し実施するために最も適したスキルを持つ役割と、各レベルのテストに最も適した手法によって分類されます。これらの異なる作業全体に渡って確実に焦点のバランスが保たれていることが重要です。
開発者テスト 
開発者テストとは、開発者チームが設計と実装を担当するのが最も適切なテストです。これは、独立テストと対比して使用される分類です。ほとんどの場合、最初にそのテストを実行するのはテストの設計と実装を担当した開発者テスト グループですが、開発者は独立テスト グループにも実行できるような方法でテストを作成しておくのが正しいアプローチです。
従来、開発者テストは主としてユニット テストに関するものであると見なされていました。開発者がさまざまなレベルの統合テストまで行う場合もありますが、これは多分に文化やその他の状況的な問題に依存しています。開発者テストでは、独立したユニットだけ切り離してテストするのではなく、より広い範囲をカバーすることをお勧めします。
独立テスト
独立テストとは、開発者チーム外の人物が設計と実装を行うのが最も適切なテストです。この区分は、その一部として独立検証を含む上位集合と見なすことができます。ほとんどの場合、そのテストを最初に実行するのはテストの設計と実装を担当した独立テスト グループですが、独立テスト担当者は開発者テスト グループにも実行できるように独立テストを作成すべきです。ボーリス バイザーは、独立テストの開発者テストとは異なる目的について次のように説明しています。
「独立テストの目的は、開発者とは異なる物の見方を提供し、ひいては異なるテストを提供することです。さらに、開発者に与えられているよりも恵まれた [中略] 環境の中でこれらのテストを実行することも独立テストの目的です。」 参考資料 [BEI95]
独立利害関係者テスト
独立テストのもう一つの見方は、それがさまざまな利害関係者のニーズと利害関係に基づいたテストを表しているという点です。このため、このテストは「利害関係者テスト」とも呼ばれます。これは重要な区分です。これにより、顧客とエンド ユーザーだけでなくテクニカル サポートのスタッフ、テクニカル トレーナー、販売スタッフなどの利害関係者までをやや包括的な「顧客」に含めて、従来考慮されていたよりも幅広い利害関係者の利害関係を取り込むことができます。
ちなみに、XP の概念では、顧客テスト (customer tests) が RUP の独立テストのカテゴリに相当します。
ユニット テスト 
ユニット テストでは、ソフトウェアのテスト可能な最小要素の検証に焦点を当てます。ユニット テストは、通常、実装モデルの中で表された各コンポーネントに適用され、必要な制御フローとデータ フローが正しく網羅されていて、それらが期待どおりに機能することを確認するために実施されます。ユニット テストは、実装担当者がユニットを開発するときに実行します。ユニット テストについて詳しくは、実装の作業分野で説明します。
統合テスト 
統合テストは、実装モデル内の各コンポーネントがユース ケースを実行するために結合されたときにも正常に動作することを確認するために実行されます。テストの対象は、実装モデル内の 1 つのパッケージまたは一連のパッケージの組み合わせです。多くの場合、結合される各パッケージは異なる複数の開発組織から得られます。統合テストでは、パッケージのインターフェイス仕様における不完全性や誤りを見つけ出します。
ときとして、開発者が、統合テストは独立テスト担当者などのほかのグループにより実行されるものとして作業している場合があります。このような場合、次の理由からソフトウェア プロジェクトにリスクが生じ、最終的にはソフトウェアの品質にまでそのリスクが及びます。
- 統合領域は、ソフトウェアの失敗の一般的なポイントである
- 独立テスト担当者が行う統合テストでは、一般にブラック ボックス手法が使用され、通常は比較的大きいソフトウェア コンポーネントが扱われる
より優れたアプローチでは、開発者と独立テスト担当者の両方が統合テストを担当しますが、両チームのテスト作業の戦略は互いにあまり重複しないようにします。厳密にどのような部分が重複するかは、個々のプロジェクトのニーズにより異なります。いずれにしても、開発者と独立システム テスト担当者が品質について単一のビジョンを持てるような環境を作ることをお勧めします。詳しくは、「概念: 開発者テスト」を参照してください。
システム テスト 
従来は、システム テストはソフトウェアが全体として機能するようになった段階で行われていました。反復型ライフサイクルでは、もっと早い段階—ユース ケースの振る舞いの適格なサブセットが実装された段階—でシステム テストを実行することが可能です。通常の対象は、システムの機能する状態になったエンドツーエンド要素です。
受け入れ テスト 
ユーザーによる受け入れテストは、ソフトウェアを導入する前に行われる最終的なテスト作業です。受け入れテストの目的は、ソフトウェアが導入できる状態になっていることの確認と、エンド ユーザーがそれを使用することによりそのソフトウェア開発の目的だった機能と作業を実行できることの確認です。詳しくは、「概念: 受け入れテスト」を参照してください。
これとは別の概念の受け入れテストもあります。一般に、グループ間やチーム間でのハンドオフの際に発生する受け入れテストです。たとえば、ビルド受け入れテストは、新しいソフトウェア ビルドが開発から独立テストへ引き渡される際に、その受け入れに対して行われるテストです。
テスト レベルの順序とタイミングに関するコメント 
従来は、ユニット テストは反復のごく早い時期 (テストの最初の段階) で実装されるものと思われていました。すべてのユニットが、次の段階に入るより前にユニット テストに合格していなければならないと考えられていたのです。しかし、反復的な開発プロセスでは、このアプローチは一般規則として適切ではありません。より優れたアプローチでは、エラーを発見できる可能性が最も高いユニット テストや統合テスト、システム テストを明らかにし、最大のリスクとサポート環境の組み合わせに基づいてそれらを実装して実行します。
|