公開:
基本的なテストプロセス

目次
はじめに
システムテストにおける作業工程の全体像について、意外と知られていないケースが多く、開発現場によっては、その中の一部の作業をテスト工程全体として捉えてしまっていることも少なくありません。
そこで、基本的なテストプロセスにおいて、それぞれのフェーズについてご説明したいと思います。
基本的なテストプロセス

なお、本稿では、具体的なイメージをもっていただくために、サンプルケースとして、以下のような問い合わせフォームのテストを例に挙げ、ご説明します。
問い合わせフォームのテストを行う際のプロセスについて

計画とコントロール
「計画とコントロール」のフェーズでは、テスト対象のソフトウェアの欠陥によって発生しうるビジネス上のリスクを分析した上で、テストの目的を決定し、テスト全体のグランドデザインを実施します。
計画とコントロールフェーズで策定する主な内容
- テスト目的の定義
- テストアプローチの決定
- テストボリュームの決定(テスト工数の見積もり)
- テストスケジュールの策定
- テストに必要なリソースの確保(費用、人員、機材、ツールなど)
上記の内容を踏まえ、問い合わせフォームのテストを行うに当たり、テスト目的、アプローチ、実施内容および実施環境をまとめると以下のようになります。
モデルケース:入力フォームのテストの場合


なかでも特に重要となるのが、テストプロジェクト全体の方向性を左右する「テストアプローチ」の決定です。テストアプローチとは、効果的なテストを実施するための戦略を策定することであり、具体的には下記のようなものが挙げられます。
分析と設計
「分析と設計」フェーズでは、テスト計画フェーズで策定されたテスト目的に即して、テスト対象のプロダクトのアーキテクチャやリスクを分析し、具体的なテスト条件やテスト設計への落とし込みを行います。
分析と設計フェーズで策定する主な内容
- テスト対象物のアーキテクチャ
- テスト対象のリスク分析
- 高度なテストケースの設計
- テストデータの設計
- テストウェアの選定や設計
- テスト環境の設計
問い合わせフォームのテストにおいて、上記の項目のテスト構造をモデル図に落とし込むと以下のようになります。
モデルケース:入力フォームテストの場合

実装と実行
「実装と実行」フェーズでは 、分析と設計フェーズにおいて洗い出したテスト観点をベースに、個々のテストケースをスクリプトや手順書に落とし込み、テスト環境のセットアップを行い、手動もしくはテストツールを用いてテストを実行します。
実装と実行フェーズの主なポイント
- テスト環境をセットアップする
- テストケースを実装し、優先順位を付ける
- テストデータを作成する
- 計画した順番に従い、テスト手順を手動ないしはテストツールで実行する
- テスト結果を記録する
- 実行結果と期待する結果を比較し検証する
問い合わせフォームのテストにおいて、テストケースをテスト仕様書に落とし込むと以下のような形となります。
モデルケース:入力フォームテストの場合

終了基準の評価とレポート
「終了基準の評価とレポート」フェーズでは、これまで実施してきたテスト実績が、テスト計画の際に定義した目的に対して妥当であるかを評価検証します。
終了基準の評価とレポートのフェーズでの主なポイント
- テスト記録をテスト計画作業で定義した終了基準と比較する
- 追加テストの必要性や終了基準の変更を定義する
- ステークホルダにテストサマリーレポートを書く
問い合わせフォームのテストレポートをまとめると、以下のようになります。
モデルケース:入力フォームのテストの場合

終了作業
「終了作業」フェーズでは 、テストプロジェクトの最終局面において、終了したテストの全活動データを収集し、プロジェクトから得たことや、利用したテストツールやインフラ、実績と数字を取りまとめます。
終了作業フェーズでの確認事項
- 計画にある成果物がリリースされたかをチェックする
- インシデントレポートを終了させるか、もしくは未対策の欠陥を明記する
- システムを受け入れるために文書を作成する
- 反復したテストに備え、テストウェア、テスト環境、テスト インフラストラクチャをまとめ、文書に残す
終了作業の際には、テストサマリーをもとに、欠陥が多く発生していたコンポーネントやクラス、不具合修正におけるスピードや連携体制など、開発工程における課題の振り返りを行い、次期開発の品質を上げる試みが行われることもあります。
以上が基本的なテストプロセスになります。ただ、“システムテスト”と一言でいっても、ソフトウェアとWebサービスではテスト観点やアプローチ方法が全く異なります。例えば、製造や物流、販売管理といった業務系ソフトウェアの場合、テストを計画して実施するためには、業務知識が必要となります。このように、システムテストとは、実は奥が深く、専門性の高い領域なのです。読者の皆さまがシステムテストに携わる機会がある場合は、是非このフローを意識してみてください。