テストですべてのバグはつぶせない
Finding bugs / juhansonin
ダイクストラの有名な言葉に
“テストでバグがあることをは示せるが、バグがないことは証明できない”
というのがあります。
そもそもシステムテストでバグを修正してソフト品質を何とかしようとするその姿勢からして間違っているのはわかっているのですが、いざソフト開発も終盤になると様々なプレッシャーを受けるし、投入できる人員,時間も底をついているので、結局システムテストでなんとかソフト品質を作り込むことになってしまいます。
“テストですべてのバグはつぶせない”ので、バグを潰すために無限大のテスト工数を投入することはできません。程度の差はあるにしても、どのソフトにも潜在的なバグを残したままテストを終了する限界点が存在します。経済的に決まる限界点は、「残ったバグを検出してつぶす費用」と「残ったバグによる市場品質ロスの対応費用」のバランスが取れるところがその限界点となります。この点が「バグを潰そうにも潰せなくなる」ポイントなのです。
つまり、ソフトウェアのバグをつぶす費用を安く上げることができる企業（つまりテストのパフォーマンスの高い企業）のほうが、製品に含まれる残存バグが少ないことになります。ソフトウェア製品の品質を高めるには、いかに安い費用でバグをつぶすかという戦略が重要なのです。稚拙なテスト戦略でソフト開発をしている企業は市場で発生するバグで苦しむことになります。
効率的なテストを行うために取られる戦略は開発しているソフトウェアの種類によって様々ですが、以下の様な観点で自分たちの組織にフィットしたテストプロセスをデザインしていきましょう。
- バグ検出効率の高い工程にテストリソースを投入する： 終盤のシステムテストより、前段の単体・結合テストの方がバグの検出率は高くなります。 開発の前段にテストリソースを投入しましょう。
- バグの追跡管理を行う： 作成された成果物は必ずテストを行い、検出したバグの追跡管理を行います。バグは素早く修正します。修正されずに放置される時間が長くなればなるほど、修正にかかる時間、コストが級数的に増大します。
- 大規模なテストより、短いイテレーション毎のテストをする： 大規模ソフトをバグ密度が高いままシステムテストで評価するのは自殺行為です。検出したバグの追跡だけでテスト工数が消費されてしまします。短いイテレーションに分割してテストを実施しましょう。
- テストの自動化をすすめる： いきなり全てのテストケースを自動化するのは無謀ですが、自動化できるテストケースから徐々に自動テストの範囲を広げていきましょう。
