私は理解したと思います。開発者テストレベルより上には、顧客テストレベルがあり、そのレベルでは、多くのバグを見つけているようです。
見つけたすべてのバグについて、停止し、テスト用の帽子を脱いで、繁殖用の帽子をかぶって、正確な繁殖戦略を理解する必要があります。次に、バグを文書化する必要があります。おそらく、バグ追跡システムに配置します。次に、テスト用の帽子をかぶる必要があります。その間に、あなたはあなたが取り組んでいたどんなセットアップも失い、あなたがどんなテスト計画をたどっていたとしてもあなたがどこにいたのかを見失いました。
さて、それが発生する必要がなかった場合、バグが非常に少ない場合は、テストをすぐに実行できますよね？
GUI駆動のテスト自動化がこの問題に役立つかどうかは疑わしいです。テストの記録と保守にはかなりの時間を費やします。これらの回帰テストは、投資を回収するのにかなりの時間がかかります。最初は、GUIを駆使した顧客向けテストの方がはるかに遅くなります。
したがって、（私が提出する）本当に役立つのは、開発活動から得られる/initial/コードの品質の向上です。マイクロテスト（元の意味では開発者テストまたはテスト駆動開発とも呼ばれます）は、これに本当に役立つ可能性があります。役立つもう1つのことは、ペアプログラミングです。
他の誰かとペアを組むことができないと仮定して、私はあなたのバグ追跡システムを調べるのに1時間を費やします。私は過去100の欠陥を見て、それらを根本的な原因に分類しようとします。「トレーニングの問題」は原因ではありませんが、「1つのエラーでオフ」が原因である可能性があります。
それらを分類してカウントしたら、スプレッドシートに入れて並べ替えます。最も頻繁に発生する根本的な原因は、最初に防止する根本的な原因です。あなたが本当に空想を得たいのなら、根本的な原因にそれが引き起こす痛みの量であるいくつかの数を掛けてください。（例：これらの100個のバグで、メニューに30個のタイプミスがあり、修正が簡単で、再現が難しいjavascriptエラーが10個ある場合は、最初にjavascriptの問題を修正することをお勧めします。）
これは、これらの根本原因のそれぞれに魔法の「修正」を適用できることを前提としていますが、一見の価値があります。例：IE6の透明なアイコンは、IE6が.pngファイルを簡単に処理できないことが原因である可能性があります。したがって、チェックイン時に.gifを拒否するバージョン管理トリガーを用意すると、問題が修正されます。
それがお役に立てば幸いです。