私は、1996 年 12 月の Stratus User Group ニュースレターの「VOS コーナー」のコラムで、効果的なプリプロダクションテストの実施について次のように述べています。 これらは、13 年近く経った現在でも関連性のある内容である。
もし私がお客様に一つ提案できるとすれば（一つだけお願いします！）、アプリケーションの新しいリリースを本番環境に置く前に、必ずストレステストを実施するようにしてください。私は最近、顧客がアプリケーションをデプロイして、すべての機能テストに合格したにもかかわらず、本番環境の負荷を処理できなかったために、本番環境に投入された後すぐに失敗したというような状況にいくつか関与してきました。
ご理解いただいていると思いますが、ソフトウェアは予測できないものであり、テストするのが難しいものです。プログラムが毎秒10トランザクションで動作することを知っているのと、毎秒100トランザクションで動作することを知っているのとでは同じではありません。また、10個の仮想回路で動作することを知っているのと、1000個の仮想回路で動作することを知っているのとでは同じではありません。私が見てきたケースでは、ラボやテスト環境ではプログラムは正常に動作していたが、本番環境ではソフトウェアの欠陥や容量制限のために悲惨な結果に終わってしまったということがあります。一般的に、私が関与した場合、その制限はアプリケーションではなく、VOS内にありましたが、それがどこにあるかに関係なく、あなたの顧客にも同じ影響があります。アプリケーションが本番で動作するかどうかを知りたいのであれば、本番であるかのようにテストしなければなりません。
私は何年にもわたって、本番と同じ限界までソフトウェアをテストできない理由について、多くの言い訳を聞いてきました。私はそのどれも信じていません。本番環境のデータストリームとファイルをキャプチャしてテストに使用することができます。良い入力と悪い入力をシミュレートするために、合成テストジェネレータを構築することができます。高速データストリームをサーバに供給するために、デバイスの影響を受けやすいインターフェースコードをバイパスすることができます。テストモードでは 100%動作させることができなくても、アプリケーションの 90%を完全に動作させるために、たくさんのトリックを使うことができます。問題を本番環境のシミュレーションと考えるのをやめて、単純にコードをできるだけ多く、できるだけ速く実行できるようにすることを考えてください。システムの CPU 使用率を 100% にするようにしてください。
アプリケーション・ソフトウェアを限界まで行使することで、VOSも行使していることになります。生産現場ではなく、ラボでキャパシティの問題を見つけることができます。何が、どこに容量の限界があるのかを知ることができます。アプリケーションのデプロイが成功するという確信を持って、テストフェーズを終了できます。上司や顧客を満足させることができます。これは良い理由ではないでしょうか？