引き続きテストの話題
構築したシステム自体のテストに限って言えば、一般的にはテストケースを作成しそれにしたがってテストプログラムや作業内容を詳細化して実行するというものだと思います。
これは当たり前の話ですが、テストプログラムやテストの作業内容というのは極限まで無駄なものをそぎ落としてシンプルにまとめておく必要があります。
なぜなら、テストプログラムが複雑になるとそのテストプログラム自体にバグがないかを確認する必要が出てくるからです。
こうなるとテストプログラムのテストプログラムが必要になり、そのまたテストプログラムが・・・ときりがなくなってしまいます。
ですので、テストプログラムはその対象のみをテストする極めてシンプルなもの（単体レベルで言えば対象のプログラムを実行するのみなど）にし、パターンを変えて別のテストプログラムを作成するというような構成をとっておいたほうが無難です。
極端な例を出すと
テスト対象プログラム
if ($a == 1) {
// 何らかの処理
}
テストプログラム
if ($a == 1) {
// 何らかの処理
}
上記のテスト対象プログラムの条件式が正しく動作するかどうかをテストプログラムによりテストします。
この条件式は、テストプログラムによりその正しさを証明できます。（そのためのテストプログラムです）
ですがテストプログラム内の同じ条件式はどこでその正しさを証明するのでしょうか？
これは、証明のしようがないわけです。
（もちろんそのためにさらに別のテストプログラムを書くというのであれば別ですが本筋から外れます）
テスト対象プログラムが正しい事が証明されたんだから、テストプログラムも正しいというのは証明の順序が逆になりますし。
テストプログラムが絶対的に正しくて初めてテスト対象が正しいかどうかを判断できる下地ができるわけです。
テストに必要な何らかの作業内容も同じです。
複雑な作業内容はミスが多くなりやすいですし、そもそもその作業がテストになる得るのかどうかをぱっと判断できないと作業者も多くの時間を費やす事になってしまいます。
（この結果になればOKだからと作業がシステムに与える影響も理解せずにテストする事は意味がありません）
複雑なシステムを問題ないかどうかを確認するには、シンプルなテストケースを一つずつ丁寧に作りそれをシンプルな内容でまとめて作業を繰り返す。
地味な作業ですがリリース後の品質を保証するためには極めて重要な作業となのです。
テスト実行班が出してくるテストケースは膨大で見てるだけでウンザリするんですがね・・・。