ソフトウェアテストの流れ：計画とコントロール

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

本記事では「計画とコントロール」についてまとめます。

通常、テスト対象やスコープによってテストの目的が決まります。

スコープは契約に基づいて決まる場合や、システムの規模によって決まる場合があります。

テストの目的として、例えば、欠陥の検出を主眼に置くのか、外部システムとのインターフェースレベルでの疎通確認を網羅的に行うのかなどを決定します。

また、テストの目的を達成するときに障害となりえる要因を挙げていきます。

どのようにテストすべきかといったポリシーや戦略を決定し、テストの目的を具体的にします。

テストの戦略が決まったら、戦略に沿ったテストとなるよう以降のアクティビティを定義していきます。

ステークホルダー間で合意を得ることができるテストの終了基準を定めます。終了基準は総合的に判断できるように複数の基準を決めていきます。

実際にどのようにテストの活動をいつ進めていくかや、どう進めていくかという手段(職務)を決定してきます。

テスト結果を適切に評価するために、テストのレベルごとに適用するテスト技法を決めたり、どのようなテストアイテムが必要かを決めていきます。

物理的なリソース、人的リソースを定義していきます。

テスト分析は、分析材料を揃えることから始めます。

ブラックボックステストであれば、RFPや要求仕様書といったドキュメントを準備します。

ホワイトボックステストであれば、アーキテクチャ定義書、基本設計書、詳細設計書、モデル定義書、DB設計書などアルゴリズムや内部構造が理解できる材料を準備します。

計画段階のスケジュールは概算スケジュールになります。大枠の工数やリソースを割り当てるために用いられます。

テストリーダーやプロジェクトマネージャなどの管理層が、過去の経験やテストに関わる工数の実績値などを元に見積もりを行うことが多いでしょう。

テスト実施の評価は、合否判定が伴う項目だけではありません。

パフォーマンス測定やリソース利用率の計測などは、基準値の近似値であれば問題ないこともあれば、単に測定するだけということもあるでしょう。

進捗やテストの様々なメトリクス（テストケースあたりの故障の発生率や機能単位の欠陥混入率）を用いて、テストそのものが妥当かどうかを随時モニタリングします。

また、モニタリングした内容を文書化し、ステークホルダー全員で把握できるようにします。

欠陥を修正したコンポーネントの反映は、プロジェクト計画やテスト計画で定められた構成管理のタイミングで実施していきます。

また、テストするタイミングも、テスト計画で定められたタイミングになります。

テスト進捗のモニタリングを行い、テストの中断、再開、終了といったテスト実施そのものに関わる意思決定を適切に行っていきます。

もし、テストの進捗全体を止めるようなインシデントや、そもそも発生してはならないようなインシデントが発生した場合は、一旦テストを中断し、テスト実施の前段階に差し戻して開発作業をやり直すかどうかを検討します。

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