最終更新日: 2024年2月19日

「ソフトウェアテストの7原則」とは、テストの担当者であれば覚えておきたい考え方です。ソフトウェアテストを行う際には、この原則がテストを実施する上での基本的な指針や前提になります。この記事では、当社の現役テスターが、テスト現場の実際の経験を交えながら、ソフトウェアテストの7原則とはどんなものか解説していきます。

【ソフトウェアテストの7原則】の内容

「ソフトウェアテストの7原則」とは、ソフトウェアテストの基本的な考え方をシンプルにまとめたものです。ソフトウェアテストの7原則は、日本のソフトウェア議事出社資格認定の運営組織であるJSTQBによって提唱されました。

ここでは現場の視点を交えつつ、ソフトウェアテストの7原則について1つずつ解説していきます。

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

ソフトウェアでは「欠陥がある」ことは示せても、他に全く「欠陥がない」ことは証明できないという意味です。

ソフトウェアテストを行うことによって故障が生じれば、そこに「欠陥がある」ことは確かに確認できます。けれどテストケースで網羅されなかったような、レアなケースで故障が起きないとは言えませんし、条件を変えてテストをしたら欠陥がみつかる可能性もないとはいえません。テストする回数を増やしたら、故障が生じる可能性もあります。その一方で、後述するように、考えうる全てのパターンを想定して膨大なテストケースを実施するのは不可能です。

つまりソフトウェアテストで欠陥を発見することはできても、それをもって他に一切の欠陥がないとはいえないわけです。

しかし、この原則をご存じなく、「ソフトウェアテストでバグをゼロにしたい」というお客様も時々いらっしゃいます。
ソフトウェアテストを依頼いただく際は、そのテストで全ての欠陥をみつけられるわけではないことを、知っておいていただく必要があります。

2．全数テストは不可能

全数テストとは、考えうる全てのパターン（組み合わせ・タイミングなど）でテストを行うことを指します。仮に全数テストを行うとなると、膨大な数のテストケースを実行する必要が生じることになり、予算や納期の面からみても現実的には不可能です。

たとえば部分的（一部の機能のみ）に全てのパターンのテストを行うことはできたとしても、ソフトウェア全体に関する全数テストを実施することはできません。一方、お客様の方から全数テストを求めてくると言った事例も聞いたことはないです。

3．早期テストで時間とコストを節約

ソフトウェア開発の早い段階で行うソフトウェアテストのことを、「早期テスト」と呼びます。

ソフトウェアテストは、できるだけ早期テストを行うことが理想的ではあります。開発の早期段階でバグがみつかればその修正が簡単だからです。仮に開発が進んだ段階で、ある機能のバグが発見された場合、その機能に関連する他機能の修正も必要になってしまうかもしれません。

また開発者は時間がたつごとに、そのソフトウェアの設計についての記憶が失われていきます。開発してすぐの方が、きちんと記憶があり、修正もしやすいわけです。

ただ早期テストの原則自体は正しいものの、ソフトウェアテストの現場ではこの原則通りにならないことも少なくありません。たとえば、せっかく早期テストを行ったとしても、担当者が多忙であることが理由で、開発作業の中にソフトウェアテストの指摘事項が含まれないこともあります。

4．欠陥の偏在

ソフトウェアの品質は全ての部分において均一ではなく、特定の箇所に欠陥が集中しているということが多いです。これを「欠陥の偏在」と呼びます。

ソフトウェアの各機能は、それぞれ構築の難易度は一定ではありません。簡単に構築できる機能もあれば、そうでない機能もあります。またソフトウェアは規模が大きくなればなるほど、より多くの開発者やチームに作業が分担されることになります。その開発者・チームごとにスキル差もあります。

このような理由から「欠陥の偏在」が生じるわけです。実際に、ソフトウェアの全ての機能において、満遍なく同じぐらいの量のバグが発見されるというのは聞いたことがありません。一方で、欠陥が集中している箇所や機能が特定できれば、その部分を優先して集中的にソフトウェアテストを実施し、欠陥の数をできるだけ減らすことも可能になります。

5．殺虫剤のパラドックスにご用心

同じ殺虫剤を使い続けていると、害虫が耐性を持ち始め、その殺虫剤が効かなくなってきます。殺虫剤のパラドックスとは、ソフトウェアテストにおいても殺虫剤の効き目と同じで、同じテストケースを繰り返しても新しい欠陥を見つけにくくなるという考え方です。

各テストケースによって発見された欠陥は、1つずつ修正されているわけですから、再び繰り返しても欠陥が見つかりにくくなるのは当然のようにも見えます。新しい欠陥を発見できるようにするには、パターンを変えてテストするのが有効です。

しかし実際の現場では、同じテストケースを繰り返すことが必ずしも悪いとはいえません。機能の改修がすすむことによって1度改修された筈の欠陥が復活してしまっていたり、同じテストケースで発見できる別の欠陥が生じたりすることもあるからです。

現場においては、プログラムを修正した際に欠陥が生じていないか確認するための「リグレッションテスト」において、修正前と同じテストケースを改めて実施することがあります。一方で修正が全く行われていない状態において、同じテストケースを繰り返しても意味がない、というのは「殺虫剤のパラドックス」の原則通りです。

6．テストは状況次第

ソフトウェアの性質や使われる環境などによって、ソフトウェアテストの方法を柔軟に変えるべきという考え方のことです。対象となるソフトウェアによって、顧客に求められるソフトウェアテストの内容が異なります。

たとえば過負荷に耐えることが重視されるソフトウェアでは、負荷に関するテストを求められるでしょう。またEコマースのためのソフトウェアであれば、どんな条件でも正確かつ安全に取引ができるか確認するためのソフトウェアテストが求められます。

また企業のコーポレートサイトでは、多種多様な環境から閲覧されることになるため、ブラウザや端末のシェア率などからテスト端末を選定した上で、正しく表示が行われるかページ遷移が設計通りかの確認を行うことが多いです。たいして業務系のソフトウェアでは、使用環境（OS・ブラウザなど）が限定されるため、その環境でのみのテストを行います。

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

「『バグゼロ』の落とし穴」とは、ソフトウェアテストで見つけた欠陥を全て修正できたからと言って、必ずしもソフトウェアの品質を向上させるとは限らないという考え方です。

たとえば欠陥を修正したことによって、ソフトウェアの動作が大幅に重くなってしまったとしたら、必ずしも品質が良くなったとは言えないでしょう。実際、ソフトウェアテストの段階では機能が正常に動作するかに注目しがちで、ユーザーの使い勝手（ユーザビリティ）はおろそかになりがちです。

一方で使い勝手を良くすることが品質を高めるわけではない、というケースがあるのも難しいところです。たとえばゲームの世界では操作性が良くなり過ぎるより、ある程度制限があった方がゲーム性は高まるということもあります。ソフトウェアの性質や方針によって、「どういう状態が、品質が高いと言えるか」が変わってくるわけです。

まとめ

ソフトウェアテストの7原則は、テストを実施する上で覚えておきたい基本的な考え方をまとめたものです。ソフトウェアテストで全ての欠陥がみつかるわけではないことや、ソフトウェアテストで発見すべき欠陥はソフトウェアの一部に偏在する傾向があるなどのポイントが示されています。実際の現場では、必ずしもこの原則通りとは言えないこともありますが、ソフトウェアテストをより適切に活用したり、スムーズに進めたりするのに役立ちます。