ソフトウェアテストの流れ

テストの主要なアクティビティ

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

• 計画とコントロール
• 分析と設計
• 実装と実行
• 終了基準の評価とレポート
• 終了作業

これらのアクティビティを直線的に進めることもあれば、並行して進めることもあります。

※ボリュームが大きいので別々の記事にまとめました。

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

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

• 計画とコントロール
• 分析と設計
• 実装と実行
• 終了基準の評価とレポート
• 終了作業

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

テスト計画

スコープとリスクを特定し、テストの目的を定義する。

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

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

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

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

テストに対する包括的なアプローチを定義する。

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

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

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

テストの活動を定義する。

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

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

 定義した活動にリソースを割り当てる。

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

• 物理的なリソース
  テスト環境、テスト対象のバージョン、使用するテストツールなど。
• 人的リソース
  人数、テクニカルスキル、ドメインスクルなど。

テストの分析と計画の活動をスケジューリングする。

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

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

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

テストの実装と実行、テスト結果の評価に係る活動をスケジューリングする。

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

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

 テストのコントロール

テスト結果の計測と分析

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

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

テストのモニタリングと文書化

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

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

欠陥修正の管理

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

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

意思決定

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

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

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

ソフトウェアテスト教科書 JSTQB Foundation 第3版

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

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

• 計画とコントロール
• 分析と設計
• 実装と実行
• 終了基準の評価とレポート
• 終了作業

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

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

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

テストベースをレビューする。

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

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

テストベースやテスト対象のテスト容易性を評価する。

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

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

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

テスト分析に基づいて、テスト条件を識別し優先順位を付ける。

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

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

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

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

高度なテストケースを設計し、優先順位を付ける。

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

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

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

• ユーザー指向：テスト対象を利用する視点で見る。
• フォールト指向：欠陥を見つける視点で見る。
• 要件指向：要件の妥当性の視点で見る。
• 設計指向：設計通りにテスト対象が動作するかを見る。

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

必要なテストデータを識別する。

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

テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する。

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

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

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

テストベースとテストケースの間でトレーサビリティを確保する。

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

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

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

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテストの流れ：実装と実行

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

• 計画とコントロール
• 分析と設計
• 実装と実行
• 終了基準の評価とレポート
• 終了作業

本記事では「実装と実行」についてまとめます。

実際にテストを実施するための手順や確認項目の詳細となるテストケースやテスト手順書、テストスクリプトといったテストウェアを作成します。また、テスト環境の構築もこのタスクで行います。

テスト実施者のスキルセットはテストウェアを記述する粒度に直接影響するためテスト実施社のスキルセットを事前に定義する必要があります。

テスト実施者のスキルレベルにあったテストを実装しないと、テストの妥当性が低下したり目的から外れた意味のないテストになりかねません。

テストケースを決定し、実装し、優先順位を付ける。

テストケース実行の優先順位はテスト計画やテスト設計で決めた優先順位に基本的に準拠しますが、効率の良いい実行手順を採用することもあり、当初の優先順位とは異なる優先順位を付けることもあります。

テスト手順を開発し、優先順位を付け、テストデータを作成する。

必要があればテストハーネスやテストの自動実行スクリプトを準備します。

テストハーネスとは、テスト実行に必要なスタブやドライバからなるテスト環境のことです。

効率よくテストを行うため、テスト手順をベースにしてテストスイートを作る。

テストスイートはテスト手順やテストハーネスの準備、後片付けなどテスト実施効率を考えた上で、テストケースを組み合わせてまとめていきます。

テストスイートはテスト実施に責任をもつ技術者自身が作らなければなりません。

テスト環境を正しくセットアップしたことを確認する。

テスト対象、テストツール、テストハーネス、計測機器などテストに必要となる設備の準備作業のすべてがこのタスクに含まれます。

テストベースとテストケースの間で双方向のトレーサビリティを確認し更新する。

仕様変更やインシデントへの対応にともなってテストベースが変更された時点で、関連するテストケースも変更していきます。

計画した順番に従い、テスト手順を人力、もしくはテストツールで実行する。

テストスイートまたはテストケースレベルで規定されたテスト実施の最小粒度ごとに行う事前準備、実行、後片付けのすべてが含まれます。

テストの実行結果の記録を取り、テスト対象のソフトウェア、テストツール、テストウェアのIDとバージョンを記録する。

計測機器での計測結果、テストを実施したソフトウェア、ソフトウェアが搭載された環境(OS、ミドルウェア、ハードウェア)、テストツールの構成やバージョン、テストウェアのIDなどをエビデンスとして記録に残します。

実行結果と期待する結果を比較する。

テストケースやテスト手順の確認項目や判定項目、テスト全体の合否を規定した標準文書の定義とテスト結果を比較します。

両者が一致しない場合、インシデントとして報告し、原因を解明するためにインシデントを分析する。

インシデントの直接的な事象だけではなく、ほかの原因で同一の問題が起きるかどうかや、当該テストケース以外にも影響が出てないかどうかといったことを調査、分析します。

実行結果と期待する結果が一致しないケースごとに、テスト活動を繰り返す。

回帰テストの実施が該当します。

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

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテストの流れ：終了基準の評価とレポート

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

• 計画とコントロール
• 分析と設計
• 実装と実行
• 終了基準の評価とレポート
• 終了作業

本記事では「終了基準の評価とレポート」についてまとめます。

テスト結果の記録をテスト計画作業で定義した終了条件と比較する。

テスト実施による合否判定や測定結果から直接導かれる基準以外に、バグ管理図を使ってテストケースの消化率と欠陥の検出が想定通りだったかどうか、欠陥が収束しているかどうか、検出した欠陥はテストの目的で狙った通りのものなのかといったものもあります。

追加テストが必要か、あるいは定義した終了基準を変更するべきかを判断する。

テスト結果が全く終了基準を満たしていなかったり、欠陥の分析結果が当該テストレベルより前のテストレベルで検出されるべき欠陥が多くを占めているのなら、テストレベルの差し戻しや再実行といったことを検討することも起こり得ます。

ステークホルダーにテストサマリレポートを書く。

ステークホルダーは、テストレベルやテスト対象によって異なります。

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

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテストの流れ：終了作業

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

• 計画とコントロール
• 分析と設計
• 実装と実行
• 終了基準の評価とレポート
• 終了作業

本記事では「終了作業」についてまとめます。

計画にあるテストの成果物がリリースされたかをチェックする。

テスト計画の段階で、テストウェアとして作成することを定めたドキュメントがリリースされているかどうかのチェックを行います。

システムを受け入れるために文書を作成する。

システムテストレベルでの終了作業であった場合は受け入れテストへ進むときに、受け入れテストの前準備として必要な文書等を作成します。

次回も使えるように、テストウェア、テスト環境、テストのインフラストラクチャをまとめ、文書化する。

再利用のためにすべきタスクにはそれなりの工数が必要となることを認識しておくことが大切です。

テストウェアを保守部門に引き渡す。

保守部門ではテスト結果からプロダクトの品質状況を把握したり、リリース後にインシデントが起きた時のトラブルシューティングなどにおいてテストウェアを利用します。

次回のリリースやプロジェクトのために教訓とすべきことをまとめる。その情報をテストの成熟度を改善するために利用する。

当該テストレベルのステークホルダー全員が集まる「ポストモーテム」を開催します。

ポストモーテムは、テストコントロールにおける課題や問題、テスト結果やその分析・評価をもとに、プロセスやテストウェアを継続的に完全するためのアクティビティ全体の良かった点、悪かった点を包み隠さず話し合う場となります。

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

ソフトウェアテスト教科書 JSTQB Foundation 第3版