プログラムテストについて

最近プログラムテスト仕様書を書くことが多くなってきました。
メモとして、テスト報告書についてまとめてみました。

１、テストってどんなことがあるか？。
①単体テスト……プログラミングの成果を検査するテスト
②結合テスト……内部設計の仕様を満たしていることを確認するテスト
③システムテスト……外部設計の仕様を満たしていることを確認するテスト
④運用テスト……要件定義を満たしていることを確認するテスト
これらのテストのうち、顧客に関係するのは「運用テスト」となる。

２、顧客にとって良いテスト仕様書とは？
顧客にとってテスト仕様書は、「要件定義書で決めた事項が満たされたシステムになっているかどうか、導入前にチェックして確認するための文書」となる。
顧客側は、主に下記のようなことを確認しますので、確認事項を考慮してテスト仕様書を作成しなければなりません。
・機能や性能が要求どおりの品質になっていること
・使い勝手や、ユーザーインターフェイスが業務作業に支障ないこと
・システムを導入するメリット（業務効率の改善、導入前より業務作業がやりやすくなるなど）が達成されていること

従いまして、顧客にとって良いテスト仕様書とは、これらの確認するために、「システムがきちんと完成していることが簡単に確認できる文書」となります。
また、テスト仕様書は、開発側の視点と顧客の視点、両方から見て満足できるものにしなければなりません。
つまり、「このテスト項目は、要件定義書のどの定義事項を確認するためのものか」、参照しやすくドキュメントにしましょう。

３、テスト項目はどのようなことを記述するか？
テスト仕様書を分かりやすくするためには、先頭に「テスト概要」を記述します。
概要は、いわゆる5W1Hを念頭に記述します。
What：何をテストするのか＝顧客に納入するシステム
Why：何のためのテストであるのか＝要件定義書で定義した事項を確認するため
When：運用テストの時期やスケジュール
Where：運用テストを行う場所や環境（顧客の業務環境を使ってテストするケースもある）
Who：テストを実行する担当者（顧客の業務担当者にお願いするケースもある）
How：運用テストのやり方。顧客に提供する操作マニュアルに記述された手順に従ってテストを実行する場合は、その旨を記述する

テスト仕様書の終わりには、まとめの報告（「テスト結果（結論）」）を記述します。
まとめの報告は、テストが完了しているのであれば、テスト結果に問題がないことを報告すればよいだけです。
テスト中に検出したバグの修正が完了せず、未解決のバグが残ってしまったテスト項目が存在する場合、バグが修正できなかったテスト項目ごとに、次のような事項を記述します。
・問題の原因・理由
・システムのどの機能や性能に、どのような影響があるのか
・どのような方針で、どのような対応をするのか
・どのような方法で改善するのか
・いつまでに対応するのか
・もし改善が顧客の稼働開始に間に合わないのであれば、バグを避けながら同等の機能・性能を確保できるような代替の手段や手順を記述します。

その他、実際に、テスト仕様書に記述すべきものとして、以下の事項があります。
 3.1.テストを実施した環境（テスト環境）
ここで必要なのは、「要件定義書で規定した環境」でテストする。
要件定義書が規定した環境でテストした場合は、そのことを明記したうえでテスト環境を具体的に記述します。要件定義書の環境と異なる環境（例えば、簡易化した環境）でテストした場合は、以下の点に留意する必要があります。
・テストを実施した環境を具体的に明示する
・テスト実施環境と業務遂行時の環境との差異を明確にする
・両者の差異はシステムの動作に影響を与えないと断言する

例えば次のように記述して、テスト実施環境が納得できるものであること記述します。
--------------------------------------------------------------
テストを実施したシステム環境を別紙に示します。今回のテスト環境は、実際の業務時の環境とは以下のような点が異なります。

（1）……

（2）……

しかし、これらの点はシステムのテスト結果には影響を与えません。今回のテスト環境で正常に動作すれば、実際の業務環境でも正常に動作します。
--------------------------------------------------------------

また、テスト段階で、顧客が業務で使用するときとは異なるケースがあります。この場合は、前提条件を明示するとともに、その条件がシステムのテスト結果には無関係であることを断言します。

例えば、次のように記述します。
--------------------------------------------------------------
このようにテスト実施に際して前提とした条件がありますが、それらはシステムの動作には無関係であり、テスト結果に影響を与えることはありません。
--------------------------------------------------------------

3.2.実施するテストの内容（テスト内容/確認内容）
「確認内容」項目は、このテストが「何を確認することを目的としているか」分かるように記述します。
 ・「正常系」テストと「異常系」テストの区分を明示する。
テストでは、正常な使い方をしたケースだけでなく、例外的な使い方や誤った操作をしたケースについても、テスト項目に盛り込みます。
このとき、前者と後者の区別が明確になるような記述が重要です。具体的には、テスト仕様書を見ただけで、
・機能Aの正常な使い方・操作を確認するテスト項目
・機能Aの誤った使い方・操作を確認するテスト項目
が一目で理解できることが大切です。

3.3.テストを実施するためのシステムの操作手順（テスト手順/操作手順）
システムの操作手順は、具体的な操作イメージをつかめるように記述します。操作手順が長く複雑になる場合は、簡潔にまとめましょう。

3.4.テストの実行結果（テスト結果/確認結果）
OK → 問題なし
NG → 問題あり・修正必要／問題未解決・修正必要
「確認内容」では、「テスト結果」だけでなく、「バグがあって正しく動作しなかったときの状況」についても同時に記述します。
ただし、状況の概要は簡潔に記述し、詳細は添付資料に別途まとめる。

3.５..障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号）
テスト実施期間中は、発生した障害を管理して、障害の詳細を開発担当チームに報告します。このため、テスト項目ごとに「障害報告票番号」の記述が必要となります。
しかし、顧客に提出する版では「障害報告票番号」を削除します。なぜなら、開発チーム内部で活用する情報があると分かりにくくなるからです。
顧客に提出するテスト仕様書には、顧客がテスト結果を確認するために必要な情報だけを記述しましょう。

3.6.テストを実施した年月日（実施日）

3.7.テストを実行した担当者(実施者 )

以上ですが、また気づいた点があったら補足していきます。