組み合わせテストを教えてもらった(3)

全3回の、第3回。

テストの組み上げ方

組み上げ方はテスト戦略として、どんなバグを見つけたいか、何をする期間か、どんな人がテストをするか、対象についての知識がどれくらいあるかなどによって、使い分ける。

増加/非増加

増加

低いレベルから作り始めて、レベルを上げながらどんどん増やしていく。

非増加

高いレベルから作り始める。シナリオテストを行うことが多い。

トップダウン/ボトムアップ

トップダウン

入力を受け付けるところからテストする。

ボトムアップ

入力位置は関係なくモジュール毎にテストする。

トップダウンの方が楽そうなのにボトムアップでテストするのは

すべてのモジュールがトップに向かうツリー構造であれば、トップダウンで網羅しやすいけど、それ以外の場合には漏れが発生しやすいから。

アジャイルの場合

組み合わせをあとから付け足す方法論。
Sprint毎に、ユーザーストーリーに対して最短のパスを開発する(テストも含まれる)。

• 事前設計は当然する。実施がインクリメンタルなだけ。
• テストケースが減る訳じゃない。

バグを予測できないものはテストではない

テストはエラーを発見したら、成功。そうでなければ失敗。

各テストフェーズの完了基準(参考：マイヤーズ)

0. 実施期間の終了によってテストを完了とする

1.ある網羅基準について満たしたテストをすべて実施して完了とする

○○技法の△△基準で網羅したテストを、すべて実施した。

2.設定したエラー件数の発見によって完了とする

そのフェーズでどんなエラーが何件あるか見積もり、その件数分エラーを発見したら完了とする。

• フェーズ毎にエラーの件数は違う

テストレベルが上がるにつれて減るべきエラーや、テストレベルが高くないと出ないエラーがあるはず。
例：仕様書を読み違えた、論理が反対になっていた、エラー処理がなかった、マルチスレッド考慮漏れ、etc..

フェーズ	エラーA	エラーB	エラーC
単体	100	0	0
統合	10	20	50
システム	0	10	0

• 件数での見積もりができないとだめ

「見積もりエラー数 / テストケース数が高いところは、優先度が高い」と言える。
→件数でないと困る。

3.エラー件数の発生具合によって完了とする

プロダクト、プロジェクトによって適したグラフがちがうから、戦略時に決めておく。

• 要望に応えるには

検出するバグの総量は面積。

• 【余談】TDD

まとめとかいろいろ

有則を網羅することは重要

自分が思っているデシジョンテーブルと、お客さんが思っているデシジョンテーブルが同じであることが重要。
→確認すべき

現実的なのは2

3にも挑戦はできるし、意味のある値をとることはできるが、完了はできない。
→傾向を測ることしかできない。

(2・3で)エラー件数に届かない

• テスト戦略が間違っている(品質が良い場合もここに含まれる)
• テスト設計が間違っている
• テスト実施者が設計通りに実施していない

品質の大きさのようなもの

• エラーは不具合モードで分けるより品質で分ける方が有用っぽい(byきょんさん)
• 機能性が大きくて使用性が小さいみたいな表現ができそう