こんにちは、Hです。
今回はテスト観点表からのテストの洗い出しについて紹介したいと思います。
このテスト観点表ですが、現在の現場では結合テストといわれるフェーズで利用しています。
結合テストでは画面、機能のモジュールをそれぞれWebアプリケーションとしてデプロイして実施します。
主な確認内容は各画面ごとの単体動作確認、機能同士を結合させて実施するシナリオ確認です。
以下がテスト観点表の見本です。
大きく以下の観点で構成されています。
■テスト観点
1.チェック・変換観点
2.データ観点
3.画面観点
4.機能観点(オンライン)
5.機能観点(バッチ)
6.セキュリティ
7.競合
8.性能観点
9.シナリオ観点
10.運用観点
11.ノンデグ観点
■テスト観点の分類
・1-5は各機能ごとの機能要求に対するテストを実施します。
・6-8および10は機能ではなく、非機能要求に対するテストを実施します。
・9はその後に続くステージング環境でのテストを想定したプレテストです。
・11は改修機能に対するノンデグテストを実施します。
私たちの現場ではまず仕様書を作るうえでベースとなる観点とそれに紐づくパターンを洗い出します。
例えばチェック観点であれば機能要求としてどのようなチェック（入力チェック、業務チェック）を行っているか、また対象の項目は何かを洗い出しします。
この洗い出したものをマトリクスなり、テスト仕様書になりに落とし込んでいきます。
実際にお客様とレビューをするときに観点も何も無く、テスト仕様書をレビューしてしまうと、そもそもこのテストケースでテストすべき内容や機能要求に関するテストが実施できているのかなど確認が難しくなってしまいます。また時間をいくらかけてもレビューが終わりに近づきません。
観点で洗い出すべきパターンは同じシステムで利用しているうちに大体パターン化できてきます。この機能だとAとBのパターンを実施すればよいなとか、前のプロジェクトではこの観点がもれていて障害につながったから元の観点のテンプレートに追加しておこうとか、品質向上の活動にもつながっています。
何よりも観点を共有しておくことで設計やレビュー、会議などでの共通認識が顧客含めてチーム内に出来あがることが大切です。
次回はテスト仕様書に落とすときのポイントやエビデンスの取得ルールなどについて紹介したいと思います。
