一般的なソフトウエアテスト手順を教えてください。

まず、気をつけたいのは「ソフトウェアのテスト」と「システムのテスト」は、イコールじゃない、というところだと思います。

現地のテスト系統で運用テスト後、本番データを本番系統へ移行し、本番系統でのテストはなく本稼働と思っていますが正しいでしょうか？

正しくないです。

テストというのは、ミスを検出するための手順だと考えれば、

• 本番系に、一部のプログラムの修正、もしくは、マスタの変更を適用しなかった
• 本番系は、ハード的に二重化されているが、その結線間違い
• 本番系のハードの初期不良

などなど、プログラムのバグ以外にも、間違いが混入する原因はいろいろあります。

最後の例など、あり得ないだろう、と思うでしょうが、

実体験として、ソフトを入れ替えなくても、CPU のボードを交換しただけで、

ソフトウェアの不具合が解消されたことがあります。

CE いわく、宇宙線で CPU やメモリのパターンの一部だけが破壊されることが稀にあるのだとか。

＃ けっこう長く、こんな仕事をやってますが、一回だけしか経験はありません。

テストの分類については、いろいろな側面があるので、分け方もいろいろありますが、

「状況に応じて」というよりは、考え方によって変わってくる、というふうに

とらえた方が良いと思います。

id:kentaro_jpn さんが聞かれている範囲では、手順は、そう大きく変わりません。

それぞれの手順の中で、どこまでしつこくテストをやるか、という密度については、

場面というか状況に応じて変わってくると思います。

問題があったら困る、というのは同じですが、

原発の制御システムと、携帯のゲームで、同じレベルのテストはできないです。

＃ 経済的な側面もありますけど。

以下、ちょっと細かい話です。

「単体テスト⇒結合テスト⇒システムテスト⇒運用テスト」

ちょっと古い教科書の分け方ですね。

「単体テスト」

ソースひとつをコンパイルしてできるモジュールを、スタブとドライバを用意して、

そのソースのミスを検出するテストです。

「結合テスト」

複数のモジュールをリンクしてできる、業務をこなすプロセスに対するテストです。

モジュール間で受け渡すパラメータの間違いなんかを検出します。

「システムテスト」

複数のプロセスを動かすテストです。

単独で動かすと正しく動くが、同時に動かすと駄目、とか、

開発環境では動作するが、実環境で動かない、というような問題を検出します。

「運用テスト」

実際に、運用に応じた使い方をして正しく使えるかどうかテストします。

業務上、同時に使えないと駄目な機能が、同時に使えない、とか、

夜間バッチが、夜中のうちに完了しないとか、

そういったような問題を検出します。

「古い」というのは、開発環境が変わるにつれ、意味が無くなってきたものがあるからです。

例えば、VB でフォームにコードを記述するような類では、

フォーム単体では、ほぼ、動作するように作られませんし、

スタブやドライバをいちいち用意していると、VB だと（見た目の）生産性が上がる、

という利点を消してしまいます。

でも、コードの断片が正しく動くかどうかの検証をせずに、いきなり結合テストをすると

問題が続出するので、かえって生産性が悪い、みたいなことがあるので、

JUnit みたいな仕組みができてくるわけです。

後、古い教科書では、テストをだれの責任でやるべきか、みたいな話は、あまり言及されてません。

どちらかというと、ベンダーの責任の範囲内で規定されている面が強いです。

でも、現実には、ベンダー任せだと、問題が多いこともあるので、

今どきの開発プロセスでは、ユーザがシステム開発に参画すべき、というのが主流です。