Vietnamese
Englishテストのモニタリングとコントロール
テストの進捗は把握しにくいものです。例えば、夏休みの宿題において「進めている？」「進めているよ」といった会話だけでは、実際にどれくらい進んでいるのか、期限までに終えられるのか、ペースを上げる必要があるのかを正確に知ることはできません。宿題の進行状況と計画との差異を確認しなければ、誰も（本人ですら）実態を把握できません。親が途中で「見せて」と確認し、進捗が遅れていれば頑張らせたり手伝ったりするような対応を取ることがあります。
ソフトウェアテストも同じです。テストプロセスの状況を把握するためにさまざまな指標を設け、それをモニタリングします。そして、得られたモニタリング結果を基にテスト活動をコントロールします。進捗が遅れている場合には、スケジュールの見直しやリソースの追加投入など、必要な対策を講じます。モニタリングとコントロールは、テストを円滑に進めるために欠かせない両輪です。
モニタリングには、データの収集や解析が伴い、それ自体に手間がかかるため、必要な情報のみを効率的に収集することが求められます。また、情報を簡単に収集できる仕組み（自動化など）を導入することで、より円滑にモニタリングを実施できます。
以下では、テストのモニタリングとコントロールについて詳しく解説していきます。
識別したリスクが現実化した場合（例えば、リリースの遅延が発生した場合）、テストの優先順位を再評価する
テストの開始時点やプロセスの途中でも、発生すべきではない事象を事前にプロジェクトリスクとしてリストアップしておきます。開発期間中は、それらのリスクが現実化していないかを監視し、現実化した際には、問題解決に向けた対応を行う必要があります。
例えば、複数のアプリケーションを含むシステムの開発において、特定のアプリケーションの開発が遅れ、そのアプリケーションに依存する別のアプリケーションのテストが実施できない可能性をリスクとして挙げていたとします。この遅れがリリース全体の遅延に直結する場合、適切な対策を講じることが求められます。リスクが現実化した際には、テスト可能な他のアプリケーションを優先してテストするなど、テスト計画の優先順位を見直すことで対応します。
テスト環境やリソースの利用状況に応じてテストスケジュールを調整する
テスト環境や必要なリソースが利用できなくなった場合、スケジュールを見直します。
例えば、特定の印刷機能をテストするために必要な専用プリンターが予定通りに準備できない場合、そのテストを後回しにし、専用プリンターを必要としない機能のテストを優先して実行します。このような場合には、代替として実行可能なテストケースや、それに必要な機材が揃っているかを事前に把握しておくことが重要です。
再作業が必要な場合、テストアイテムが開始基準と終了基準を満たしているかを再確認する
故障が発生した場合、原因となる欠陥を修正した後で中断していたテストを再開します。この際、テストアイテムが開始条件と終了条件を満たしていることを再評価する必要があります。
例えば、ある機能に重大な故障が見つかり、デバッグの結果、多くの欠陥の修正が必要となり、修正の影響がすでに合格したテストケースにまで及ぶことが判明した場合を考えます。このような場合、再作業を開始する基準として、すべての欠陥が修正されていること、テスト環境が整備されていること、そして実行すべきテストケースが明確になっていることが挙げられます。また、終了基準としては、再開前に合格していたテストケースを含め、すべてのケースについて再評価することが求められます。
テストで使用するメトリクス
では、実際にテスト活動をモニタリングするためのメトリクスについて確認していきます。テスト期間中および終了時に、以下の項目を評価し、次に説明するテストレポートに反映させます。
計画したスケジュールや予算に対する進捗
計画されたスケジュールに対して、進捗が予定通りか、それとも前倒しや遅延が発生しているかを確認します。予算についても同様に確認を行います。例えば、特定の作業が予定より遅れていても、他の作業が前倒しで進んでいれば全体に問題はないかもしれませんが、全体の進捗に影響が出る場合には、テストコントロールにフィードバックが必要です。また、スケジュールが早まっている場合には、用意したテストケースが不足していないか、すべてのケースが確実に実行されているかを確認する必要があります。
テスト対象の現在の品質
テストケースの実行状況や故障の発生数、欠陥の修正数などのデータを用いて、テスト対象の品質を評価します。例えば、実行されたテストケースの数が少ないにもかかわらず、故障の発生数が多い場合、テストを進めることでさらに多くの故障が発生するリスクがあると判断されるため、テストコントロールへのフィードバックを行います。
テストアプローチの十分性
選択したテストアプローチについて、その効果を評価します。例えば、体系的なテストアプローチを採用し、標準的なテスト条件一覧を活用して設計を行った場合に、一覧に含まれないテスト条件から多くの欠陥が見つかった場合、標準のテスト条件一覧の見直しが必要です。このように、テストコントロールを通じてアプローチの改善を図ります。
テスト目的に対するテスト活動の効果
計画時に設定したテスト目的に基づき、テストが十分に行われているかを評価します。例えば、テスト目的として「要件、ユーザーストーリー、設計、およびコードといった作業成果物を評価する」ことが含まれている場合、これらの成果物を評価した結果として、テスト実行中に発見される故障の数が減少していることを確認します。このような場合、プロジェクト期間中に作業成果物の評価に関するフィードバックを直接テストコントロールに反映させることは難しいかもしれませんが、将来の開発プロジェクトにおいて活かせる重要な教訓となります。
テスト活動の期間中には、これらの評価を行う必要があります。以下では、代表的なテストメトリクスについて説明します。
計画したテストケースの準備が完了した割合
計画に沿ってテストケースが設計・実装され、全体の進捗がどの程度かをモニタリングします。これにより、テスト実行に着手するまでに必要な作業があとどれくらい残っているかを把握します。具体的には、設計予定のテストケースがどれだけ完成しているかという指標を用いる場合があります。また、自動テスト用のスクリプトを作成しながらテスト実行を並行して進める場合、テスト実行の進捗状況とスクリプト作成作業の進捗を比較しながら作業を進めることが求められます。
計画したテスト環境の準備が完了した割合
テスト環境の準備状況は、テスト対象によって大きく異なります。
例えば、組込みソフトウェアのテストでは、複数台のハードウェアを調達する作業から準備を始めることが必要な場合があり、これには大きな作業量が伴います。このようなケースでは、準備が必要なすべてのテスト環境に対して、どの程度進捗しているか、またいつ準備が完了するのかが、テスト実行を開始する判断を行うための重要なメトリクスとなります。
テストケースの実行
準備したテストケースがどれくらい実行済みかを測定します。これにより、残りのテストケース数を把握できるため、テスト実行に必要な期間を常に見積もることが可能です。ただし、実行したテストケースの数だけを計測しても十分な情報を得ることはできません。各テストケースの実行に必要な時間を考慮して、計算することが重要です。
欠陥情報
欠陥情報には、欠陥密度、検出および修正された欠陥の数、故障率、確認テストの結果などが含まれます。これらの情報をもとに、テスト実行の優先順位を再検討したり、必要に応じてリソースを調整するなど、テスト活動を効果的にコントロールすることが可能です。
欠陥密度は以下の式で算出します。
欠陥密度 = 欠陥数 ÷ プログラム規模
プログラム規模の測定には、ソースコードの行数やステートメント数、あるいはファンクションポイント数などを使用します。また、欠陥数の計測やプログラム規模の算出に際しては、プロジェクト全体で統一したルールを設定することが重要です（測定開始時期や測定対象など）。ルールが曖昧だと異なる基準での比較となり、欠陥密度の算出自体が意味を失う可能性があります。
故障率は単位時間あたりの故障発生回数を指しますが、ソフトウェア開発ではハードウェアとは異なる故障の概念が適用されます。例えば、テストケースを実行中の期間における実際のテスト作業時間に対して、どの程度故障が発生したかを計算することが可能です。
テストレポートの目的、内容、読み手
テストレポートの主な目的は、テスト活動の結果をステークホルダーに共有すること、また、得られた知見をメンテナンスフェーズや将来のプロジェクトに活用するための情報を提供することです。結果の要約としては、テスト期間中の出来事や終了基準達成日などの具体的なデータが含まれます。次の活動に役立つ情報としては、テスト全般の分析結果や指標が挙げられます。
テストレポートは大きく分けて、テスト中に作成する進捗レポートと、テスト終了後にまとめるサマリーレポートがあります。
テストサマリーレポートでは、最新の進捗レポートや関連情報に基づき、実施内容の要約、計画通りに進行しなかった場合の理由や対応策を記載します。また、終了基準の判定結果を記載する際には、指標を活用します。さらに、リリース時に受け入れるリスクアイテムを列挙し、発生確率や想定される問題への対応を明確にします。例えば、「うるう年の12月31日の予約ができない」といった故障が残る場合、リスクが許容範囲内である理由を説明します。加えて、再利用可能な成果物についても記載します。
進捗レポートやサマリーレポートの具体的な内容は上述の通りですが、プロジェクトの性質や組織の要件、ソフトウェアライフサイクルに応じて適宜調整が必要です。
簡易なソフトウェア更新プロジェクトでは、レポート作成コストを考慮し、効率化が求められます。「はじめに」の部分を共通フォーマット化するなどが有効です。また、自明な事項を省略しつつ、重要な部分、特に残存リスクは必ず報告します。
アジャイル開発では、タスクボードやバーンダウンチャートなどを活用し、進捗レポートを代用します。日々の朝会やスタンドアップミーティングで情報を共有するのが一般的です。レポート内容は読み手に応じて調整します。
開発担当者やテストチーム向けのレポート
テスト予定件数や実績件数、欠陥の発生・修正状況を簡潔に示します。多くの欠陥が発生している場合は、それらの修正予定日を具体的に記載し、テスト再開のスケジュールを明確にします。
プロジェクトマネージャー向けのレポート
通常は開発者向けの内容で十分ですが、進捗に影響を与える遅延や欠陥の検出がある場合、プロジェクトマネージャーがテストコントロールを行える情報が有用です。例えば、故障の種類やリソース配分の必要性をリストアップします。
経営者向けのレポート
テストプロジェクトの全体状況を簡潔にまとめ、コスト、進捗、品質について「良好」「課題あり」など一言で説明します。課題がある場合、その理由と対処状況も簡潔に記載します。
構成管理
構成管理は、Configuration Management (CM) の日本語訳であり、ソフトウェア分野では特にSCM (Software Configuration Management) と呼ばれます。この管理では、部品の管理に加えてバージョンのコントロールやトレーサビリティの確保が重要な役割を果たします。
簡単に言えば、「構成管理とは、特定の時点（バージョン）のプロダクトを構成する部品を一意に識別可能な状態で管理・記録すること」です。
例えば、「ソフトウェアプロダクトAのバージョン1.1」と指定された場合、それに対応する実行ファイルや関連する必要ファイル、ヘルプ、マニュアルなど、プロダクトAの全構成要素を正確に取得できる状態であることが、バージョン管理が適切に行われている状態を意味します。
さらに、プロダクトAを構築するためのソースコード、ビルド環境、テスト環境、ユーザーマニュアル、ヘルプ、その他のパッケージ情報なども一括して管理される必要があります。これらの関連性を追跡できる状態をトレーサビリティと呼びます。
テストにおける構成管理
ソフトウェアテストにおいて、構成管理はどのような役割を果たすのでしょうか。
例えば、あるテスト手順に必要な入力データが記録されていなかった場合、そのテストを再実行したり次のバージョンで同様のテストを行う際に、テスト担当者がデータを探し回り、何日も無駄にすることがあります。また、あるテストで発見した故障を再現するためのテストスクリプトが明確でなければ、修正後の確認テストがスムーズに行えなくなるでしょう。
テストにおける構成管理では、テスト対象プロダクトの部品（テストアイテム、例：ソースコード）だけでなく、テスト計画、手順、スクリプト、環境、結果などのテストウェアも管理対象に含まれます。これらはすべてバージョンコントロールを行い、互いに関連付けられた状態を維持する必要があります。また、テストアイテム（ソフトウェアプロダクト）とテストウェア間のトレーサビリティの確保も重要です。
しかし、テストウェアの構成管理は通常の開発プロセスから分離されることが多いのが実情です。一部の組織ではドキュメントやソースコードのバージョン管理は行う一方で、テストデータやスクリプトの管理が手付かずという場合があります。構成管理には手間や専門技術が求められるため、テストウェアの管理にリソースを割けないことも原因の一つです。
ただし、古いテスト手順を使って確認テストを行い、欠陥が修正されたと誤解した結果、ユーザー環境で故障が発見されるといったトラブルは避けなければなりません。これを防ぐためにも、テストにおける構成管理は他のソフトウェア構成管理と同等に重要です。次に、テストでの構成管理の対象や具体的な実施手順について説明します。
テストウェア構成管理の手順
構成管理を実施する手順は、一般的に以下の通りです。
- 構成管理対象を決める
ソフトウェアプロダクトの構成管理では、主にバージョンコントロールが中心となります。
前述の構成管理対象となる成果物の中から、各プロジェクトにおいて何を管理すべきかを選定します。管理対象と管理方法については、プロジェクト開始時（マスターテスト計画作成時）に明確に決めておくことが重要です。
規模の大きいプロジェクトでは、専任者を配置し、ツールを用いて管理を行います。ただし、最初からすべてを網羅的に記録するのは難しいため、プロダクトの規模や特性、組織のリソースに応じて、実現可能な範囲で管理対象を選定することが現実的です。
- 構成管理方法を決める
決定した構成管理対象について、記録方法や使用ツール、専任者の有無、記録の詳細度（例: 記録間隔）などを定めます。特に、頻繁に更新されるテストスクリプトなどに対して、どのタイミングでバージョン管理を行うかや管理ルールを策定します。
例えば、どのテスト手順書に対応するテストスクリプトなのか、どのスクリプトの実行結果なのか、使用したテストデータは何か、といった個別の管理対象間の関連付けを可能にすることが重要です。トレーサビリティを確保しておくことで、特定のソフトウェア機能を改修した際、どのテストを実施する必要があるかがすぐに把握できます。これにより、効果的かつ効率的なテストが実現します。
- 記録を残す
管理対象や方法が決定し、構成管理を開始したら、バージョン情報などの更新履歴を記録します。これには文書化や構成管理ツールの使用が考えられます。どちらの方法を用いる場合でも、記録が正確であることが重要です。 - 継続的に管理し、参照可能な状態を維持する
プロジェクトの初期段階では記録を徹底していても、進行につれて管理が疎かになることがあります。しかし、管理が不完全だと、構成管理の利点を享受できず、むしろ負担が増加する結果となります。
専任者を配置し、ツールの適切な利用方法を教育し、管理状況を定期的に確認する機会を設けることで、構成管理を継続的に維持しましょう。これにより、必要なときに迅速かつ正確に情報を参照できる体制を確保することができます。
※確認問題