ソフトウェアテスターのための4つのレッスン−1 レッスン1 ［何もせずに取り残されるな］：The Rational Edge （26）（3/4 ページ）

[Len DiMaggio（IBMソフトウェアQEエンジニア／マネージャ），＠IT]

レッスン3 ［相違に注意を払え］

　機能、システム、ストレスなどの各種ソフトウェアテストに関する文献は多いが、見落とされることの多いテストが1つある。統合テストだ（注9）。

【注9】Len DiMaggio著、「Testing at the Boundaries」、およびLen DiMaggio 著、「Orchestrating Integration Testing」、STQE Magazine、2003年7月/8月合併号。

　統合テストはなぜ重要なのだろうか？ この質問には質問で答えよう。自社製品のソフトウェアをすべて実際に自分で書く人はいまもいるだろうか？ 答えはノーだ。ますます多くの製品が、少なくとも一部は、サードパーティから供給されたコンポーネントで構築されるようになっている。これは、オープンソースであったり、フリーウェアであったり、他社との提携であったりする。どちらにしても、コンポーネント、システム、サーバなどの統合テストがますます重要になっている。複数のシステムを統合することは、要するにシステム同士を結合するための共通言語を構築していることになる。この言語の要素には、ソフトウェアの依存性、コンフィグレーションデータ、内部および外部プロセスのコーディネートとデータフロー、イベントレポート作成、そしてセキュリティなどが含まれる。統合テスト（「集約テスト」の方が適切な用語かもしれない）は、これらの言語要素と統合システム全体の動作を検証し、これらの間でコンフリクトが発生する場所を特定するために実施される。

　統合テストを成功させるためには、ソフトウェア統合のどの側面を検証すべきなのだろうか？ 筆者の意見を以下に述べる。

◆ インストレーションとコンフィグレーション。統合される各種ソフトウェアシステムをその配布メディアから目的のシステムへと移動できないと、統合はあまりはかどらない。また、そのシステムがコンフリクトを起こすライブラリをインストールしたり、コンフリクトを起こす環境変数を定義するようでも統合がはかどらない。

◆ データの互換性。どのプログラムでも、多階層のデータパースや変換はできるが、毎回これを行う必要があると、どこかの時点でパフォーマンスが低下してくる。そして、もし微妙なデータパターンを見過ごすと、ユーザーに発見を委ねなくてはならない時限爆弾をシステムに残すことになる。

◆ プログラム間のコーディネーション。統合するシステムはどれも、単体ではサーバ上で動作するほかのソフトウェアに一切影響を与えず、適切に動作するかもしれない。しかし、2つのシステムが一緒になると、もう一方よりも先に起動しないと適切に動作しないようなものも出てくる。

◆ モニタリングとログ記録。誰に気付かれることもなくプログラムのほんの一部が破綻しても、システム全体がダウンするだろうか？ いかにうまく設計され、構築されたシステムでも、いつかは問題が発生する。そのときデバッグを行うためには、とにかくあらゆる情報が必要になってくる。複数のシステムが統合されている場合、さまざまな場所から、さまざまな形でデバッグ情報を入手できなくてはならないため、この作業はさらに複雑化してくる。

◆ セキュリティ。これが終始一貫して必要だ。連結されたシステムの強度は、最も弱いつなぎ目で決まる。そして、この弱いつなぎ目がシステム全体を危険にさらすのだ。

◆ パフォーマンスとスループット。低いパフォーマンスは、統合システムを台無しにしてしまう。ボトルネックは、ユーザーがシステムの反応にいら立つ前に特定し、解消する必要がある。

◆ 信頼性。問題はいつかは発生する。もし発生したら統合システムは機能停止を回避できるだろうか？ もしできない場合、影響を受けるサブシステムは復旧することができるだろうか？

◆ 保守性と拡張性。遅かれ早かれ、どのシステムもパッチ、サービスパック、修正などの世話になる。これらのソフトウェアアップデートは矛盾なくインストールできるだろうか、そして、システムは保守作業中も動作し続けることができるだろうか？ サポートスタッフは複数のインストレーション手順を学ぶ必要があるのだろうか？ さらに、もし徐々にでも自社の成長が期待されるなら、統合システムが確実に拡張をサポートできるようにしておきたい。