パターン19:QAの参加    

図3 Borland社のWindows向けのQuattro Proの開発では、QAは開発の中心であった。

問題:

どのようにして製品の品質を保証しますか?

コンテキスト:

開発組織における役割の集まりと顧客がいて、そして製品の品質を保証するための開発組織と顧客の間での何かのフィルタを必要としている。

影響する事柄:

開発者は何事も正しくできると感じている。

完全なソフトウエアはほとんどありえない。

品質はいつも後回しになる。

成功は高い品質にかかっている。

基本的な品質上の問題にとって、早い時機でのフィードバックは重要である。

解決策:

QAに中心的な役割をさせなさい。何かテストできるようなものが出来次第、QAと開発とを強い関わり合いを持つようにしなさい。テスト計画の作成はコーディングと平行して進めることができるが、開発者はテストを開始していいかどうかを宣言しなければならない。

QA組織はプロジェクトの外側に位置づけるべきである。すなわち、テストの計画と報告の責任は開発組織にあってはならない。

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

QAが参加すると、プロジェクトは顧客へのアプローチの準備ができる。QAと顧客が参加すると、品質保証プロセスを開始できる(利用例が収集されるなど)。

論理的根拠:

すくなくとも、QAを開発者が忠誠を誓っている組織とは別にする理由がいくつかある。まず第1に、テスト開発者は開発者にありがちな偏見を持っていてはならない。もし、開発者とQAが別々に独自のテストをしたとすると、テストはそのソフトウエアを対象とした両目をつむった実験になってしまう。第2に、QAは、客観性を持つために、開発組織からの影響を受けるような範囲の外に置かれるべきである。

これはQPWにおける明白なパターンである。アプリケーション設計はテスト設計の制約を受けるのパターンをも参照してください。