6.3テストと品質保証

「テストは最後にまとめてやればよい」という発想は、レベル4の設計者には通用しません。システムアーキテクトは、開発の各段階（モジュール単体→結合→システム全体→発注者受入）でどのテストが何を保証するのかを設計し、テストの進捗自体が正常に収束しているかをデータで判断する責任を負います。テスト工程の設計を誤ると、本番後に致命的な不具合が発覚し手戻りコストが跳ね上がります。

6.3.1単体・結合・システム・受入テスト

• 単体テスト＝関数・クラス・モジュールなど最小単位を単独で検証するテスト。開発者自身が担当し、内部ロジックの分岐や境界値を細かく確認できる一方、モジュール間の連携（インタフェースの食い違い等）の不具合は検出できない。
• 結合テスト＝単体テスト済みの複数モジュールを組み合わせて、モジュール間のインタフェース（データの受け渡し・呼び出し順序等）が正しく機能するかを検証するテスト。システムテスト＝結合済みのシステム全体が、業務要件・非機能要件（性能・可用性等）を満たすかを、実運用に近い環境で検証するテスト。
• 受入テスト＝開発を発注した利用者・発注者側が主体となって、要件通りに完成しているか、実業務で使えるかを最終確認するテスト。開発者側のテストとは主体が異なり、発注者が合意した受入基準を満たすかどうかが合否の判定基準になる。

6.3.2性能・負荷・セキュリティテストと信頼性成長曲線

• 性能テスト＝想定される通常の利用状況・利用者数のもとで、要件で定めた応答時間・スループットを満たすかを確認するテスト。負荷テスト＝想定を上回るアクセス集中や大量データ投入など限界に近い、または限界を超える負荷をかけ、システムがどこまで耐えられるか・どう振る舞う（緩やかに劣化するか、突然停止するか）かを確認するテスト。
• セキュリティテスト＝脆弱性診断・ペネトレーションテスト等により、想定していない入力や攻撃に対してシステムが安全に振る舞うかを確認するテスト。機能要件の充足を確認する他のテストとは異なり、「想定外の使われ方をされても壊れない・漏洩しない」ことを積極的に確認する点が特徴。
• 信頼性成長曲線＝テスト工程で検出された不具合件数の累積を時間軸でグラフ化したもの。理想的には検出件数の増加が徐々に緩やかになりS字カーブを描いて収束する。期限間際になっても不具合が減少せず高止まり・増加している場合は、テストが不十分（品質が収束していない）ことを示す危険信号であり、リリース延期等の判断材料になる。