テストの名前

インフラのテスト計画を開発にあわせるのはそもそもムリがあるよ。
結合とか単体とか。

だって、開発のほうからインフラのほうにきたヤツってみんな、戸惑ってるよ。

バグ抽出率、みたいな概念がテスト計画書に残ってたりするけど、こんな項目どうすんだよって。インフラで。

オイラの知ってる範囲では、インフラ向けのびしっとしたテスト仕様書（兼結果報告書）のフォーマットを見たことがない。
だから、現場現場で、そこに残っている開発の香りが残っているテスト仕様書のフォーマットをいつも使っている。

インフラのテストがなんかうまくいかないのはフォーマットが整備されていないせいだ、というのもあると思う。

あと、なんつーか、「歴史」だよね。インフラのテストってこなれてないよ。

たとえばハードとかＯＳとかパッケージのミドルとかで、テストフェーズで致命的なバグを見つけたら、どうすんの？　メーカーと交渉して改修してもらえるわきゃねーだろ！
んなもんテストフェーズで見つけてちゃ間に合わねーだろうが。だって、その頃はもう、発注してんだから。もうその流れは止められねーだろって。

つまり、ね。インフラの「単体テスト」ってのは、メーカーが終わらせている、と思わなければならない。客も、その製品を購入するからにはその覚悟でいなければならない。

で、真の意味でのインフラのテストなんてさ、ゼッタイ設計段階で終わらせてなきゃいかんよ。テストは、ホントに、演技というかね。。
インフラに限っていえば、テストで問題が噴出する、という状況がおかしい。
だから、インフラのプロマネは、考えなきゃ。スケジュールを。