JSTQB (日本ソフトウェアテスト資格認定委員会)が定める。

1. テストは「欠陥があること」しか示せない

テストを何百回やっても、どんなに厳しいテストにパスしても、「このソフトウェアにはバグかありません」と言い切ることはできません。他のテストパターンに変えたらバグが発覚するかもしれないからです。テストの結果から言えることは、バグを検出した場合に「欠陥がある」ということだけなのです。

2. 全数テストは不可能

全てのテストパターンを実行することは不可能です。例えば、自動販売機のお釣りを計算するプログラムで、120円のジュースを売る場合を考えてみます。入ってくる硬貨のパターンは、100円が1枚と10円が2枚だけとは限りません。パターンは限られているとはいえ様々な入金ケースがあり、それら全てテストすることは不可能です。

3. 初期テストが重要

ソフトウェア開発では設計段階やコーディングが始まったばかりの初期の段階で不具合を見つけることができれば修正するのは簡単です。ところが不具合が発覚するのが後の行程になると、作る・設計・テストとやり直さないといけない段階が多くなり、後戻りの工数が大きくなってしまいます。開発の早い段階でテストを行って不具合を潰しておくことが重要なのです。

4. 欠陥の偏在

ソフトウェアの欠陥は広い範囲に平均して潜在するものではありません。特定の部分に集中していることが多く、設計が甘いモジュール、複雑なインターフェース、スキルが低いメンバーがコーディングしたプログラム、などに集中しているものなのです。

特定のモジュールを一人のプログラマ個人に任せっぱなしにすると、エラー処理が甘くてそのモジュールで不具合が頻発するということもあり得ます。個人を責めるのはよくないですが、欠陥を探すときは作者を意識することも必要です。

5. 殺虫剤のパラドックス

同じ殺虫剤をずっと使い続けていると、だんだん効かなくなってしまいます。耐性を持つものが出てきてそれ以降はその殺虫剤は効果がなくなってしまうのです。虫も進化するのでしょう。

これと同じことがソフトウェアのテストにも当てはまります。同じテストをなんども繰り返すとそのテストでは新しいバグを見つけられなくなります。これは同様のバグが作り込まれることがなくなるためです。これを「殺虫剤のパラドックス」と呼びます。ソフトウェアテストでは殺虫剤と同じように新しい内容のテストを常に作っていく必要があるのです。

6.テストは条件次第

金融機関のシステムは正確に計算されセキュリティ性が高いことが必須です。一方、ゲームのソフトウェアは画像が止まることなくサクサク動かなくては売れません。 テストもソフトウェアの種類によって観点を変えておこなう必要があります。ソフトウェアの条件次第でテストは変わるのです。

7.「バグゼロ」の落とし穴

そのバグを回避するために大修正をしてバグゼロを実現しましたが、全体の処理速度が30%低下してしまいました。はたしてその修正は本当に必要だったのでしょうか。バグゼロが必ずしもベストではない場合もあることを意識しましょう。