開発期間が短いプロジェクトでも、しっかり試験を行うには

プログラムの品質を高めるには、試験工程でどれだけ良いテストを行ったかも鍵になります。
試験工程で良いテストを行うには、良いテスト項目書が必要です。
開発期間の短いプロジェクトでは、試験工程になかなか時間を割けないものですが
それでも、短い時間で良いテスト項目書を作成する方法を……まずは自分のやってきたことを以下に纏めてみます。

時間がない時にまずやること

以下の作業を通し、テスト対象となるシステムを理解します。

  1. 要件定義を機能ごとに理解する
  2. 業務フローを、要件定義を意識しながら理解する
  3. 設計書を、要件定義・業務フローを意識しながら理解する
  4. 画面項目を、要件定義・業務フロー・設計書を意識しながら理解する
  5. DB項目を、要件定義・業務フロー・設計書・画面定義を意識しながら理解する

2.の業務フローの理解の時点で要件定義と合わない箇所を見つけたとすると、
プログラムにはほぼおちていないこととなり、大変大きな問題となるのでここでは割愛します。

3.~5. の段階で、まず設計書や画面項目、DB項目記載事項に要件定義や業務フローと合わない矛盾を見つけることができます。
ここで想定しているプロジェクトの開発期間では、大抵これらはプログラムを作りながら変更されていくものなので、
この時点ではプログラムまたは設計書および画面やDB項目のどちらに不具合があるのか、テスターにはわからないことが多いのですが
仕様管理者や該当箇所の開発担当に状況を伝え、次に進みます。
- Redmine等不具合を手軽に管理できるツールでチケット起票だけはしておくと便利です。
- 指摘誤りは担当者がバサバサ切ってくれるので、気になることはすべて起票しておきます。

テスト項目書の作り方

システムを理解したら、早速テスト項目書を作成します。
テスト項目書は、件数の増減に耐えられるよう「シナリオ」「データ」「試験項目書」の3つのシートに分けておきます。
「シナリオ」「データ」を作成したら、「試験項目書」からそれぞれを参照していく形式です。

  • シナリオをつくる

業務フローを書き出し、まずは要件定義や設計書で定義されている仕様と画面の動きが合っているかどうかを確認するシートです。
仕様的な不具合を、これを作成している間に洗い出すことが目的です。

1. テストの対象となる業務フローを、機能ごとにすべて書き出す
2. 業務フローに対し、該当する要件定義・設計書の項目番号を記載する
3. 要件定義または設計書側に、業務フローに対応していない箇所があるかどうかを確認する
4. 業務フロー側に、要件定義または設計書側に対応していない箇所があるかどうかを確認する
5. 3.または4.にて対応していない箇所を見つけた場合は、シナリオに適宜追加しどちらが対応していないかをメモしておく

試験対象となる業務フローが、要件定義や設計書に紐付きすべてが記載されたはずです。
5.で追加されたシナリオについては、場合によっては仕様管理者や開発担当に報告しRedmine等の管理ツールがある場合は、まずは不具合として起票しておきます。

  • データをつくる

シナリオに記載された業務フローに対し、考えられるすべてのデータの入力パターンを別表として作成、各パターンにデータパターン番号を振っておきます。
データの作成は、以下の基本パターン別から作り出すとスムーズですが、まずはシナリオ作成時に一通りチェックしている要件定義・設計書側からみたデータを作成します。
シナリオでは、各ケースで必要なデータ番号を紐付けておきます。

1. 初期表示・再表示
2. 必須項目
3. 条件付き必須
4. 境界値
5. データ数
6. その他(テスト対象となる要件定義・仕様から適宜追加)

また、これらは画面側からみたデータパターンですが、次にDB項目定義側からみたデータパターンも作成しておきます。
DB定義側との齟齬を洗い出すことが目的です。

  • 試験項目書をつくる

作成した「シナリオ」や「データパターン」を参照先として、以下の観点ごとに試験項目書のケースを作成していきます

1. ログインユーザの権限別
2. 機能別
3. 正常系・異常系
4. 起動時引数別
5. その他(テスト対象となる要件定義・仕様から適宜追加)

期待結果や操作手順・テストデータ等、試験項目書には幾つか項目がありますが、基本的にはそこには「シナリオ」や「データ」の該当する項目番号を参照するよう記載するイメージです。

試験を進めながら、試験項目書不備(期待結果誤りや考慮漏れ)が発生した場合は、参照先である「シナリオ」や「データ」を修正します。

試験を行うために必要な仕様やデータに関する知識はそれらのシートに纏められているので、あとから再確認する際や他のテスターに引き継ぐ場合に便利です。

また「試験項目書」シートでは、試験件数(総件数・ステータス別件数・合格件数・不具合件数)や試験結果および試験日を、品質管理として集計しやすいよう配置する工夫が必要です。
このシートを、試験結果報告用に流用できるよう作成しておくのです。

以上が、時間がないときによく作っていたテスト項目書作成の流れですが、「シナリオ」さえできてしまえば、あとはExcelを駆使すればすぐ出来ます。
もっと時間があれば、あれもこれも……と悔しい思いをしたことは何度もありますが、
まずはざっと、試験対象の要件や仕様をおとすことなく試験するには上記の方法がとてもやりやすいものでした。

また機会があれば作ってみたいです。