ソフトウェアの検査（ソフトウェアに限らない話でもありますが）で第三者による検査（納品受け入れ・検収検査など）の場合は、基本全項目検査になるわけですが、開発側（納入側）の最終システム検査なども一応は全項目検査のはずです。
現実では全項目を最後に一回やるのさえ難しい状況というのは結構あるため、差分検査になることが多いかもしれません。
頻繁にサービスアップデートを繰り返すようなネットサービス系のシステムなどでは、その機能の豊富さもあいまって検査項目数が爆発していることが多いので、むしろ基本差分検査になっているでしょう。
そしてよくあるの事故は、検査項目の選定に失敗して、検査漏れが生じて、忌まわしきマーフィーの法則に従いその漏れた検査項目にあたる機能が壊れていたという類でしょう。ネットワークゲームでは日常茶飯事的にも見受けられます。
こういう業界では、繁忙のあまり工学的手法などをとっている暇さえないでしょうし基本先手のリスク削減よりビジネス機会の確保（機能のサービスイン）が優先されます。確かに行け行けドンドンな状況ならそういう判断もありです。
ただ、その結果生じる損害の予測をしておいてあえてリスクを無視するならまだしも、予測もせず、そのため低コストで対策も講じることが出来るにも関わらず事態が生じて思いのほか大きい損害にあわてて「想定外の事態が起こった」と言っても多くの場合は通用しないわけです。
例えば、よく検査の管理のために作る表として以下のようなものがあります。本当に骨格だけのものですけれど。
テストケースと要件（要求事項）の対応表ですね。
これとは別に要件とそれの実現に関わるユニットとの対応表というのも考えられます。作っているところでは作られているのではないでしょうか？
これを組み合わせれば、
こんな表が作れます。この表を見ればどのユニットに変更があった場合、どのテストケースのテストをしないとまずいかがすぐ分かります。
構成管理（変更管理）と検査プロセスを安上がりに繋ぐツールと見なせるでしょう。
コードの変更に対してユニットとテストケースの対照表があれば、やる必要が少ないテストがすぐ分かる。例えばユニットＡに変更があった場合は、テストケースの１と３以外はやらなくても良い可能性が高いわけです。
厳密には変更の結果の伝播がどうなっているかで変わるので１と３以外は必要ないとは言えないですけれど、ざっくりとテスト工数を見積もったりするには使える。そこらへんの話は、また機会があったら。
＜つづく＞