システム開発における「異常系テスト」は、「教科書通り」（＝学問:ソフトウェア工学）であれば、「システムテストフェーズ」で実施することになる（テキストによって微妙なユレあり）。

しかしながら「教科書通り」というのは、「理想的なウォーターフォール」である。

ここに「工数･時間の制限」と「開発体制の規模」を勘案する必要がある。現場は「理想的」な状況は ほとんどありえない。よって「テストフェーズ」をいかにミニマイズできるか、ということがいつも課題となる。

これに対して現状私は、「システムテスト」と「受入れテスト」を融合させている。ユーザーシナリオに予め沿ってシステムテストを設計すれば、受け入れテストを実施する必要はない、という私の経験上の考えを土台としている。

そもそも「学問」のうえで「システムテスト」と「受入れテスト」が分けられているのは、大元の考え方として「開発部隊とユーザー部隊が組織レベルで別である」という前提がある。
※ウォーターフォールモデルは、IBM社員が自社プロセスをベースに提唱。IBMはユーザーでは無いと思われるので。

しかし、昨今のWebサービスのようなプロダクトになると、開発部隊とユーザー部隊はむしろ一つでなければ開発スピードが出ないため一つの組織にまとまっている。harmoもそうである。よってシステムテストと受け入れテストは「１組織内で完結可能」となる。

したがって、理屈のうえでも、この2つのテストフェーズは融合できると判断している。

一方、融合すると、その「融合フェーズ」は、それだけテストケースボリュームは増してしまうので、余計なテストを取り除きたい。

そこで、昨今のテスト自動化ツールの進展から、画面上の「異常系テスト」（UXレベルでの異常系ケースは除く）は、自動化ツール上で再現できてしまうという事実に注目する。

とすると「異常系テスト」は、エンジニア主管の「結合テストフェーズ」に吸収させることが可能であり、「システムテスト」の外に出したほうが、開発全体として効率的である、という判断となる。