6.3テストと品質保証

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

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

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

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

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

あるシステムアーキテクトが、新しい会員向けECサイトのリリース直前、品質状況を評価するとします。まず信頼性成長曲線を確認すると、リリース予定日の2週間前になっても不具合の新規検出件数が減少せず高止まりしていることに気づきます——理想的なS字カーブであれば、この時期には検出件数が大きく減っているはずです。この兆候から、現状のテストが不十分で品質が収束していないと判断し、原因を分析します。テストの実施状況を精査すると、開発者による単体テストと、モジュールを組み合わせた結合テストは完了していたものの、実運用に近い環境で業務要件全体を検証するシステムテストの実施が遅れており、システムテストで初めて見つかる種類の不具合（複数機能をまたぐ業務フローの不整合等）が終盤に集中して発覚していたことが分かりました。さらに、セール時のアクセス集中を想定した負荷テストが未実施であることも判明し、想定を超えるアクセスでシステムがどう振る舞うか（緩やかに劣化するか、突然ダウンするか）が未知数のままでした。アーキテクトは、このままリリースすればセール時に致命的な障害が起きるリスクが高いと判断し、リリースを2週間延期してシステムテストの残項目と負荷テストを完了させ、信頼性成長曲線が収束傾向を示すことを確認してから、最後に発注者（マーケティング部門）による受入テストで実業務での使い勝手を確認し、Go判断を行う計画に修正します。このように、テストレベルごとに保証すべき対象を切り分け、信頼性成長曲線という定量データで品質の収束状況を判断するのが実務です。

6.3.3この節のまとめ

• 単体→結合→システム→受入の順にテストレベルが上がり、検証主体・対象が変わる
• 性能テスト＝通常負荷で要件を満たすか、負荷テスト＝限界での挙動確認、セキュリティテスト＝想定外の使われ方への耐性
• 信頼性成長曲線が期限間際も収束しない（高止まり・増加）のは品質未成熟の危険信号