2015/09のテスト勉強会レポート。
先月の勉強会に引き続き、ゆもつよメソッドの勉強。

マトリクスのチェック

前回作成したマトリクスに対して、仕様書等を参照しながら、作成したマトリクスに、試験が必要と思う所に○を付けていく。 (今回は時間の都合で圧縮の所まで○付け)

f:id:mokky14:20150924124030j:plain

重み付け等で差を付けたい場合は適宜記号を工夫する事。

試験項目作成

作成したマトリクスを元に、試験項目を作成する。

f:id:mokky14:20150914195026j:plain

表に記述する内容は以下の通り。

項目	記載する内容
機能名	中項目-小項目(内容が分かれば小項目のみでも)
テストタイプ	テストカテゴリの種類(ex.機能性、負荷テスト、パフォーマンステスト)
テストカテゴリ	テストカテゴリの各項目
仕様項目	テストでの確認観点
期待結果／確認内容	期待する結果、確認する内容等
パラメータ	テストで指定するパラメータ(上図では省略)

機能名～テストカテゴリはマトリクスに○を付けたものを抜き出して記載する。この各項目に対し、確認対象、確認する内容を記載していく。
試験項目と、マトリクス、仕様書を相互確認しながら作成する。マトリクスに不足があったりしたら、そちらも適宜修正する。

マトリクスの用途

ゆもつよメソッドのマトリクスは、システムテストのチェックに使用するために考えられたもの。

以下、自分の解釈。

単純に機能のIN/OUTだけに着目した試験だと、機能的に確認しておくべき試験が漏れてしまう事が懸念される。
そのため、ユーザシナリオでユーザにとって重要な機能を確認した上で、内部構造にも着目して試験観点を抽出する。
マトリクスの内容は、結合試験の内容と多少オーバラップしたものになるが、機能や処理パターンを網羅する事が目的ではない。「ユーザシナリオを提供する」ために必要な機能を試験観点として抽出する事が目的になる。

非機能観点の試験は、「ユーザシナリオを提供する」ために必要な機能を抽出した上で、その機能を多方面(性能、連続運転、ユーザビリティ、セキュリティ、等)の観点から検証するために実施する。

非機能観点は対象のプロダクトが変わっても流用できるものが多くなる。チームやプロダクトで育てていくと良い。