テストではバグがあることは示せるが、バグがないことは証明できない

（2008.5.13）
三菱東京ＵＦＪ銀の大規模移行作業でもATM障害が。
http://ntd.way-nifty.com/blog/2008/05/atm_72aa.html

（2004.3）
ITProより。２００４年１月に連発したシステム障害について。

統合ATMが陥った“テスト不足”の落とし穴〜負荷集中や計算値「思い込み」からテストケースが漏れる〜
http://itpro.nikkeibp.co.jp/members/SI/ITARTICLE/20040226/1/
ここに読者からのコメントが。
「テストが漏れた」と書かれているが、そもそも、設計時に想定されていないことをテストすることは不可能である。「テストが漏れた」のではなく、「システム設計時に想定していなかった」のである。GOTOレス設計で有名なダイクストラは「テストではバグがあることは示せるが、バグがないことは証明できない」ことを証明した。そもそも、テストでバグをたたき出そうとする姿勢が間違いなのである。などということは、品質管理の世界では「自明」なのだが、そもそも、そんなことをマスコミも、ベンダも言わないことが問題なのである。記者殿、こんな記事では勉強不足ですよ！

原因から見るに、テスト不足よりは設計ミスだったのが発端ですね。DB-READ時に各レコードをロックしたのはまずかった。ロックは常に悪いわけではないけど排他時間が長引くと他を待たせることになるので、それとの兼ね合いを検証してなかったんですね。
しかし「使用中状態が多い状態の負荷テスト」は普通にテスト段階で項目あげてもよかったんじゃないかなぁ？負荷試験ってそういうものでしょうに。極端に空きが少なくなるくらい負荷を増やせば試験段階で気付いたはず。
しかし記事では銀行側のレスポンスも低下したとあるので、試験では銀行側はすぐ返答してすぐ使用中状態が解放される前提しか考えなかったわけだ。

確かに記事ではテストが悪いとありますが、
設計時に想定されていないことをテストすることは不可能である。
ということも一理ありますね。