1996年12月発行のストラタス・ユーザー・グループ会報「VOSコーナー」コラムにおいて、効果的なプリプロダクションテストの実施について以下の所見を記した。発表から13年近く経った今もなお、その内容は有効である。
お客様に一つだけお願いできるとしたら（たった一つだけ！）、アプリケーションの新バージョンを本番環境に導入する前に、必ず負荷テストを実施してください。最近、機能テストは全て通過したアプリケーションが、本番環境の負荷に耐えられず導入直後に障害を起こすケースに何度も遭遇しています。
ご存知の通り、ソフトウェアは予測不能でテストが難しいものです。プログラムが毎秒10トランザクションで動作することを知っていても、毎秒100トランザクションで動作することを知っているのとは異なります。10の仮想回線（VC）で動作することを知っていても、1000の仮想回線（VC）で動作することを知っているのとは異なります。 私がこれまで目にしてきた事例では、いずれもラボやテスト環境では問題なく動作していたプログラムが、根本的なソフトウェアの欠陥や容量制限により本番環境で完全に機能不全に陥りました。一般的に私が関与するケースでは、その限界はアプリケーションではなくVOS（仮想オペレーティングシステム）内に存在していましたが、その原因がどこにあろうと、お客様への影響は変わりません。アプリケーションが本番環境で動作するかを知りたいのであれば、本番環境と同様の条件でテストしなければなりません。
長年にわたり、本番環境と同じ限界までソフトウェアをテストできない理由として、数多くの言い訳を聞いてきた。 私はそれらの言い訳を一切信じていません。本番環境のデータストリームやファイルをキャプチャしてテストに流用できます。良質・不良な入力をシミュレートする合成テスト生成器を構築できます。デバイス依存のインターフェースコードをバイパスし、サーバーに高速データストリームを供給することも可能です。テスト環境で100%動作させられなくとも、アプリケーションの90%をフル稼働させるための手法は数多く存在します。 問題を「本番環境のシミュレーション」と捉えるのをやめ、「可能な限り多くのコードを、可能な限り高速に実行させる」という視点に切り替えよう。システムを100%のCPU使用率まで追い込むことを忘れずに。そここそが「興味深い」問題が現れやすい領域なのだ。
アプリケーションソフトウェアを限界まで動作させることで、VOSも同様に鍛えられます。容量問題は本番環境ではなく、ラボ環境で発見されるでしょう。容量の限界がどこにあるのか、明確に把握できます。テストフェーズを終える頃には、アプリケーション導入が成功する確信が格段に高まっているはずです。上司も顧客も満足させられるでしょう。これらは十分な理由ではないでしょうか？