ソフトウェアテストの流れ：分析と設計

テストの主要なアクティビティとして以下のものがあります。

本記事では「分析と設計」についてまとめます。

テストの分析では、テスト計画で定めたテスト戦略に基づいてテストベースを収集した上で、情報の取捨選択、再収集、新たに作成するなどを検討していきます。

分析を経てテスト対象に対して、どのようなテストをどのような手段で実施すべきかというテスト戦略を検討するためのタスクがテスト設計となります。

テスト設計を行う技術者がテストベースをレビューします。

テストベースにはドキュメントとして明文化されたものだけではなく、議事メモ、メール、ホワイトボードのメモなども含まれます。

テストケースの実現性を検討します。

人に依存しないテストとするためには、定性的な評価を定量的な評価に置き換えるテスト設計が必要です。具体的には、段階的な評価を可能とするための基準や、標準といった「ものさし」を用いるか、ないのなら自ら用意できないか検討します。

テストの容易性は、テスト対象が持つ構造的な観点からも考えていきます。具体的には、プログラムの最終的な値だけでなく中間的な値も確認できる構造になっているか検討します。

テストで検証すべき条件や要件を明らかにします。

テストを実施できるスケジュールや、技術者のスキルセットも検討材料に加えるようにします。

テストアイテムごとの仕様の相違、類似点などをアイテム自身の動作や、ソフトウェアの構造などを分析することによりテスト条件を識別していきます。

テスト条件が明らかになったら、テストの目的(戦略)に沿うように、テスト条件の優先順位付けを行います。

テスト設計では、テスト手順や期待結果などの詳細なところから検討するのではなく、テスト条件(テスト要件とも呼ぶ)を網羅するようにテスト技法を用いて設計してきます。"高度なテストケース設計"とはこのように抽象度の高いテストケースのことを指しています。

網羅性を満たすには、要件や仕様に対するカバレッジとコードカバレッジの両方の視点が重要になります。テスト設計は、基本的にはこれら2つのカバレッジを満たすように行います。

主要なテスト設計の視点として次のものがあります。

f:id:jumperson:20130922143621j:plain

このようにテスト設計を行うと同時に、テストアプローチを元にテストケースごとに優先順位を割り当てます。

単体テスト・結合テストレベルではテストツールで自動生成したデータを用い、システムテストレベルでは実測データや本番データを使用する。といったことを検討します。

テスト実施に必要な環境を物理的側面/論理的側面から識別します。

物理的側面としては、ハードウェアやOS、ミドルウェア等のバージョンなどを検討します。

論理的側面としては、テスト実施におけるミドルウェアやファームウェアの可変パラメータに対するデフォルト値や、チューニング可能なテーブル設定の組み合わせといったようなこともこのタスクで検討します。

トレーサビリティが確保できていないこと自体が、致命的な欠陥を内在する要因となります。

トレーサビリティ、トレーサビリティマトリクスを作成したり、要求管理ツールやALM(Application Lifecycle Management)ツールを導入することで確保していきます。

参考にした資料はこちらです。