JBC開発標準サンプル 「テストガイドライン」


 ■はじめに

本書は、JBC開発標準文書の「工程管理要領」に基づき、テスト工程の作業についての詳細なガイドラインを示すものである。
基本的にはjavaによるWEBアプリケーションの開発を想定したガイドであるが、設計概念・考え方等、他の言語での開発でも流用できる。

各工程・タスクの概要・INPUT/OUTPUTの関連は「工程管理要領」を参照。また、JBC標準文書のドキュメントフォーマットを参照し、本書の内容と見比べながら理解すること。

本書は標準的なガイドラインであるが、各プロジェクトの特性にあわせて方針を決定すること。
 (例)  本書の記述では画面単位のテストは単体テスト工程に記述してあるが、プロジェクトによっては結合テスト工程になっている、等。


 ■単体テスト

1.テスト目的

単体テストは、作成したプログラムの品質を高めることやプログラムの品質を見極めることを目的とする。
単体テストを行っておくことによって結合テストや総合テストにおいてメソッドやクラスレベルでの障害を出にくくし、以降の工程の効率化を目指す。

2.テスト実施前提条件

・テスト開始の段階までに本工程で実施するテスト内容が明確になっていること。
・プログラム開発工程にて、コーディングが完了しており、コーディング規約に則したソースレビューが完了していること。

3.テスト概要

標準的なテスト内容を以下に示す。各プロジェクトの特性にあわせ、テスト方針を決定しておくこと。

(1)モジュールテスト(ホワイトボックステスト)

・最小単位でのテスト。Javaによる開発においてはクラスのメソッド単位のテストとなる。
・正常値だけでなく異常値を入力した場合エラーが正しく発生するかもテストする。
・プログラミングしたすべてのソースコード上をテストで通過させ、要求通りの動きをしていること、予想外のエラーを返すことが無いことを確認する。
・テスト実施の準備として、テスト対象メソッドが単体で動作するような呼び出し用のドライバを用意する必要がある。
・全クラス/メソッドでのテストを実施するのが望ましいが、画面等から直接呼び出されるメソッド等に関しては、画面・プログラムテストにて実施してもよい。
  ただし、共通モジュールおよびDBアクセス用モジュール(DAO)に関してはモジュールテストを必須とする。
※モジュールテストについては、JUnit等のツールを使用し自動化してもよい。テスト計画時に決定しておく。

(2)画面・プログラムテスト

・画面単位でのテスト。バッチの場合はプログラム単位のテスト。
・初期表示やボタンの押下等のイベント発生時に正常な動き、正常な表示となっているか確認する。
・ステータスや使用者(ロール)等の条件で画面表示のパターンが変化する場合に条件分岐を網羅する。
・各入力項目に関しては正常値だけでなく異常値、限界値・境界値もテストして正常な動きとなっているか確認する。
・画面レイアウトのくずれや画面表示文言の誤字脱字も確認する。
・入力内容チェックのテストをする。必須チェック、型チェック、MAX値チェック、相関チェック等。

4.テスト仕様書

(1)ケース作成

・テストするプログラムの全命令を通過(命令網羅)するケースを洗い出す。
・真・偽の条件分岐も1回は実行させ(条件網羅)、複数の条件分岐も全て1回は実行させる(複数条件網羅)。
・ボタン押下時、画面イベント発生後の1トランザクションですべてのロジックが通過するケースを洗い出す。
・テストケースに予想結果を記述する。予想結果は詳細設計時に作成したプログラム仕様書、画面仕様書、バッチ仕様書等、詳細設計書の記述どおりとなることとする。

(2)エビデンス

・各プロジェクトの特性にあわせ、テスト計画時に取得エビデンスを決定しておくこと。
・画面HC、ログ、DBダンプ、ツールの実行結果等。
・エビデンスについては実施前と実施後を取得すること。

(3)ケースの妥当性

・テストケースの件数が十分であるかを判断するために、プログラムの規模からテストケースの理論値を算出する。
  ※JBC標準の算出方法は検討中。品質管理ガイドラインに記載予定。
・テストケースの内容が妥当か判断するために、テストケースにおける分類毎の割合について理論値を定義する。
  例)正常処理が40%、異常/例外処理が30%、境界/限界処理が20%、その他処理が10%等

(4)カバレッジ

・命令網羅および分岐網羅のカバレッジは100%を目指す。
・100%にならない場合は正当な理由をリーダに説明し承認が得られ、かつ次工程にてカバーできるのであれば可とする。

(5)レビュー

・テスト仕様書のレビューを行い、ケースの妥当性を検証する。
・テスト予想結果は詳細設計成果物の記述とあっていることを確認する。

5.テスト消化

・レビュー済のテスト仕様書に基づきテストを消化し、予想結果どおりになることを確認する。
・障害を発見した場合、プロジェクト計画時に定められた障害管理に基づき障害を管理し、再テストを正常な結果になるまで繰り返す。
・テスト消化時にはテスト仕様書で定められたエビデンスを取得する。

6.テスト終了条件

・すべてのテストケースの消化が完了していること。またエビデンスの取得も完了していること。
・発見された障害の修正が終了し、再テストまで完了していること。
・テスト結果のレビューが行なわれており、テストの妥当性を確認されていること。
・すべてのテストケースが消化できない場合は正当な理由をリーダに説明し承認が得られ、次工程に持ち越す課題が明確になっていること。


 ■結合テスト

1.テスト目的

・結合テストは、作成したプログラムについて機能や業務等の操作によるテストケースを作成し、要求仕様通りの動作確認を目的とする。
・結合テストは、ブラックボックステストであり、インプットに対して正しいアウトプットが得られることを確認する。

2.テスト実施前提条件

・詳細設計工程にて、結合テスト計画書が作成されており本工程で実施するテスト内容が明確になっていること。
・単体テスト工程が完了していること。
・結合テスト用のテスト環境が用意されており、アプリケーションが正常にインストールされている状態であること。
・他システムとの疎通がテストできる環境が用意されていること。

3.テスト概要

標準的なテスト内容を以下に示す。各プロジェクトの特性にあわせ、要件定義時点でテスト方針を決定しておくこと。

(1)機能テスト

・機能で分類された画面の集まり(画面群)の単位でのテスト。検索〜照会〜登録〜確認〜完了等、一連の機能の流れを確認する。
・一連の機能の流れの中でエラーが発生した場合の動作もテストする。
・バッチの場合は1つのJOBの単位のテストになる。また、障害時のリランテストも行なう。
・ブラックボックステストであり、プログラムの入出力を意識したテストである。
・一連の機能の流れについて、考えられるデータのバリエーションを洗い出し、データバリエーションテストを行なう。
・各機能(画面)のレスポンス時間を計測し、要件定義時点で決定したサービスレベル要件が満たせていることを確認する。
※ただし、結合テストの段階では、単一の処理での時間をあらかじめ確認することが目的であり、実際のサービスレベルについては同時アクセス等、
  高負荷の状態でのテストを総合テスト時に実施する。

(2)業務シナリオテスト

・業務単位のテスト。要件定義工程で作成した業務フローを元にテスト仕様書を作成しテストする。
・実業務の流れに沿ってシステムをオペレーションし、正常な動作になることを確認する。

(3)他システム間連携テスト

・他システムとデータ送受信が行われること、送受信データがシステムにより正常に処理が行われることを確認するテスト。
・開発中のシステムから他システムへ送信したデータがエラーなく正常に処理されることを確認する。
・他システムから開発中のシステムへ送信したデータがエラーなく正常に処理されることを確認する。

4.テスト仕様書

(1)ケース作成

・一連の機能の流れのケースを画面(機能・JOB)群単位に洗い出す。
・一連の機能の流れの中でなんらかのエラー(DBダウン等)が発生した場合を考慮し、エラーがハンドリングされ正しいエラー画面に遷移するケースも作成する。
・バッチの場合にはデータ不正等を考慮したケースを洗い出し、バッチ異常終了→データ修正→リランのケースも作成する。
・一連の機能の流れについて、考えられるデータのバリエーションを洗い出す。
・業務フローからケースを洗い出す。複数業務フローの組み合わせにおいてもパターンを洗い出しケースを作成する。
・システム間でのデータの送受信が行えるか、送受信したデータが正しく処理できるかのケースを作成する。(バッチと連携したシナリオでもよい)
・テストケースに予想結果を記述する。予想結果は要件定義時の業務フロー、基本設計時の画面仕様書・バッチ仕様書の記述どおりになることとする。
・レスポンスのテストの予想結果については、サービスレベル要件に記述されている時間(秒数)が確保されていること。

(2)エビデンス

・各プロジェクトの特性にあわせ、テスト計画時に取得エビデンスを決定しておくこと。
・処理前後が分かるINPUT/OUTPUT。
・障害管理票等、障害管理および修正したことが確認できるエビデンス。

(3)ケースの妥当性

・テストケースの件数が十分であるかを判断するために、プログラムの規模からテストケースの理論値を算出する。
  ※JBC標準の算出方法は検討中。品質管理ガイドラインに記載予定。

(4)レビュー

・テスト仕様書のレビューを行い、ケースの妥当性を検証する。
・テスト予想結果は業務フロー、基本設計成果物の記述とあっていることを確認する。

5.テスト消化

・レビュー済のテスト仕様書に基づきテストを消化し、予想結果どおりになることを確認する。
・障害を発見した場合、プロジェクト計画時に定められた障害管理に基づき障害を管理し、再テストを正常な結果になるまで繰り返す。
・テスト消化時にはテスト仕様書で定められたエビデンスを取得する。

6.テスト終了条件

・すべてのテストケースの消化が完了していること。またエビデンスの取得も完了していること。
・発見された障害の修正が終了し、再テストまで完了していること。
・テスト結果のレビューが行なわれており、テストの妥当性を確認されていること。
・すべてのテストケースが消化できない場合は正当な理由をリーダに説明し承認が得られ、次工程に持ち越す課題が明確になっていること。


 ■総合テスト

1.テスト目的

・総合テストは、開発したシステムの日常業務のテストケースを作成し、検証することにより、要求仕様の通りの動作確認を目的とする。

2.テスト実施前提条件

・基本設計工程にて、総合テスト計画書が作成されており本工程で実施するテスト内容が明確になっていること。
・結合テスト工程が完了していること。
・総合テスト用のテスト環境が用意されており、アプリケーションが正常にインストールされている状態であること。

3.テスト概要

標準的なテスト内容を以下に示す。各プロジェクトの特性にあわせ、要件定義時点でテスト方針を決定しておくこと。

(1)サイクルテスト

・締め処理を含めた日回し(サイクル)テスト。
・締めの処理を含めたテストなのでオンライン処理、ジョブネット単位のバッチ処理、他システム連携すべてを連動させ日次・月次・年次のバッチを業務ライフサイクルに合わせて処理を行い、
  稼動を確認する。
・日次、月次、年次業務等について想定データを作成し、テストを行うことによって信頼性をテストする。

(2)性能負荷テスト

・業務ピーク時および高負荷時のオンライン処理、バッチ処理のパフォーマンスが要件定義時点で決定したサービスレベル要件を満たせていることを確認する。
    ※eLoadなどの負荷テストツールを使用してもよい。テスト計画時に決定しておく。
・高負荷時にサーバのメモリ、CPU等の使用率を取得し、使用率の限界値以内におさまっていることを確認する。

(3)障害回復テスト

・障害発生時にサービスが利用できるようになるまでの回復を行うテスト。
・通常運用時に障害が発生した場合を仮定し、マシンの切り替え作業やデータのバックアップからの回復手順を確認する。
・上記マシン回復からシステムの回復〜稼動確認までの一連の手順を確認する。
・マシン回復までは運用・基盤担当が主導でテストを行い、マシン回復以降、アプリケーションの稼動確認までをアプリケーション開発担当が主導でテストする。

(4)移行リハーサルテスト

・現行システムからの移行要件があるときに行う手順の確認テスト。 ※移行ガイドライン参照

(5)ユーザテスト

・ユーザが主体となって要求仕様通りにシステムが稼動しているかを確認するテスト。
・ユーザの視点でのテストであり、作成したシステムがリリース可能かどうかを判断する最終テストとなる。

4.テスト仕様書

(1)ケース作成

・日次、月次、年次業務を業務フローから洗い出し、バッチ〜オンライン〜バッチ等のサイクルからテストケースを作成する。
・サイクルテストでは業務サイクルが中心となるため、正常処理が多いテストケースになる。
・サービスレベル用件からピーク時のシステム利用者数、同時アクセス数にてテストできるようなケースを作成する。
・障害回復テストでは、障害回復手順書の作業の流れがテストケースとなる。
・ユーザテストに関してはユーザ主導でシナリオを作成いただく。
・テストケースに予想結果を記述する。予想結果は要件定義時の成果物の記述どおりになることとする。

(2)エビデンス

・各プロジェクトの特性にあわせ、テスト計画時に取得エビデンスを決定しておくこと。
・画面HC、ログ、DBダンプ等。
・障害管理票等、障害管理および修正したことが確認できるエビデンス。

(3)ケースの妥当性

・テストケースの件数が十分であるかを判断するために、プログラムの規模からテストケースの理論値を算出する。
  ※JBC標準の算出方法は検討中。品質管理ガイドラインに記載予定。

(4)レビュー

・テスト仕様書のレビューを行い、ケースの妥当性を検証する。
・テスト予想結果は業務フロー、基本設計成果物の記述とあっていることを確認する。

5.テスト消化

・レビュー済のテスト仕様書に基づきテストを消化し、予想結果どおりになることを確認する。
・障害を発見した場合、プロジェクト計画時に定められた障害管理に基づき障害を管理し、再テストを正常な結果になるまで繰り返す。
・テスト消化時にはテスト仕様書で定められたエビデンスを取得する。

6.テスト終了条件

・すべてのテストケースの消化が完了していること。またエビデンスの取得も完了していること。
・発見された障害の修正が終了し、再テストまで完了していること。(性能負荷でのNGの場合はパフォーマンスチューニングがなされていること)
・テスト結果のレビューが行なわれており、テストの妥当性を確認されていること。
・ユーザテストの結果について、テスト完了のユーザ承認が得られていること。


 ■管理

1.テスト計画

(1)テスト概要

・各テスト工程の概要を記載する。
・テストの範囲、目的、リスク、制限、優先度等を明確にする。

(2)テスト体制と役割分担

・テストの体制図を作成し、各役割と責任を明確にする。
・一般的には、テストやレビューで欠陥を摘出する場合は独立したテスト担当者を使うと効率が上がるため、「テストチーム」を立ち上げたほうがよい場合がある。
  独立いたテストチームのメリット、デメリットは以下の通り。
  <メリット>
  −先入観が無いため、異なる欠陥が見つけられる
  −システムの仕様策定中や実装中に想定どおりかを検証出来る
  <デメリット>
  −開発チームから隔絶されている場合に連携がとりづらい
  −独立したテストチームが、最終チェックポイントとしてボトルネックとなる
  −開発担当者の品質に対するマインドが薄れる
・運用担当者や基盤担当者がテストを実施する場合には、テスト範囲を明確にする。

(3)スケジュールと要員計画

・テスト工数を見積もる。以前のプロジェクトや類似プロジェクトから代表的な値をベースに見積もる方法や、作業の実行者やエキスパートが見積もる方法がある。
・テスト工数の見積りが終了すると、必要となるリソースを決定できるので、スケジュールおよび要員計画を立てる。

(4)開始基準・終了基準

・各テスト工程の開始基準・終了基準を明確にする。
・終了基準では、品質の妥当性を判断する。本節4参照。

(5)成果物

・各テスト工程での成果物(エビデンス)を明確にする。

(6)管理方法

・各テスト工程での進捗管理、レビュー管理、品質管理、変更・障害管理、構成管理等の管理方法を明確化する。本節2以降を参照。

(7)環境構成

・各テスト工程別にテスト環境の環境構成図または表をテスト計画書に添付しておく。

2.進捗管理

(1)予定/実績

・1日で消化できるテストケース作成数、テスト消化数を過去実績等から基準化する。
・総テストケース数、総テスト数と1日単位の基準値より、テストスケジュールを策定する。
・障害摘出率等の基準値より、テストスケジュールには改修、再テストの予定も組み込んでおく。
・日単位で作成予定テストケース数、消化予定テストケース数を割り振る。
・テスト担当者に日単位で実績を報告させ、予定に対しての実績(パーセンテージ)を管理する。

(2)テスト進捗モニタリング

テスト工程における進捗管理は、テスト作業を可視化し、管理する。モニタリングする情報は手動あるいは自動で収集し、たとえば終了基準を計測するために使用する。
収集する内容の例を以下に示す。

・作成したテストケースのパーセンテージ
・実行したテストケースのパーセンテージ
・テスト結果の合格/不合格数、障害摘出率のパーセンテージ
・障害の再テスト結果
・開発担当者およびテスト担当者のスキル、信頼度
・障害原因、他プログラムへの影響度

(3)テストコントロール

・リスク発生時(スケジュール遅延等)のテスト優先順位見直し
・開発担当者およびテスト担当者のスキル、信頼度により担当テストの割り振り
・環境の準備状況によるテスト順位の見直し

3.レビュー管理

(1)計画

・レビュー人選を行なう。役割と責任を明確にする。
・目標値の設定をする。1テスト仕様書に対しての指摘率あるいは指摘件数。
・レビュー結果が目標値の範囲内でなかったときの対処方法を決定しておく。
・レビューの完了基準を明確にする。
・レビュー結果の記録方法、指摘事項反映結果確認方法を明確にする。

(2)レビュー参加者の役割

参加者 役割
PM(PL) レビュー計画を立案し、実施スケジュールを作成。レビュー結果に対して責任を持つ。
作成者 レビュー対象のドキュメントに責任を持つ。
レビューア
(チェッカー)
レビュー目的にあった特定の技術やバックグラウンドを持つ各個人。レビュー対象ドキュメントの不具合、欠陥を指摘する。

記録者(議事録) レビュー中に出たすべての課題、問題点、未解決事項を記録する。

4.品質管理

・テスト結果の妥当性を判断するために、プログラム規模からのテストケース数、障害摘出数の数値を基準化する。
・設定したテストケース数、障害摘出数が基準値の範囲内でなかった場合の再テスト方法等の対処方法を明確にする。
・不具合の原因等から品質の妥当性を判断、品質基準が満たされない場合再テスト指示を行なう。
  (例)
  結合テストの原因分析をしたところ単体テストで摘出すべき障害が多発したため、単体テストを一部やり直す等。

※JBC基準文書「品質ガイドライン」を参照のこと

5.変更・障害管理

・変更・障害発生時の管理方法を計画する。管理フローを作成すること。
・管理台帳で変更・障害を一覧化し、管理票で1つ1つの障害または仕様の修正〜再テストを管理する。

※JBC基準文書「変更・障害・構成管理ガイドライン」を参照のこと

6.構成管理

・変更・障害発生時の修正前バージョンの管理方法を明確にする。

※JBC基準文書「変更・障害・構成管理ガイドライン」を参照のこと

7.テスト完了報告(テストレポート)

各テスト工程の終了時にテスト作業のサマリ情報を勘案してテスト完了報告(テストレポート)を作成する。
将来のプロジェクトにおいて方針決定や参考となるようにナレッジに蓄積させること。
下記に例を示す。
−テスト要約
−予定に対する実績、予定に対する相違の分析
−不具合原因分析
−障害摘出率、カバレッジ等からみた品質、信頼性
−すべての未解決事項、次工程での解決見込み
−総合評価(テスト目的に対する十分性、採用したテストアプローチの十分性、テスト効率)