総合テストとは何か?総合テストの目的と進め方を解説
総合テストの目的
総合テストでは要件を満たしているかの確認を行うことを目的としてアプリケーション全体をテストします。ここでのテストは要件定義書に記載されている内容が実現できているかのテストになります。
要件定義から始まるソフトウェア開発は総合テストで完了となります。この流れを見てみると、開発(コーディング)より前には設計、後にはテストとなっています。
そして、上記のように設計フェーズとテストフェーズが対になっており、これをV字モデルと呼びます。
このV字モデルは、単体テスト、結合テスト、総合テストにおけるそれぞれのテスト対象の設計フェーズを表しています。つまり、要件定義、外部設計、内部設計の通りにプログラミングできているかの確認を対となっているテストで行います。このように、視点を変えたテストを積み重ねることで、アプリケーションの品質を確認していきます。
また、要件定義に記載されないこともありますが、総合テストでは下記のテストも行います。
- 操作性テスト:アプリケーション利用者の立場で操作に着目したテスト
- 負荷テスト:大量データの処理などアプリケーションに負荷をかけるテスト
- ロングランテスト:特にシステム系のアプリケーションでの長時間稼働のテスト
- セキュリティテスト:不正アクセス防止、情報漏えい防止などのテスト
総合テストの進め方
ここからは総合テストの進め方を解説していきます。
総合テストは以下のような流れで進めていきます。
- テスト設計
- テストケース作成
- テスト環境準備
- テスト実行
- バグ修正
- テスト進捗管理
ここからは、これらの内容をさらに詳しく紹介していきます。
1.テスト設計
テスト設計では、要件定義書を確認し、どのようなテストを行うか設計します。
総合テストではアプリケーション視点ではなく、ユーザー視点からのテスト設計となります。つまり、アプリケーションの機能を順番に確認するのではなく、ユーザーがアプリケーションをどのように使うかに着目してテスト内容を決めます。
テスト設計でも、どこまでテストをするかが課題となります。
メインとなるユースケースは必須ですが、重要度、頻度が高くない使われ方に対しては、どこまでテストを行うかを決めます。もし、ユーザーズマニュアルがあるのなら、その内容からテスト範囲を決めるという方法もあります。
2.テストケース作成
テスト設計書からテストケースを作成します。
テストを行う操作方法と期待する操作結果を記述します。テストを実施する人(テスター)を特定しなくても、テストを実行できるようなテストケースでなければなりません。
3.テスト環境準備
開発するアプリケーションによっては、テスト専用の環境を利用する場合があります。テスト環境を準備し、テストケースを実行できるように、テストデータを作成しておきます。
4.テスト実行
テストケース毎に担当者を決めて、テストを実行します。
テスト結果がOKとなった場合には、画面キャプチャー、ログなどのエビデンスを取っておき、テスト結果報告書と一緒に提出します。また、テスト結果がNGとなった場合には、バグ管理ツール(もしくはエクセル表など)に提起してプロジェクト内に共有します。バグ提起では、バグを再現できる最短の操作を記述することを意識してください。
5.バグ修正
登録されたバグについて、原因を調査し修正を行います。確実に修正するためには、修正レビューが効果的です。ただし、すべてのバグ修正に対してレビューを行うのが難しい場合には、設計に起因したバグに対してのみレビューを行うなど、一定の基準を設けることも必要です。
6.テスト進捗管理
総合テストが完了するのは、作成したテストケースがすべて実行され、そして発見されたバグの対応がすべてクローズされたときです。
想定した件数以上のバグが発生した場合には、予定していた期間を大きく超えることもあります。そのため、テストケースの実施済件数、バグの登録件数、バグ修正件数を定期的にチェックして、スケジュール通りに総合テストを完了できるかを確認できるよう、進捗管理を行います。
ソフトウェアの品質とは
開発するソフトウェアの品質は何で決まるのでしょうか?品質が悪いソフトウェアと聞いて真っ先に考えるのは、本番運用後にバグが発生することです。しかし、バグが無いということだけで品質が高いとは言えません。
ソフトウェアの開発とは、要件定義に基づいて行うわけですので、「顧客の要求を満たしているか」ということが品質を決める大事なポイントです。
その他に、ソフトウェアの品質を決定する一般的な項目として下記があります。
- 機能性:機能が利用者の使用目的に合っているか
- 信頼性:エラーがなく安定して正常動作するか
- 使用性:利用者にとって操作を覚えやすいか、操作しやすいか
- 効率性:処理においてレスポンス時間、スループットが適切か
- 保守性:プログラムの変更、追加、拡張、修正が容易に行えるか
- 移植性:別の環境に移行して容易に動作させることができるか
これらの内容は非機能要件の記事で詳しく解説していますので、こちらもあわせてご参照ください。
総合テストの後にすること
受け入れテスト
開発プロジェクトでのテストは総合テストで完了となります。
完成したアプリケーションを納品して、顧客から「思っていた通りのものが出来ている」と言ってもらえるといいのですが、そうでない場合もあります。
納品後のトラブルを無くすためには、総合テストの後に、顧客にもテストをしてもらいます。これを受け入れテスト、もしくはユーザーテストと言います。
この受け入れテストは、顧客側の責任で行われ、アプリケーションが要求した通りに動作するかが確認されます。
もし、顧客から「要求と違う動作になっている」と指摘されたときには、要件定義書、外部設計書を確認します。
要件定義書、外部設計書の記載内容と異なった動作になっていた場合には、アプリケーションの不具合となりますので、ただちに修正しなければなりません。
逆に、要件定義書、外部設計書の記載にない場合には、顧客からの新たな要求となり追加契約となることもあります。
そのためにも、要件定義書、外部設計書は顧客側にも理解できるようなドキュメントとし、顧客の承認を取っておきましょう。
リリースの準備
開発したアプリケーションによってリリースの準備内容は様々です。準備すべき主なものは下記になります。
プログラム一式
開発したプログラム一式を準備します。このときバージョン情報を設定します。また、リリースするプログラムは動作環境の違いにより、テスト環境のものと同一とはならないこともあります。
リリース作業手順書
リリース作業が複雑であったり、複数人が作業する場合には、作業手順書を作成します。
リリースノート
ユーザーへの案内、及びプロジェクト内のバージョン管理のためアプリケーションの変更内容を記載します。ユーザーへの案内については主な変更内容までとして、細かい変更については、"その他軽微な修正"として下さい。
リリース判定
すべてのテストが完了したところで、リリース判定会を実施します。品質の高いアプリケーションをリリースするためには、組織でリリース基準を設定することが必要です。リリース判定の基準として考えられるものは下記があります。
開発プロセス
開発内容から見て、適切なプロセスで開発が行われたかを確認します。
テスト結果
単体テスト、結合テスト、総合テストで実施したテストケースとその結果を確認します。また、発見したバグを修正できないままリリースする場合には、その影響もあわせて確認します。
開発成果物
要件定義書、外部設計書、内部設計書、ソースコード、そして各レビュー結果の記録を確認します。
リリース準備
この後のリリースまでの準備に問題がないか確認します。
これらの項目をリリースの直前にすべて確認することはリスクがありますので、どのような開発プロセスにするかは開発プロジェクトの開始時に承認を取り、また、各フェーズの終了時にその成果物に対する承認を得るようにします。