ソフトウェアテストの7原則

概要

テストは欠陥があることは示せるが、欠陥がないことは示せない

全数テストは不可能

早期テスト

欠陥の偏在

殺虫剤のパラドックス

テストは条件次第

「バグゼロ」の落とし穴

/icons/hr.icon

テストは欠陥があることは示せるが、欠陥がないことは示せない

テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはなりません。

単体テスト1ケースだけ通してこのプログラムは完璧ダァとか言い出したらヤバいよなぁ。そういうこと

「どんなバグも許さない」みたいな無茶な請負契約を結ぶとその時点で終わるよ

全数テストは不可能

関数が増えるほど入力パターンの組み合わせは爆発的に増える

普通に無理。

早期テスト

早めからテストする方が修正のコストが少なくて済む

欠陥の偏在

重大なバグはある特定のモジュールに偏って存在している

ソフトウェア版パレートの法則

約20%のテストで80%の重大なバグが発見される

重大なバグを発見するようなテストが効果の高いテストケースと言える

コアロジックに対して重点的テストするのがコスパが良い

殺虫剤のパラドックス

同じ殺虫剤だといずれ害虫は駆除できなくなる

同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる

バグがテストケースに対して耐性を持ってくるってイメージすると感じやすい

ただし、新しいバグを見つけられないというだけでデグレを検知するリグレッションテストとしての効果はずっと続く

テストを行う意義は新たなバグを見つけるというのもそうだけど、開発に伴ってデグレしていないかを保証するという側面も大きい

単体テストが充実していることで積極的なリファクタを行える

テストは条件次第

ここでいう条件とはプロダクトの周辺の環境全てを含んだ意味

一律のテストアプローチがすべてのソフトウェアに適用できるわけではないという現実を意味している

テストを仕様を左右するようなスコープ例

プロジェクト特性(ミッションクリティカルなど)

リスクの大きさ

ユーザーの期待値など

投下できる時間・リソース

技術的な問題

法的な問題

「バグゼロ」の落とし穴

バグゼロみたいな目標を掲げるのは一見良いことのように思えるけどむしろプロジェクトを破綻に追い込む要因になりうる

リソースの無駄遣いであったり、リリースが遅延することになったり、そもそも現実味がない目標で開発メンバーが疲弊することになる

バグゼロを目指すというよりはプロダクトの性質・使うユーザーなどを考慮してどこまでを許容するのか決定するのが良い

/icons/hr.icon