1. 果たして完璧なテストは実現出来るのか?

　

費用対効果の問題
システムの品質の信頼性を高めるためには、出来るだけ細かい粒度で、かつ、出来るだけ広い対象範囲で、テスト計画を立案し、またその項目を全て実施することになります。しかし、実際には、得られる利益に見合う範囲でしかテストへのコストは掛けられないものです。

時間が経過しなければ発見出来ない性質の問題
また、テストの際に特に技術的に実施が困難なものが、時間的経過によって発生する不具合の検証です。

(例)
　　*長期間の連続稼動で発生する劣化
　　　極小さいスタックが破棄されずに残っていて、僅かずつ肥大化してゆき、悪影響を及ぼす例
　　*一定日数後に起きる問題
　　　一時的にリダイレクトさせるサブサイトのSSLの証明書だけ有効期限が切れ、データの部分欠落が起き、ユーザー情報が破壊された

テスト計画はイマジネーション
さらに上記から気付かれる方も多いかと思いますが、テスト計画立案では、例外的な事象の発生をどれだけ想定出来るのかという、ひらめき、つまり、創造性が問われます。

(例)
　　*想定外のユーザ動態によって起きる問題
　　　局所的なページアクセス殺到、UI上のミスリード
　　*オペレーション上の人災
　　手順違い、勘違い、悪意等

完璧なテストは至難
このように考えると、全てを網羅する完璧なテストというものが、いかに難しいかご理解頂けたかと思います。

また、実際にテストに携わる方々の間では、100％保証のテストなど不可能ということは、既に暗黙の了解となっているかと思います。

不完全テスト下での品質管理
リリース前のテストで、品質を完全に保証出来ないのならば、どのようにシステムの品質をマネジメントしてゆくのか？

まず、重要なことは、リリース前テストで品質を絶対的に保証することは不可能という現実を、暗黙の了解では無く、組織の中でのコンセンサスとすることです。テストへの過信や、品質保証の虚構性を再考しましょう。

そして、障害の不可避を前提にして、リリース後にも常時モニタリングテストを行い、障害発生の迅速な発見と切り分けを可能にしてサービス停止時間を出来るだけ短縮するという、倒れないシステムよりも、倒れても直ぐに起き上がれるシステムの構築を考えましょう。