基本的なテストプロセスにおけるテストの活動・Part 3

基本的なテストプロセスにおけるテストの活動・Part２では、「テスト設計」「テスト実装」の２つのテストプロセスにおける活動を紹介しました。本記事では、次に最後の2つの活動を一緒に見ていきましょう。

• テスト実行
• テスト完了

⑥テスト実行

テスト実行活動には、次の主な活動があります。

テストアイテムまたはテスト対象、テストツール、テストウェアのIDとバージョンを記録する

テスト実行を始める際には、テストケースに必要な情報を記録します。テスト対象となるソフトウェアは明確な場合が多いですが、どのバージョンをテストするかは実行直前に確認する必要があります。また、テストデータやテストツールを使用する場合、それらのバージョンやスクリプト情報もテストウェアのIDとして記録します。テスト結果は、定められたテストケースや手順に従い、記録として残します。近年の開発環境では、これらの記録を自動でログに残す設定が可能なシステムもあります。

手動で、またはテスト実行ツールを使用してテスト実行する

テスト手順に基づき、テストは人やテスト実行ツールによって実施されます。テスト対象を直接操作する場合もあれば、リモートアクセスを通じて遠隔で操作する場合もあります。また、統合開発環境を利用したテスト実行など、さまざまな方法でテストを実行することが可能です。

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

テストケースや手順に定められた確認項目や判定基準、およびテスト全体の合否を決める標準文書の定義とテスト結果を照合します。結果が一致している場合や、単に測定目的の項目である場合は、テストを合格または完了として記録し、次のテストケースの実行に進みます。

不正を分析して、可能性がある原因を特定する

テストケースの記述やテスト設計の基盤となるテストベースと照らし合わせて、何が不適切な動作かを分析します。テスト対象を操作した順序に起因するのか、または使用するテストデータを変更した際にも不正が発生するのかなど、原因を特定するために、不正が発生するパターンやケースを特定していきます。

故障を観察し、観察に基づいて欠陥を報告する

テスト結果がテストケースで設定された期待結果と異なり、不正の分析から故障や欠陥と判断された場合、欠陥レポートとして報告します。報告をまとめる際には、故障として観察された直接的な事象だけでなく、他の要因によって同様の問題が発生する可能性や、該当テストケース以外に影響がないかどうかも考慮して含めるようにします。

テスト実行の結果を記録する

テストケースごとの結果を期待値と比較し、合格か不合格かを判断します。不合格の場合は欠陥レポートを作成し、同じ手順で実行しても不合格が予想されるテストケース（ブロックケース）も記録します。ブロックとは、外部要因でテスト実行が妨げられている場合を指し、環境が整わない状況（ソフトウェアライセンスの購入待ちや機器の使用順番待ちなど）も記録します。テスト結果は、コンピュータデータファイルや手書きメモ、測定結果を含めて具体的に残し、実行環境や使用ソフトウェア、テストツールの構成やバージョン、テストウェアのIDもエビデンスとして記録します。

不正への対応の結果、または計画したテストの一環として、テスト活動を繰り返す

不正を欠陥レポートとして登録し、修正が行われた場合には確認テストを実施します。確認テストは、修正されたテスト対象がテスト環境にリリースされた直後に行うこともあれば、テスト実行スケジュールに基づいて集中して行う期間を設け、そのタイミングでまとめて実施することもあります。また、確認テストとは別に、既存機能への影響を確認するためにリグレッションテストを計画して行います。

テストベース、テスト条件、テストケース、テスト手順、テストスイートの間で双方向のトレーサビリティを検証し更新する

テストが要件や仕様に基づいて正しく実施されていることを確認し、各要素が互いに正しくリンクしているかを見直すプロセスです。これにより、テスト実行の過程で変更や修正があった場合も、それがすべての関連要素に反映され、整合性が保たれます。

⑦テスト完了

テスト完了では、テストケースや欠陥レポートなどの成果物をまとめ、テスト計画の目的が達成されたかを確認します。コードカバレッジや要件に対するテストの十分性、非機能要件のカバー、システム構成の網羅性を評価し、テスト終了基準に基づいて結果を分析します。バグ管理図やメトリクスも基準として、欠陥の収束状況やテストの進捗を確認します。

また、計画値段での終了基準はあくまでテスト開始前の仕様や品質の前提を基に決められますが、進捗に伴う仕様変更や顧客ニーズの変化により見直されることがあります。そのため、完了のタイミングはプロジェクト形態によって異なり、テストレベル移行時や全テスト終了時、またはアジャイル型では各イテレーションごとに実施されることがあります。また、場合によってはテストが打ち切られることもあります。

本記事では、ソフトウェアテストプロセスにおける2つの活動について学びました。以下のリンクにあるミニテストを行って、これらの活動に関する知識を確認してみましょう！

以下がその主な活動になります。

すべての欠陥レポートがクローズしていることを確認する。またはテスト実行の終了時に未解決として残されている欠陥について変更要求またはプロダクトバックログアイテムを作成する

以前のテストレベルや現在のテストレベルで発行された未解決の欠陥レポートが残っているかを確認します。問題が解決している場合は、そのレポートを完了・クローズします。次のテストレベルで修正することが決まっている場合は、欠陥レポートを次のレベルに引き継ぐか、未対応の場合はプロダクトバックログアイテムとして記録し、対応漏れがないようにします。

テストサマリーレポートを作成して、ステークホルダーに提出する

テスト結果を終了基準と比較・分析し、テストレベルが終了可能かどうかを判断するために、ステークホルダーへ報告するドキュメントを作成します。このレポートでは、テストの合格率や欠陥レポートの件数と対応状況などを整理し、テストに関連する全ステークホルダーに報告します。

ステークホルダーは、テストが終了した際に直接的または間接的に影響を受ける関係者で、テストレベルや対象によって異なります。最終的に、テスト結果と終了基準に基づいた分析により、テストレベルの終了や打ち切りについてステークホルダーの合意が得られれば、テストレベルの終了が宣言されます。しかし、現実には、開発責任者の指示で終了することもあり、その場合はステークホルダーは開発責任者となります。テストマネジメントの証拠を残す場合は、モニタリングやコントロールの結果を収集・分析し、文書としてまとめます。特に独立したテストチームが担当する場合、この結果を文書化するのも重要な活動の一環です。

テスト環境、テストデータ、テストインフラストラクチャー、その他のテストウェアを次回も使えるように整理し保管する

再利用可能なテストがある場合、そのための整理やメンテナンスを行います。テストウェアの直接的な修正や、ガイドラインやトレーニング資料の整備、テストツールのバージョンアップ後も使えるようにテストスクリプトを調整するなど、再利用のための作業には一定の労力が必要です。プロダクトのバージョンアップや異なる機種への移植がある場合、次のリリースや機種に対応できるように、テストケースやテストベース、テスト手順などをメンテナンスします。

テストウェアをメンテナンスチーム、他のプロジェクトチーム、および／またはその使用により利益を得る可能性のある他のステークホルダーに引き継ぐ

プロジェクトの開発部門と保守部門が異なる場合、テストウェア一式を保守部門に引き渡します。保守部門は、テスト結果を基にプロダクトの品質状況を把握したり、リリース後に欠陥が見つかった際のトラブルシューティングにテストウェアを活用します。

収集した情報をテストプロセスの成熟度を改善するために利用する

このタスクを実施するため、テスト終了後に当該テストレベルの全ステークホルダーが集まる「ポストモーテム」（振り返り会）を開催します。この会議では、テストコントロールに関する課題やテスト結果を基に、プロセスやテストウェアを改善するための良い点と悪い点を率直に議論します。

ポストモーテムで得られた改善点を次のテストレベルやプロジェクトに引き継ぐ体制を整えないと、振り返りがその場限りになり、改善にはつながりません。そのため、議事録やアクションアイテムリストを作成し、マネジメント層がフォローすることが重要です。

本記事では、ソフトウェアテストプロセスにおける最後の2つの活動について学びました。以下のリンクにあるミニテストを行って、これらの活動に関する知識を確認してみましょう！

https://exam-site.briswell-vn.com/startTest/jstqb-2-3-jp