テスト工程の中にはさまざまな作業工程があります。
その中でテストの屋台骨ともいえる、テストアーキテクチャをご存知でしょうか。
テストアーキテクチャとは
テストの実現方法、概念、特徴、要素、関係性、設計方針を表現したものです。
実務イメージでは、テスト計画書とテスト設計書の間にあるものとイメージしていただければと思います。
例えば、以下のようなイメージです。
全体方針
| テストレベル | 目的 | タイミング |
|---|---|---|
| 単体テスト | ユニットの動作が正しいことを確認する | ブランチごと |
| 結合テスト | ユニット間結合の動作が正しいことを確認する | メインブランチごと |
| システムテスト | システムの動作が正しいことを確認する | リリースごと |
システムテスト方針
| テストタイプ | 詳細テストタイプ | 目的 |
|---|---|---|
| 機能テスト | 仕様書照合テスト | 要件定義書に記載の通りの動作を行うことを確認する |
| 画面遷移テスト | 画面遷移書に記載の通りの動作を行うことを確認する | |
| … | … | … |
| 非機能テスト | 障害テスト | 一部システムの障害発生時にフェール動作を行うことを確認する |
| … | … | … |
テスト構造
| サイクル | 前工程 | テストレベル |
|---|---|---|
| CI | 実装 | 単体テスト |
| 1か月ごと | インテグレーション | 画面遷移書に記載の通りの動作を行うことを確認する |
| リリースごと | 結合テスト | 一部システムの障害発生時にフェール動作を行うことを確認する |
etc...
上記以外にもテストタイプごとのリスク、テストシステム（ツール）と対象テストの一覧などを整理していきます。
さらにはテストタイプごとにテスト構造（条件、因子の考え方）も記載していきます。
何のためにテストアーキテクチャが必要か
以下の理由から、テストアーキテクチャが必要と考えています。
- ただでさえテストの重要性や必要性がわかりづらい中で、テスト計画書とテスト設計書だけでは複雑大規模なシステムのテストの満足度をチェックし、理解することは難しい
- プロジェクトに存在するステークホルダーが、テストしてほしいことが実践されているかを把握し、レビューできることが重要
- リリースするシステムの制約事項やリスクを正しく把握できるようにすることで、品質ゴールをプロジェクト関係者で合意し、良いプロダクトを目指すことが可能になる
テストアーキテクチャをテストプロセスに追加しましょう
テストアーキテクチャは文字通り、「テスト構造」を表現することです。
昨今のシステム開発はクラウド化やSaaSとの連携、IoT機器連携など複雑で大規模なシステム構造をしていることが多いです。
対象システムが何か、テスト範囲はどこまでなのか、どこまでの品質が担保できているのか、不透明な状況に陥ることが多くあります。
テストアーキテクチャの作成をテスト工程のプロセスに組み込むことで、大量のテストはしているが品質を確保できているといえるのかわからない、という状況を打破できるのではないかと思います。
ぜひ皆さまのプロジェクトのテスト計画においても取り込んでいただき、納得のテストと品質保証を実現していただければ幸いです。
