 |
|
|
| 前のページ 1 2 3 次のページ
|
|
| 試験内容（テストパターン）
|
図4は、テストシナリオに対する詳細の試験内容を定義したものです。
図4：結合テスト仕様書のテストパターン （画像をクリックすると別ウィンドウに拡大図を表示します）
まず試験準備として、どのようなテストデータを用意するかを定義します。そしてテストシナリオにそって、どのようなテストを行い（試験実施方法欄）、どのようなことを確認するか（確認する内容欄）の詳細を定義します。
そして、これらのテストパターンを実施した結果を図4の右端の確認欄に記述します。
|
| テストデータ
|
図5は、先ほど解説した試験準備でセットしておくべきテストデータの定義フォームです。
図5：結合テスト仕様書のテストデータ （画像をクリックすると別ウィンドウに拡大図を表示します）
あらかじめ部門マスタや社員マスタなどテストに関連するマスタデータをいくつかのパターンで用意しておくことにより、実際のテスト作業の効率があがります。
規模の大きなシステムでは、マスタデータの全情報を記載するのは大変なので、ここではテストパターンに影響のありそうな項目のみを抜き出して記述しています。
また必要に応じて、テストの中で入力するトランザクションデータも定義しておきます。この例では、受注入力で入力すべきトランザクションデータをパターン化して定義しています。
|
| テスト結果データ
|
バッチ処理など、テストデータ（INPUT）とテスト結果データ（OUTPUT）が定義しやすい場合は、テスト結果データも定義します。
図6：テストデータとテスト結果データ
|
|
テスト工数と品質のトレードオフ
一般に、範囲が限定できるモジュールや機能の単体テストは網羅型テストが可能です。しかし、複数の機能を組み合わせた結合テストとなると、条件の組み合せが乗算で膨れあがり、その全パターンを網羅的にテストするのが困難になってきます。
そのときに大切なのがシナリオの設定です。基本的に業務想定にあるシナリオは、すべてのパターンを確認する必要があるのですが、ほかのパターンですでに実証されてテスト内容が重複するような部分は省略します。
同じようなテスト工数と品質のトレードオフは、テスト仕様書の作成においてもいえます。
例えば複雑な業務パターンがいくつもあるケースにおいて、テストデータやテスト結果データをすべて書きだすのは、膨大な工数がかかり現実的ではありません。品質のトレードオフというと「だからソフト業界は」などと目くじらを立てる人がいますが、必要な品質をあきらめるというわけではありません。いたずらに網羅性、綿密性を追求するのではなく、ここまでやれば十分というゴールを定めてテストする姿勢が大切なのです。
|
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。
常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。
国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。
|
|
|
|
|
|
