設計においては、入力データについてある前提を置いて条件分岐を作り込みます。
例えば、
・「支払い手段」が"1"の場合はクレジットカード払いであると判定する
・「契約日」が"2016/01/01"～"2016/12/31"かつ
「支払い回数」が"48"ならキャンペーン対象であると判定する
といった具合です。
しかし、この前提はもしかしたら間違っているかもしれません。
・一部だけ現金払いした場合の「支払い手段」は？
・「支払い回数」が後から変更された場合は？
・他システムから連携されるようなデータが存在したら？
・そもそも設計者が条件を勘違いしていたら？
…等、前提を間違うケースは色々と想定できます。
テストにおいては、このような設計の前提を疑うことが重要です。
総合試験（システムテスト）において、
以下のようにテストシナリオを作ることが重要です。
・実運用と同じ方法でデータを発生させる
設計者の勘違いによるミスはこれで発見することができる。
また、データ発生方法を考えることで、例外的なケースに気付くきっかけになる。
・システム固有の知識に精通している有識者の手を借りる
複雑なケースや例外的なケースは、一般論で導き出すのが困難な場合がある。
テスト対象のシステムに何年も携わっていないと気付かないケースもあるので、
テストの網羅性を高めるためにできる限り有識者の手を借りるべきである。
この手のミスをテストで完全に洗い出すことは困難ですが、意識するのとしないのとでは大きな違いがあります。
少なくとも、データの発生方法は実運用にできる限り近づけたいです。
