パターン18:アプリケーション設計はテスト設計の制約を受ける

   

 

問題:

いつテスト設計し、テスト項目を決定し、テストスクリプトを作成しますか?

コンテキスト:

ソフトウエアアーキテクチャーを記述し決定し、開発者がコーディングするというある仕組みを持つシステムにおいて、テストする役割が決められようとしている。

影響する事柄:

テストの計画・設計・項目決定・実施には時間がかかり、システムが完成してからでは遅すぎる。(「何をテストすべきかをいつ知るのか。」)

要求仕様がわかった時にシナリオがわかる。シナリオの多くは早い時期にわかる。

テスト項目決定には、メッセージフォーマットの詳細やインタフェース、あるいはソフトウエアアーキテクチャーに関する非常に詳細な点まで知らなければならない。

ソフトウエアの設計仕様は毎日変わる。テスト設計がソフトウエアの設計仕様のはかない変更を追跡する必要はまったくないのではないか。

解決策:

要求仕様のシナリオが顧客に合意された時点で、シナリオに基づくテスト設計が始まる。テスト設計はソフトウエア設計と同時進行するが、顧客のシナリオにのみ対応すればよい。テスト者には、ソフトウエア自身を使用することはできないからである。アーキテクチャ上のインタフェースが安定したと開発者が決定した時に低レベルのテスト設計とテスト項目決定を進めることができる。

結果として生じるコンテキスト:

これは、QAの参加シナリオは問題を明らかにするのパターンの結果と同様である。

論理的根拠:

テスト者がソフトウエアを使用できるような状態にすると、テスト者は顧客の観点よりも開発者の観点で見るようになってしまう。そして、間違ったことをテストしたり、詳細について間違ったレベルのテストをしてしまうようなことも起こりうる。さらに、ソフトウエア自身は要求仕様から掴み所のないアーキテクチャまで変化を続け、インタフェーステストが落ち着くまでは、テスト設計がソフトウエア設計の後を追いかけなければならないということでは困る。

手短にいうと、要求仕様の最初の主要な流入の最終時点でテスト設計を開始する。そして、アーキテクチャが安定した時に再度基本的な設計の見直しを行う。

このパターンは、(まだ記述されていない)パターン“Testing first in last out”、QAの参加およびシナリオは問題を明らかにするのパターンに関連する。