これまでに、ソフトウェアテストのさまざまな原則が生まれてきましたが、その中でももっとも重要で、多くのものに共通した考え方がソフトウェアテストの7原則です。
ここでは、ソフトウェアテストの7原則について解説します。
■原則１：テストは「欠陥がある」ことしか示せない
テストをおこなうことで、故障が起きれば、そのソフトウェアに欠陥があることは分かります。また、その原因を究明すれば、欠陥を取り除くことができます。
しかし、そもそもテストをしても故障が起きなかった場合には、どうでしょうか？
もしかしたら、本当にそのソフトウェアには、欠陥がなかったのかもしれません。
しかし、そのテストではたまたま故障が起きなかっただけかもしれません。
その他にも、テストケースに漏れがあって、たまたま故障が起きる値でテストがされなかっただけかもしれません。
このように、テストでは「故障が起きた = 欠陥がある」という証明はできても、「故障が起きない = 欠陥がない」は証明することができないのです。
■原則２：全数テストは不可能
「全数テスト」とは、ソフトウェアに入力する可能性のある、すべてのパターンをテストすることです。しかし、入力条件の全組み合わせをテストするのは、テストケースが膨大になりすぎるため、単純な機能レベルのテスト以外では非現実的です。
全数テストを考える際の、テストケースの数の増え方に関して、興味深い動画がありますので、こちらを参考にしてください。
参考動画：日本科学未来館 MIraikanChannelより
このように、全数テストを考えると、テスト実行を実行する以前に、テストケースを洗い出すだけでも膨大な時間がかかることが分かります。
そのため、実際のテストでは、ソフトウェアの性質、目的、使われ方、考えられるリスク、
などにより、重点的にテストをおこなう場所を絞ったり、優先順位をつけたりしてテストをおこないます。
■原則３：初期テスト
ソフトウェアの開発において、欠陥は作りこまないことが理想ですが、人が作っている以上は、完璧なソフトウェアを開発することは不可能です。もしも欠陥が紛れ込んでしまった場合には、欠陥が作り込まれた時期から欠陥が発見された時期の分だけ、その影響範囲は大きくなってしまいます。
そのため、いかに早く欠陥に気付けるかが重要となってきます。
そこで、ソフトウェア開発の早い段階からおこなわれるのが「初期テスト」です。
■原則４：欠陥の偏在
テストは、過去の欠陥分析や、直前のテスト結果などを参考に、欠陥位置を予測してテストの焦点を絞るのが良いとされています。それは、不具合があった場合に、それがソフトウェア全体に均等に存在することは少なく、むしろ特定のモジュールに集中していることが多いからです。
一説には、ソフトウェアで発見される欠陥の8割は、ソフトウェア全体の２割に集中しているともいわれています。
■原則５：殺虫剤のパラドックス
害虫駆除にずっと同じ殺虫剤を使っていると、そのうち虫が耐性をもつようになり、殺虫剤がだんだん効かなります。ソフトウェアテストでも、同じテストを何度も繰り返していると、そのテストでは新しい欠陥が見つからなくなります。
見つけた欠陥を修正するというのは、そのテストに対する耐性を身につけているのと一緒です。
そのため、ソフトウェアテストでは、新しいテストケース、テストデータでテストを実施する必要があります。
■原則６：テストは条件次第
すべてのモジュールで使える共通のテストは存在しません。ソフトウェアが使用される状況や、目的に合わせてテストの内容や方法を変更する必要があります。
■原則７：「バグゼロ」の落とし穴
ソフトウェアテストで見つけた欠陥を全て修正したからといって、良い製品とは限りません。欠陥を修正したことによる影響範囲や、新たな欠陥がないか確認しないと、できていたことができなくなったり、欠陥を修正したことで使いづらくなったりしている可能性もあります。
■まとめ
●ソフトウェアとテストは同時に発展してきた●テスト担当者なら絶対に覚えておきたい、ソフトウェアテストの7原則
ソフトウェアテストの7原則は、テストのあらゆる場面で当てはまります。
テスト担当者であるなら、絶対に覚えておいて損はないでしょう。
【参考文献】：
『ソフトウェアテスト教科書 JSTQB Foundation 第3版』