Vietnamese
English基本的なテストプロセスにおけるテストの活動・Part 1
ソフトウェアテストプロセスはテストの準備からテストを終了するまでの一連の流れを指します。ソフトウェアのテスト時には、さまざまな活動が行われています。テストプロセスは簡単に言えば、段階ごとに分けられ、グループ化されたテスト活動の集まりです。実際の状況によっては、テストプロセスを短縮することもあります。テストプロセスに影響を与える要素には、案件の規模、予算、法的な基準などが含まれます。
常に、基本的なテストプロセスには以下の7つの活動があります。
- テスト計画
- テストのモニタリングとコントロール
- テスト分析
- テスト設計
- テスト実装
- テスト実行
- テスト完了
場合によっては、上記の活動を順番に行うこともあれば、複数の活動を同時に進めることもあります。仕様が明確なケースでは、テスト分析を行いながら、テスト設計やテスト実装を進めていきます。ソフトウェアの開発モデルなどの客観的な要因に基づき、適切にテスト活動を調整することが必要です。
本記事でテストプロセスにおける最初の3つのテスト活動を調べてみましょう。
- テスト計画
- テストのモニタリングとコントロール
- テスト分析
①テスト計画
テスト計画を立てる際に、最初に明確にすべきことはテストの目的です。テストの目的はソフトウェアの納期や存在理由によって異なります。例えば、納期を優先する場合、テストの目的はソフトウェアの基本的な機能の確認に集中することになります。また、単体テストや結合テストといったテストレベルによっても、テストの目的は変わります。例えば、単体テストの段階では、各機能を徹底的にテストすることが目的です。一方、結合テストでは、ソフトウェアの遷移フローを確認することが目的となります。
②テストのモニタリングとコントロール
テストプロセスをコントロールするためには各テスト活動やタスクの状況を把握する必要があります。つまり、テストプロセスをモニタリングしなければならないということです。モニタリングしなければ、テストが正しい傾向に進んでいるのか、また客観的にテストがうまく進行しているのかを理解することはできません。そのため、客観的に状況を理解するためには、検証終了基準が必要です。検証終了基準に基づいて、テスト活動を終了してもよいかどうか判断できます。
次に、モニタリング項目には何があるのでしょうか。検証を実施している時点では、テスト計画や現在の状況を確認し、バグの頻度やテストケースの日々の進捗に基づいてテスト対象の品質を分析します。この分析結果は、検証進捗レポートとしてステークホルダーへ報告します。このような活動を通じて、テスト計画と比較するだけでなく、案件計画で設定された目的とも比較し、必要に応じてテスト計画や案件計画を見直す提案を行います。
③テスト分析
テストを分析する活動で、テストを実行するための情報を収集します。具体的には、ソフトウェアの設計、機能要件、非機能要件、構成などのテストベースを集めることです。その後、集めた情報をフィルタリングし、新規作成することで、どのフィーチャ（コンポーネントやシステムの属性）がテストできるか判断します。分析した対象に対して、どのテスト技術を使うか、どのテスト戦略を適用するかは、テスト設計の活動で決定されます。以下はテスト分析活動で行うタスクです。
テストレベルごとに適切なテストベースを分析する
テスト設計を行う技術者は、テストベースを分析する役割を担います。テストベースには、RFP（提案依頼書）、企画書、ユースケース、購買仕様書、ユーザーや顧客の視点からのユーザーストーリーなどの資料があります。その他にも、要求仕様書、アーキテクチャ定義書、リスク分析レポート、技術設計書、インタフェース仕様書、標準資料（RFCやISO/IEC標準などの公開資料、内部標準や組織の標準資料まで）などが含まれます。
また、テストベースには、会議のメモ、やり取りされたメール、開発時のホワイトボードに聞かれた内容なども含まれます。これは案件のコミュニケーションスタイルによって異なります。
テストベースとテストアイテムを評価して、さまざまな種類の欠陥を識別する
テストベースを分析した後、テストベースにおける特有のエラーを識別する必要があります。明確なエラーの例として、要求仕様書に記載されている内容が機能要件に含まれていない場合、これは問題として報告できます。また、記載が正しくないエラーや、記載が明示されていないエラーとしても報告できます。例えば、資料には「字が読みやすいことを確認する」と記載されていますが、具体的にどのサイズや色の字が読みやすいのかは明記されていません。このため、テスト技術者は自分の主観的な感覚で判断せざるを得なくなります。
そのため、テストを客観的に実行するためには、具体的な定量的な仕様の記載が必要です。例えば、字のフォントはTimes New Romanで、サイズは13ポイントと明記することが重要です。特に、論理的な言語で書かれた仕様や、長い文章で主語や述語が明確に示されていない仕様には注意が必要です。
テストすべきフィーチャーとフィーチャーのセットを識別する
フィーチャーとはシステムの確定された機能やデフォルトのコンポーネント、属性を指します。例えば、信頼度、可用性、設計上の紐付けなどが含まれます。これらの機能をテストする際には、テストレベルごとにテストを実行できるフィーチャーを判断し、独立してテストできるフィーチャセットとしてグループ化していきます。時には、1つのフィーチャーセットのみを扱う小規模な案件もあります。
テストベースの分析に基づいて、各フィーチャーのテスト条件を決めて優先度を割り当てる
テストベースを集めて分析した後、各機能のテスト条件を決定します。テストベースに加えて、テスト環境の準備状況に基づくテスト実行可能なタイミングやスケジュール、技術者に必要なスキル、テストに必要な技術など、ビジネス的な要素も合わせて検討する必要があります。テスト条件は、機能および非機能の仕様の相関関係や依存性、類似点、ソフトウェアのアーキテクチャを分析した上で決定されます。
テスト条件が決まったら、テストアプローチやテスト目的を考慮し、優先順位を決めます。優先順位を決める際には、どのテスト条件がプロダクトリスクに関連しているかも検討することが重要です。
テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する
テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立することで、テストベースから確定されたテスト条件がすべて分析され、展開されることを確認できます。これにより、ソフトウェアの要件や機能がすべてテストされることが保証されます。
テスト分析活動で上記のタスクを実行することによって、テスト設計を行う前に、テストベースに存在するエラーを発見することができます。さまざまな視点からテストベースを集めて分析することで、プロダクトの開発に関する幅広い視点を得ることができます。クライアント、エンドユーザー、プロジェクトマネージャー、プロダクトマネージャー、技術者、開発者のそれぞれがプロダクトに求める要件は多様で、時には異なることもあります。このテスト分析活動は、ステークホルダーの要求がテストベースに正しく反映されているかを確認するのに役立ちます。
※練習問題：