テストの観点表を用いてテストの観点レビューを行う | 組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題

テストの観点表を用いてテストの観点レビューを行う

テスト設計ではテスト項目を決定し、テスト項目ごとにテスト対象とする要因(パラメータ)とそれらがとりうる値を洗い出し、それをもとにテストケースを作成します。要因と値はテストの観点分析で決定します。

 

テストの観点分析は次の手順で行ないます。

 

①.機能仕様書をもとにそこに書かれていることに対応するテスト項目を決定する。
②.決定したテスト項目で必要な要因と値を洗い出す。
③.決定した要因と値をテストの観点表に記入する。
④.機能仕様書に書かれていることについて原則としてすべてをテスト項目とするまで①~③を繰り返す。
⑤.作成したテストの観点表をテストチーム内でレビューする。
⑥.開発チームとテストチームでテストの観点表をレビューする。

 

上の④で機能仕様書に書かれていることのすべてとありますが、もちろん書かれていないことについても検討を行ない、必要があればテスト項目にします。

 

上の⑥で開発チームを含めてレビューを行うのは、テストに開発チームの知見を反映させるためです。このことにより、テストはグレーボックステストとなります。

 

テストの観点表にはそこに記述されているテスト項目に対応する機能仕様書の記述を明記します。これはそのテスト項目が何を対象としてテストするかを明記するためです。またテスト対象の要因(パラメータ)と値および確認内容を記述します。

 

テストの観点表の例を次に示します。

 

 

記述はExcelに行ないます。各列の幅は25、表示のズームは80%です。この例では、仕様 リレー制御(センサー検知連動機能) 1. と2. がテスト対象の機能仕様書の記述です。テスト項目によっては機能仕様書の記述が表形式の場合もありますが、その場合は当該の表の画像を張り付けるようにします。監視状態、リレー使用種別、リレーのメーク時間が要因であり、それぞれの下に記述されているのが要因の取りうる値です。

 

値に色がついているのは同じ色の組み合わせのみ可能であること、つまり制約があることを意味しています。このテストの観点表では複雑な制約は表現できませんが、組み合わせに制約があることは表現できます。

 

次にテストの観点表の他の例を示します。

 

 

このテストの観点表で 34. WEBサービス・同時操作 は機能仕様書に記述がない項目です。WEBサービスで2人のユーザから同時にアクセスがあった時の動作を確認しています。こうした事項は機能仕様書に改めて明記されることがないのが普通ですが、テストの観点としては重要な確認項目です。

 

このようなテストの観点表を作成することにより、テスト仕様書を作成する前にテストの要因と値にテスト漏れがないかをレビューによってチェックすることができます。また開発チームと共同でレビューすることによって、システム構成上必要な組み合わせが漏れていないか、その逆にテストする必要のない組み合わせがあるかをチェックできます。

 

テストの観点レビューが完了したら、テストの観点表をもとにテスト設計書の作成を行なうことになります。