トレーサビリティのあるテスト項目と、その限界

テスト項目は、

・仕様書の内容Xテスト観点Xバラエティー

で規定される。たとえば、

画面設計書に
・受注検索・一覧画面
・受注詳細・入力画面
・商品検索・一覧画面
・商品詳細・入力画面
　　：
　　：
と画面があったとして、

画面のテスト観点として、
・初期入力画面
・項目入力チェック
　　選択　＝　選択できるか
　　複数選択＝　単一選択
　　　　　　　／複数選択
　　　　　　　／未入力
　　整数入力＝数字チェック
　　　　　　　境界値
　　　　　　　範囲外
　　　：
などとあった場合、

　受注検索・一覧画面X初期入力画面
　受注検索・一覧画面X（選択：選択できるか）
　　　　：
　受注詳細・入力画面X初期入力画面
　受注詳細・入力画面X（選択：選択できるか）
　　　　：

というように、

　　仕様書（画面）Xテスト観点

　の組み合わせとなる。もちろん、画面によっては、選択するものがない、入力するものがない等、テスト観点が該当しないものがあるので、これは行わない。

　また、境界値が２つ、３つある場合があるので、それはXバラエティとして、それぞれのケースを行うことになる。



　ここで、仕様書は、そこに書かれた機能を確認することになる。
　したがって、機能要件であることが多い。

　テスト観点は、テスト項目全般に関わること（非機能）になってくるため、
　　　　各種項目・画面等で守るべきこと
　　　　非機能要求
　などが、観点として挙げられることになってくる。



　よって、
　　　機能仕様X（守るべきこと＋非機能）
　に関しては、トレーサビリティが取れる。

　しかし、ここで問題となるのは、機能仕様の範囲だ。
　一般には、ビジネスモデルが機能仕様にあたるが、
　それだけだと、通信エラーのときの手順とかはどうなるの？
となる（通信エラーはビジネスじゃないだろう・・・）

　で、ここで問題になる。
　　　通信エラー
　　　ハードディスク障害
　などは、仕様書にかかれる。だから仕様書に書かれたとこだけ
調べればよいとなると、テスト範囲は狭まる。
　本来、通信エラー、ハードディスク障害はどこでも起きることなので、
テスト観点に含めて、すべての状況で確認すべきだ・・



　まあ、そこまでやるかどうかは別として、
　いいたいことは、
　ビジネスモデルをベースに機能を出し、

　　その機能Xテスト観点

　とやると、トレーサビリティは取れるが、ハードに依存した部分の障害（通信、メモリなど）が抜ける可能性が出てくる。

と、いうことだ。