業務アプリケーションのテストの話（その２）：テストフェーズはテスト計画の中で定義する

開発フェーズの用語の混乱

システム開発のフェーズ（工程）に関する用語は混乱しています。統一されていないという言い方もできます。

たとえば、要求定義、要件定義は日本語ではそれぞれ別のような意味付けをされていても英語では共に requirements definition らしいです。

外部設計は基本設計あるいは概要設計と呼ばれたり、内部設計は詳細設計と呼ばれたりします。システムの方式設計はアーキテクチャ設計と呼ばれたり、基本設計と呼ばれたりすることがあります。「外部設計」と「システム方式設計」がそれぞれ「基本設計」を名乗るのは混乱以外の何物でもありません。そもそも「基本」って何？ってことが曖昧です。

また、同じ用語を使っていたとしても、組織や個人によってその言葉の定義が微妙にずれていることがあります。したがって、プロジェクト計画時や契約時に各工程の成果物の定義とカバーする内容を、成果物の名前だけでなく、その書きっぷりに踏み込んで合意しておかないと、納品時の揉め事の原因になります。

テストのフェーズに関する用語も同様に不統一です。しかし、テストにおいてはより複雑です。正確には、プロジェクトの前提条件を考慮した上で、全体テスト計画を立案する中でテストフェーズを定義し、関係者で認識を合わせる必要があります。

テストのフェーズを定義する際に意識すべき要素として以下のものがあります。

• テストレベル
• テスト環境
• テスト実施組織

テストレベル

システムの部品同士を接続することを結合、または統合といいます。最も小さな部品から始めて段階的に結合（統合）しテストしていくことをボトムアップテストと呼びます。また、結合（統合）したときのテスト対象の粒度でテストを分類したものをテストレベルと呼びます。具体的には単体テスト、結合テスト、システムテストなどがあります。テストフェーズはまず、これらのテストレベルに対応して計画を開始し、単体テストフェーズ、結合テストフェーズ、システムテストフェーズとします。

ただし、システムテストフェーズは総合テストフェーズと呼ばれることが多いため、以下では総合テストフェーズとします。

テスト環境

テストを実施する環境はテストフェーズを細分化したり統合したりする要素となります。テスト環境は具体的には以下のようなものがあります。

開発環境（ベンダ内）

• 開発者のPC
• 開発用サーバー（群）

結合テスト環境（ベンダ内）

• テスターのPC
• 結合テスト用サーバー（群）
• 性能テスト用サーバー（群）

結合テスト環境（顧客内）

• 結合テスト用サーバー（群）

総合テスト環境（顧客内）

• 総合テスト（業務シナリオテスト）用サーバー（群）
• 総合テスト（性能テスト）用サーバー（群）

運用テスト環境（顧客内）

• 運用テスト用サーバー（群）

本番環境（顧客内）

• 本番用サーバー（群）

テスト実施組織

これらの環境の上で、誰が、何をテストするのか作業計画を行うことでテストフェーズが定まります。誰が、何をテストするのかは、会社組織やプロジェクトによって決まります。

テストフェーズの例（自社サービス開発）

たとえば自社サービスを開発してクラウドに公開しているような企業で、製品開発チーム、テストチームが常時設置されているとすると、テストフェーズを以下のように定義することができます。

単体テストフェーズ

• 開発用PC、開発用サーバー（群）で実施する
• 開発者がxUnitでクラスを自動テストする

結合テストフェーズ

• 開発用PC、開発用サーバー（群）で実施する
• 開発者が画面・帳票・バッチを手動でテストする

総合テストフェーズ

• テスト用PC、総合テスト用サーバー（群）でテストする
• テストチームが画面・帳票を手動でテストする
• 開発者がバッチを手動でテストする

この例ではxUnitを使用してクラスを自動テストする工程を単体テストフェーズ、画面・帳票・バッチのようにアプリケーションとして操作可能なものを手動でテストする工程を結合テストフェーズとしています。これは単体＝クラスという考え方に基づいています。

一方、単体＝機能（画面・帳票・バッチ）ととらえる考え方もあり、SIerの場合は単一の機能をテストするのを「単体テストフェーズ」、機能をいくつか組み合わせてテストするのを「結合テストフェーズ」と呼ぶことが多いと思います。この場合、単体=クラスの意味での単体テストは実施しないことがあります。

テストフェーズの例（受託システム開発）

別の例として、システムを受託開発で構築する場合は、自社、顧客、他ベンダと協力してテストを計画する必要があります。この場合、例えばテストフェーズを以下のように定義することができます。

単体テストフェーズ

• 開発用PC、開発用サーバー（群）で実施する
• 開発者がxUnitでクラスを自動テストする　※実施しない場合もある
• 開発者が個々の機能（画面・帳票・バッチ等）を手動でテストする　※こちらは必ず実施する

内部結合テストフェーズ

• ベンダ内の結合テスト用PC、結合テスト用サーバー（群）で実施する
• ベンダ内のテストチームが機能（画面・帳票・バッチ等）を組み合わせたシナリオをもとに手動でテストする

外部結合テストフェーズ

• 顧客内の結合テスト用PC、結合テスト用サーバー（群）で実施する
• 自社の開発者と、他社の開発者が、互いに対向するシステムとのインターフェースを手動でテストする

総合テストフェーズ（業務シナリオテスト）

• 顧客内のテスト用PC、業務シナリオテスト用サーバー（群）
• 顧客内のテストチームが画面・帳票を手動でテストする
• 開発者がバッチを手動でテストする

総合テストフェーズ（性能テスト）

• 顧客内のテスト用PC、性能テスト用サーバー（群）
• ベンダの性能評価担当者が画面・帳票・バッチを性能評価する 

この例では、テストレベルが「結合テスト」とされる機能（画面・帳票・バッチ等）が開発者によって単体テストフェーズで実施されます。その他の部分はシステム間のインターフェースによって区切られるベンダの担当範囲によって、内部結合テストフェーズと外部結合テストフェーズに分割して実施されます。

 

このように、自社の中で閉じた開発と、顧客や他のベンダと作業分担して行う開発とでは、テストフェーズの定義の仕方が大きく異なります。

「結合テスト」という用語を使ったとき、相手は違う内容を思い浮かべているかもしれません。認識齟齬があると後に問題が発生したときに揉める原因となります。

 

したがって、特定のテストフェーズの意味を確認してから関係者とテストに関する調整をすることが大変重要です。