テストプロセスとは？プロセスの詳細やその目的、成果物までわかりやすく解説！

一般的に テスト という言葉は、手動または自動でのテスト実行を指す場合が多いです。しかし実際は、テストは テスト対象の分析やテストケースの作成なども含めたさまざまな活動 により構成されています。これらの活動を総称して テストプロセス と呼びます。

‍

この記事では、JSTQB テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03 https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf における定義をベースとして、テストプロセスについて大まかな解説を行います。

‍

テストプロセスとは何か？

一般的に プロセス とは、物事を進める順序や流れを指します。ですので、テストプロセスとは読んで字のごとく「テストをどのように進めるか」という順序のことです。

例えば、JSTQB（※1） FLシラバスによれば、テストプロセスは以下の7つの主要な活動で構成されます。

1. テスト計画: テストの目的を定義し、アプローチを選択します。ここでは、テストの範囲、リソースの割り当て、スケジュールを決定します。
2. テストのモニタリングとコントロール: テスト活動の進捗を監視し、必要に応じて調整します。具体的には、テストの進行状況を追跡し、問題が発生した場合には計画を修正します。
3. テスト分析: テスト条件を定義し、リスクを評価します。要件や仕様書をもとにテスト対象を詳細に分析し、どの部分をどのようにテストするかを決定します。
4. テスト設計: テストケースを作成し、テストデータを準備します。具体的には、テスト条件に基づいて具体的なテストケースを設計し、必要なテストデータを作成します。
5. テスト実装: テストウェアを作成し、テスト環境を設定します。これは、実際にテストを実行するための準備段階で、テストスクリプトの作成やテスト環境の構築が含まれます。
6. テスト実行: テストを実行し、結果を記録します。設計されたテストケースに基づいてテストを実行し、発見された欠陥や問題を報告します。
7. テスト完了: テストの結果を評価し、レポートを作成します。全てのテスト活動が完了した後、テスト結果を総括し、最終的なレポートを作成します。

これらの活動を一連の流れとして表したものをテストプロセスと呼びます。これらはあくまで一例で、組織形態や開発プロセスに応じて異なる形となりますが、JSTQBなどが標準化したプロセスは良い指針になります。

‍

_{※1: JSTQB (Japan Software Testing Qualifications Board) は、ソフトウェアテスト技術者資格認定の運営組織。各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織として認定されており、相互認証しているため、JSTQBの試験で得た資格は世界各国で通用します。}

‍

テストプロセスに携わる人

テストプロセスにはさまざまな役割の人が関わり、協調しながらテストを成功に導きます。以下は、代表的な役割と目的、関わるプロセスです。

‍

1. テストマネージャー
   • 目的: テスト計画の策定、進捗のモニタリングとコントロール、リスク管理を担当し、テストプロジェクト全体の成功を保証する。
   • 関わるプロセス: テスト計画、テストのモニタリングとコントロール、テスト完了
2. テストアナリスト
   • 目的: テスト条件の分析、テストケースの設計、テストデータの準備を行い、効果的なテスト実施を支援する。
   • 関わるプロセス: テスト分析、テスト設計
3. テストエンジニア
   • 目的: テストスクリプトの作成、テスト環境の設定、テストの実行を担当し、実際のテスト活動を遂行する。
   • 関わるプロセス: テスト実装、テスト実行
4. 品質保証担当者
   • 目的: テスト結果の評価、最終レポートの作成、品質基準の維持を担当し、全体の品質保証を支える。
   • 関わるプロセス: テスト完了

テストプロセスはなぜ必要なのか？

テストプロセスの利点

上述した通り、テストの中にはさまざまな活動が存在します。これらをまとめて「テスト」とだけ称すると、誰がどのような役割であるのか明確にならず、的確な改善が困難になるでしょう。そのような背景もあり、テストの流れをテストプロセスとして可視化することで、以下のような利点があります。

• 役割分担と関係の明確化: テストプロセスを明文化することで、チーム内での役割分担や、開発プロセス（SDLC: Software Development Life Cycle）との関係が明確になります。これにより、誰がどの部分を担当するかがはっきりし、コミュニケーションが円滑になります。
• ボトルネックの特定と改善: テストプロセスを可視化することで、プロセス内のボトルネックを特定しやすくなります。具体的なステップごとに進捗を追跡できるため、どの段階で遅延や問題が発生しているのかを迅速に発見し、改善できるようになります。

テストプロセスと開発プロセスの関連

テストプロセスは開発プロセスと密接に関連しており、これらを分けて考えることはできません。ソフトウェア開発において、テストプロセスは開発プロセスに内包される形で実施されます。これにより、開発とテストが並行して進行し、早期に欠陥を発見して修正することが可能です。

V字モデルの例

‍

_{出典: https://shiftasia.com/ja/column/}

‍

V字モデル（V-Model）は、テストプロセスと開発プロセスの関係を視覚的に示した代表的なモデルです。V字モデルでは、開発の各段階に対応するテスト活動があり、以下のように構成されています。

1. 要求分析
   • 対応するテスト活動: 受け入れテスト計画
   • 説明: システムに対するユーザーの要求を明確にし、その要求を満たすためのテスト計画を立てます。
2. 基本設計
   • 対応するテスト活動: システムテスト計画
   • 説明: システム全体の設計を行い、その設計に基づいてシステム全体のテスト計画を策定します。
3. 機能設計
   • 対応するテスト活動: 結合テスト計画
   • 説明: システムの構造やコンポーネントの設計を行い、それに基づいて統合テスト計画を策定します。
4. 詳細設計
   • 対応するテスト活動: 単体テスト計画
   • 説明: 各モジュールの詳細設計を行い、その設計に基づいて単体テスト計画を策定します。
5. コーディング
   • 対応するテスト活動: 各モジュールのコーディングが完了したら、単体テストを実行します。

V字モデルでは、開発プロセスの各段階に対応する形でテストプロセスが実施されるため、以下のような利点があります。

• 早期欠陥発見: 開発の初期段階でテスト計画を立てることで、早期に欠陥を発見し、修正することが可能です。これにより、後工程での大きな手戻りを防ぐことができます。
• リスク管理: テスト計画の策定段階でリスクを評価し、優先順位をつけてテストを実施することで、リスクの高い部分に対するテストを重点的に行うことができます。
• プロセスの透明性: 開発とテストが並行して進むことで、プロジェクト全体の進捗状況が可視化され、関係者間のコミュニケーションが円滑になります。

各プロセスの概要

本章では、JSTQBにおける各プロセスの概要について、それぞれの目的、内容、成果物を軸に説明していきます。

‍

‍

_{出典：https://www.jasst.jp/symposium/jasst21hokuriku/pdf/A1.pdf}

テストのモニタリングとコントロール

テストモニタリングとテストコントロールの目的

テストモニタリングとテストコントロールの目的は、テスト活動が計画通りに進行しているかを確認し、必要に応じて調整を行うことです。これにより、プロジェクトの進捗を適切に管理し、問題が発生した場合には迅速に対応することができます。

また、上記の図が表しているように、テストのモニタリングとコントロールは、テストプロセス全体を通して実施されるものです。

テストモニタリングで実施する内容

テストモニタリングでは、以下の内容を実施します。

• 進捗確認: テストケースの進捗状況を追跡し、計画通りに進んでいるかを確認
• リスク管理: テスト中に発生するリスクを識別し、その影響を評価
• 欠陥管理: 発見された欠陥の数や修正状況を監視
• リソース管理: テストに必要なリソース（人員、ツール、環境など）の使用状況を確認し、必要に応じて調整

テストコントロールで実施する内容

テストコントロールでは、以下の内容を実施します。

• 計画の修正: テストモニタリングの結果に基づき、テスト計画を修正します。これには、スケジュールの調整や追加リソースの投入が含まれます。
• 対策の実施: 発見されたリスクや問題に対して適切な対策を講じます。これにより、テストの進行をスムーズに保ちます。
• コミュニケーション: 関係者間での情報共有を行い、テストの進捗状況や問題点について報告します。

主なメトリクス

テストモニタリングとテストコントロールで使用する主なメトリクスには、以下のものがあります。

• 欠陥数: 発見された欠陥の総数、修正済みの欠陥数、未修正の欠陥数など
• テストケースの進捗: 実行済みのテストケース数、成功したテストケース数、失敗したテストケース数
• カバレッジ: コードカバレッジ、要件カバレッジ、リスクカバレッジなど
• リソース使用状況: テストに投入されたリソース（人員、ツール、環境など）の使用状況

主な成果物

テストモニタリングとテストコントロールの主な成果物には、以下のものがあります。

• テストレポート: テストの進捗状況や結果をまとめた報告書
• 進捗レポート: テストケースの実行状況やリソース使用状況を報告する文書
• リスク管理レポート: 発見されたリスクとその対応策をまとめた報告書
• 欠陥レポート: 発見された欠陥の詳細情報や修正状況を記載した報告書

テスト計画

テスト計画の目的

テスト計画の目的は、テストの全体的なアプローチとスケジュールを定義することです。これにより、テストの範囲、リソースの計画、スケジュールを明確にし、効率的なテスト実施を支援します。

テスト計画で実施する作業

テスト計画では、以下の作業を実施します。

• テスト範囲の設定: テストの対象範囲を明確にし、どの部分をテストするかを決定
• リソースの計画: テストに必要なリソース（人員、ツール、環境など）を計画し、確保
• スケジュールの設定: テストの実施期間を設定し、各テストフェーズの開始日と終了日を決定
• リスク管理: テストに関連するリスクを特定し、その管理方法を計画

主な成果物

テスト計画の主な成果物には、以下のものがあります。

• テスト計画書: テストの全体的なアプローチ、範囲、スケジュール、リソース計画を記載した文書
• リソース計画書: テストに必要なリソースを記載した計画書
• リスク管理計画書: テストに関連するリスクとその管理方法を記載した文書

テスト分析

テスト分析の目的

テスト分析の目的は、テストベース（※2）を分析してどの機能をテストするかを決定したり、関連するテスト条件（※3）を定義したり、それらの優先順位を付けることです。また、関連するリスクとリスクレベルを分析します。これにより、テスト対象のフィーチャーがしっかりとカバーされ、テストの範囲と深さが適切に設定されるようになります​​。

※2: テストベースとは、テストのために使用される情報源やドキュメントの集合であり、要件仕様書、設計仕様書、ユーザーストーリーなどが含まれます。これらはテスト条件やテストケースを設計するための基盤となります。

※3: テスト条件は、ソフトウェアの特定の側面や機能が正しく動作するかどうかを確認するための基準を指します。例えば、「ログイン試行が連続して失敗した場合、アカウントがロックされることを確認する。」などがテスト条件です。テスト条件は、テスト対象が満たすべき要件や仕様の一部であり、これに基づいてテストケースが設計されます。例えば、入力の有効性、出力の正確性、システムの振る舞いなどが含まれます​​。

主な作業

テスト分析における主な作業は以下の通りです。

1. テストベースの評価：
   • 要件、設計、ユーザーストーリーなどのテストベースを評価し、テストすべき機能を検討します。
2. テスト条件の定義：
   • それぞれの機能について、テスト条件を定義し、それらの条件に優先順位を付けます。
3. リスク分析：
   • テスト対象に関連するリスクとそのリスクレベルを分析します。これにより、重要なリスクが適切にカバーされるようにします。
4. 欠陥の識別：
   • テストベースとテスト対象を評価し、それらに含まれている可能性のある欠陥を指摘します。

成果物

テスト分析の成果物には、以下のものが含まれます。

1. テスト条件リスト：
   • テストするべき条件とその優先順位をまとめたリスト。
2. リスクレポート：
   • テスト対象に関連するリスクの評価結果をまとめたレポート。
3. 欠陥リスト：
   • テストベースの分析によって発見された潜在的な欠陥のリスト​​。

テスト設計

テスト設計は、テスト分析の後に行われるプロセスであり、定義されたテスト条件を具体的なテストケースやその他のテストウェアに落とし込む作業を指します。これにより、どのようにテストを実施するかが決定されます。

‍

テスト設計の目的

テスト設計の目的は、テストケースを設計し、テストデータを準備することです。これにより、具体的なテスト手順が明確になり、テストの実施が円滑に行われます。

テスト設計で実施する作業

テスト設計では、以下の作業を実施します。

• テストケースの設計：
  • テスト条件に基づいてテストケースを作成し、それらがシステムやソフトウェアの特定の部分をテストする方法を明確にします。
  • カバレッジアイテム（テストケースがカバーする要件や仕様）を識別します。
• テストデータ要件の定義：
  • テストケースを実行するために必要なデータを特定し、そのデータを準備します。
• テスト環境の設計：
  • テストを実行するために必要な環境（例えば、ハードウェア、ソフトウェア、ネットワーク設定など）を設計します。
  • スタブ、ドライバー、シミュレーター、サービス仮想化などのツールやインフラストラクチャも含まれます。
• テスト技法の適用：
  • ブラックボックステスト技法、ホワイトボックステスト技法、経験ベースのテスト技法など、適切なテスト技法を適用してテストケースを設計します。

主な成果物

テスト設計の主な成果物には、以下のものがあります。

• テストケースリスト: 設計されたテストケースを記載したリスト
• テストデータセット: テスト実行に使用するデータをまとめたセット
• テストシナリオ: テストケースを順序立てて実行するためのシナリオ

これらの成果物は、次のテスト実装で具体的なテスト手順書を作る際に利用します。

テスト実装

テスト実装の目的

テスト実装の目的は、テストウェアを作成し、テスト環境を設定することです。これにより、テストの実施準備が整います。

テスト実装で実施する作業

テスト実装では、以下の作業を実施します。

• テストスクリプトの作成: テストケースに基づいてテストスクリプトを作成
• テスト環境の設定: テスト実行に必要な環境を構築
• ツールの準備: テストに必要なツールを準備

自動テストとの関係

この段階で、テストケースを自動テストとして実装する場合もあります。自動テストは、繰り返し実行可能なテストスクリプトを作成することで、効率化を図ります。

主な成果物

テスト実装の主な成果物には次のようなものがあり、主にテスト実行の際に使われます。必要なドキュメントは、テスト対象や実施するテストの種類などによって異なります。

• テスト手順書: テスト実行の手順を詳細に記したドキュメント
• 自動テストスクリプト: 自動テストを実行するテストコード
• 設定ファイル: テスト環境の設定を記載したファイル
• テスト環境セットアップドキュメント: テスト環境の構築手順を記載した文書

テスト実行

テスト実行の目的

テスト実行は、テストプロセス全体を通して設計・作成したテストを実際に実行することを指します。これにより、ソフトウェアの現在の品質が評価され、欠陥や問題を発見・修正し、品質向上につなげることができます。

テスト実行で実施する作業

テスト実行では、以下の作業を実施します。

• テストケースの実行: 設計されたテストケースを順次実行し、結果を記録
• 欠陥の報告: テスト実行中に発見された欠陥や問題を報告し、修正依頼を行う

自動テストとの関係

自動テストとして実装されている場合は、テスト実行は自動テストの実行に代替されます。自動テストは、スクリプトを使用して迅速かつ効率的にテストを実行し、多くの場合、手動テストよりも早く結果を得られます。

主な成果物

テスト実行の主な成果物には、以下のものがあります。

• テスト実行レポート: 各テストケースの実行結果をまとめた報告書
• 欠陥レポート: 発見された欠陥の詳細情報や修正状況を記載した報告書

これらは次の テスト完了 ステップで使われます。

テスト完了

テスト完了で実施する作業

テスト完了時には、以下の作業を実施します。

• テスト結果の評価: テストの全体的な結果を評価し、ソフトウェアが要求を満たしているかを確認
• 最終レポートの作成: テストの結果を総括し、発見された欠陥や改善点などを含む最終的なレポートを作成
• テストウェアの保管: 使用したテストケース、スクリプト、データなどのテストウェアを適切に保管し、将来のプロジェクトやメンテナンスに備える

主な成果物

テスト完了の主な成果物には、以下のものがあります。

• テスト完了レポート: テストの最終結果をまとめた報告書
• 最終評価書: テスト結果に基づいてソフトウェアの品質を評価した文書

まとめ

テストプロセスは、ソフトウェア開発における品質保証の重要な要素であり、各ステップごとに明確な目的と作業内容があります。これを適切に実行することで、ソフトウェアの品質向上とプロジェクトの成功に寄与します。

テストプロセスを標準化し、体系的に実施することで、テスト活動の効率化と透明性の向上が図れるでしょう。また、開発プロセスとの連携を強化することで、欠陥の早期発見と修正が可能となり、全体的なプロジェクト進行のリスクを低減できます。

‍