テスト工程の成果物作成要領を記す。テスト仕様書には、テスト情報とテスト管理情報を記載する。・テスト情報テストの内容とテスト実行結果を記す。・テストケース・テストケースを洗い出す・画面の操作や実行手順を具体的な業務の順序に沿って洗い出す。・ユーザ要望の操作パターンだけでなく、システム的に実行可能な全てのパターンを洗い出す。・ただし、時間(コスト)との兼ね合いで、業務上発生することがない例外パターンについてはモンキーテストで検証するが、テストケースの細分化に多くの時間は費やさない等の工夫も必要。・論理的にパターンを洗い出す(デシジョンテーブル等で整理する)・データパターンは条件と動作の組み合わせで整理することができる。例)テーマパークのフリーパスを発券する。(不具合一覧の管理番号とステータス)不具合の詳細情報は不具合一覧に記載するが、テストケースを完了して良いかを判断するための情報として不具合の対応状況を記載する。・テスト管理情報テスト管理情報はテスト品質の妥当性確認と、テスト進捗状況の把握のために使用する。・テスト品質の妥当性確認テストの品質が妥当か否かを判断するために、1機能あたりのテストケース設定数を検証する。1機能あたりのテストケースを設定すると言っても、それぞれの機能は同じソースコード行数ではないので、1機能あたりのテストケース数を単純に比較することは誤った示唆を導き出してしまう恐れがある。複雑な機能と単純な機能では、1機能あたりのテストケース数に違いがあるのが当然で、複雑な機能の方がテストケース数は多くなる傾向がある。そのため、それぞれの機能の規模を考慮する必要がある。・1機能の規模の把握1機能あたりのテストケース設定数(=ケース密度)を検証するためにはまずそれぞれの機能の大きさを定量的に把握する必要がある。1機能の規模を把握する方法として、以下のような考え方がある。SLOCが多ければ、検証ポイントは増えるという仮説に基づいている。数式によってデータ計算して登録するIPAのソフトウェア開発データ白書では、SLOCのほかにFP(ファンクションポイント)を利用している。多くの時間を費やして設計した機能は、ソースコード量が多くなると見なす考え方。SLOCが最も一般的な考え方だが、パッケージ製品の場合はシステム開発時にSLOCを把握できないことがある。そのような場合に、機能の要素分解や設計の実績工数を用いることを検討する。・ケース密度の妥当性(テスト結果報告書に記載する)テスト仕様書にテストケース密度の情報は記載しなくてもよいが、テスト完了までに密度の分析は実施する。1機能あたりのケース数の妥当性は過去に同様または類似する機能のテストを実施していればその時の数値をひとつの参考情報として用いることを検討する。密度の差に客観的に説明しうる理由があるのかを確認する。・テスト進捗状況の把握テスト期間中にテストが終わるのか否かを把握するために、テストケースの完了状況と不具合の解消状況を把握する。テストデータテストデータの作成は効率性と実用性を備えなければいけない。・効率性:データ作成にかかる時間をできるだけ少なくする・実用性:テストデータを見ただけで何のデータかわかることこれを満たすために、例えば下記のようなデータにする。上記のデータは、Excelのオートフィル機能を使って簡単に連番のバリエーションを増やすことができる。Excelやテキストエディタのマクロを利用して極力手間をかけずにデータを作成することを推奨する。Selenium、Appium、QTP等の自動化ツールを利用するか、カスタムツールを作成する。ツール利用に関する検討の詳細は基本設計工程の全体テスト計画を参照。結合テストエビデンス結合テストのエビデンスも、単体テスト同様にテスター以外の人間が見てもわかりやすいものである必要がある。画面から実行した結果を確認する場合は、画面の結果とデータベースのデータの両方がそろってはじめて十分なエビデンスと言える。データベースのデータをExcelシートに張り付けて保存する場合には、セルの形式が数字型だと数字の頭のゼロは消えてしまうため注意が必要。この事象はセルの形式を文字型にすれば回避できる。・不具合を管理する不具合対応のフローは、大まかには以下のようになる。→3修正(または対応不要のため完了)→再テスト→対応完了(不具合が解消しない場合は再度原因調査に戻る)上記の1から3に関する情報を不具合一覧に記録する。再テストの結果、不具合が解消されたことを確認してからクローズする。以下に、不具合の管理に必要な情報を記載する。System/バグ管理システム)を利用する不具合を管理するためには、情報を記録するためのツールが必要になる。System/バグ管理システム)が普及している。代表的なツールとしては、JiraやRedmineがある。従来のExcelの管理表よりもBTSが優れている点の例をあげる。専用のアプリケーションを個々人の端末に用意する必要がない。個々人が自分専用のViewを作成できるため、自分に必要な情報を抽出することが容易である。他の人もその影響を受けるため、都度表示設定を変更する手間がかかる。・拠点が異なるとFileServerのアクセス権がそれぞれ異なるなどの理由で共通のExcelファイルにアクセスできない場合があるが、BTSを利用すればプロジェクト内に限定したアクセス権限を設定できる。FileServerの権限設定は全社レベルで設定していることが多く、これに比べるとBTSで権限設定をする方が影響範囲が狭く容易。用途に応じた形式のViewを用いることでチケット駆動開発が用意になる。・BTSのデメリットを克服するBTSには優れている点がある一方で、BTSにはデメリットもある。開発メンバーが不便な経験をすることになる。従来のExcel管理に比べて、BTSは情報入力の手間が増えるという負の面がある。Excelはデータの編集に関しては非常によく出来たツールであり、WEBブラウザからデータを入力するBTSはExcelに比べるとユーザビリティは低い。この問題を克服するために、入力機能のカスタマイズに関する自由度が高いBTSを選択する。(すでに利便性の高いプラグインが存在しているとなお良い)例えば、JiraやRedmineはREST-APIが公開されており、これを利用することで、ExcelファイルやCSVファイルでチケットを一括更新することができる。テスト報告書に記載する情報の観点を以下に記す。テスト終了基準の中で未達成の事項がないか記載する。未達成の事項がある場合は残課題対応の予定を記載する。問題点は端的に記載し、詳細は後述のパートに記載する。・すべてのテストケースの検証が完了しているか。・完了していない場合はその理由は何か。・すべての不具合が解消しているか。・解消していない場合は、個別にその内容を報告する。・未解消の不具合が原因で総合テストの開始に影響が出ないか。・テストケースの設定漏れはないか。(全機能・非機能の要素を対象にしているか)・設定したテストケースの密度は適切か。(テストケース密度が荒すぎないか)・テストケース密度に異常値(密度が低すぎる)がある場合、その理由は何か。・テストケース密度が低い機能に対して追加のテストが必要ないか。多すぎる機能、少なすぎる機能がないか。・件数の過多・過小が起きている機能について、追加のテストの必要はないか。リリースリハーサルを通してタイムチャートや手順の精度を向上させる。詳細設計工程の作成手順を参照。