無則の組合せテストの範囲
ソフトウェアテストの世界には「無則」や「有則」という言葉があります。
ここらへんの記事がわかりやすいでしょうか。記事の中では
>組み合わせによって出力に影響を及ぼす組み合わせを有則の組み合わせ
>無則のテストは、悪影響が無いことをテストする
と説明されています。「無則のテスト」は本当に無則であること（出力に影響がないこと）を証明するために実施するテストなので、言い換えると、意図しない有則が存在しないことを確認するテスト、と言えます。
ペアワイズテストや直交表の文脈では、無則の因子を規定のカバレッジで網羅的に組み合わせてテストケースを生み出します。その時には、どんな因子を組み合わせるかということについては考慮をしません。
ただ、経験がある人だとわかると思いますが、この因子とこの因子（とこの因子）の組合せってテストしておきたいよねーと「感じる」ことがあります。そのインスピレーションをテストに生かさない手はありません。（この、無則だけど有則の可能性が高いものを、暗黙の有則と呼んでいます。）
このインスピレーションを活かすテスト技法が経験ベースのテスト技法である探索的テストやエラー推測なのですが、この記事では、このインスピレーションがどんな場合に生まれるか、というのを思い付きで（つまり経験ベースで）あげてみようと思います。
ちなみに、経験ベースのテスト技法におけるインスピレーションは組み合わせに関するものだけではありません。念のため。
相互に影響がある「つくり」である。またはそう推察される
ホワイトボックス的に中身を知っていて、ブラックボックス的には無則だけれど実は有則であるケースです。
同じ内部リソースや外部インターフェースを共有する
特に内部リソースの共有は一つ目と似ていますね。外部インターフェースにおいて、衝突する場合は定義があることが多いため要件ベースのテストで実施されますが、並列動作する場合はテストしないこともあります。この並列動作は暗黙の有則になりえます。
出力に影響があることが多いが、特に規定がない因子の組合せ
文字だけだと何を言っているかわからないかもしれませんね。例えば、不揮発メモリの読み出しタイミングで、あるフィーチャーは電源ON直後なのだけれど、他のフィーチャーはトリガがかかった直後である、という仕様の場合です。この場合、後者のフィーチャーで電源ON直後に読み出しが行われていないかテストすることが有効だったりします。この例が無則組合せかというと結構微妙ですが、まぁ例だとおもって許してください。
おわり。