【QA】テストの７原則

ソフトウェアがこの世に生まれてきたと共にソフトウェアテストも生まれました。ここでは、一般的なガイドラインとして使われているテストの原則についてご紹介していきます。

ISTQBでは次の7つの原則を示しています。
＊ISTQB：国際ソフトウェアテスト資格認定委員会（International Software Testing Qualification Board）

• 原則１：テストは欠陥があることは示せるが、欠陥がないことは示せない

• 原則２：全数テストは不可能

• 原則３：早期テストで時間とコストを節約

• 原則４：欠陥の偏在

• 原則５：殺虫剤のパラドックスにご用心

• 原則６：テストは状況次第

• 原則７：「バグゼロ」の落とし穴

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

テストにより、故障を見つけることができれば、そのソフトウェアに欠陥があることはわかります。しかし、テストをしても故障を見つけることができなかった場合にはどう考えたらよいでしょうか。本当にそのソフトウェアに欠陥がなかったのかもしれませんが、そのテストでは「たまたま」故障しなかっただけかもしれません。また、そのテスト自身に不備があって、「たまたま」故障するパターンをテストしなかっただけかもしれません。

原則２：全数テストは不可能

全数テストとは、ソフトウェアに入力する可能性のあるデータと、テストを行うときの条件のすべてのパターンをテストすることです。通常、テストパターンはもっと複雑ですから、テストを有限の時間で行うことはとても難しいのです。

その理由でテストの現場では、ソフトウェアの性質や目的、使われ方などから重点的にテストをする場所を絞ったり、優先順位を決めてテストをしたりすることが重要です。

原則３：早期テストで時間とコストを節約

テストはソフトウェア開発のなるべく早い時期に開始し、なるべく早い時期に欠陥を見つけるようにするのが大切です。

ソフトウェアの欠陥を見つけるのが、その欠陥を作り込んでしまった時期から離れてしまうほど、ソフトウェアの設計者は、その設計またはコーディングを行った時のことを忘れてしまい、欠陥を特定するのに時間がかかってしまいます。一方、欠陥を見つけたのがコードを書いた翌日だったのであれば、設計者はそのコードの内容を鮮明に覚えています。欠陥の特定も、その修正もあっという間にできます。

原則４：欠陥の偏在

ソフトウェアの品質は均一なものではなく、欠陥が見つかるのはある部分に集中しているということがよくあります。これはソフトウェア自体がいろいろな要素から構成されているからです。パソコンに搭載されるアプリケーションなら、動作する環境、UI（User Interface）部、データベースなどで構成されます。

これらの各機能が一体となり、複雑なソフトウェアとして動きます。各機能は、その機能を実現するための設計も異なりますが、構築するための難しさの質も程度も異なります。そのため、欠陥の存在も一様ではなく、特定の個所に集中する傾向があります。

原則５：殺虫剤のパラドックスにご用心

害虫を退治するのに、同じ殺虫剤をずっと使い続けていると、だんだん利かなくなってしまいます。耐性を持った虫にはその殺虫剤の効果がなくなってしまうからです。これと同じことがソフトウェアテストにも当てはまります。

１つのソフトウェアに対して同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなります。そのソフトウェアのテストセットに対する耐性を作っているということを「殺虫剤のパラドックス」と呼びます。

したがって、ソフトウェアテストでは、システムの他の部分を狙ったテストを実行するとか、異なったパターンの入力をしてみるといった視点を変えながらテストを行う必要があります。

原則６：テストは状況次第

ソフトウェアが使われる状況、目的、ソフトウェアの作り方によって、テストの方法を変える必要があります。例えば、24時間稼働し続けなければならないシステムのテストでは「どんなことをしてもシステムダウンしない」ことをテストする必要があります。一方、eコマース（電子商取引）のシステムなら、会社または個人が取引を行うものなので、正確性、セキュリティを重点にテストする必要があります。

原則７：「バグゼロ」の落とし穴

「入力時に、5桁の数値しか入らない」という欠陥レポートがあったとして、それを5桁も100桁も入るように修正されたとします。でもその対応によってソフトウェアの動作が今までの10倍遅くなってしまったとしたらどうでしょうか。ユーザーからクレームがついてしまうでしょう。

このように、欠陥を修正することによってソフトウェアが役に立たなくなってしまったら、適切な修正を行ったとは言えません。そこで欠陥レポートを受け修正を行う際には、機能や性能、システム全体に影響はないか、といったことを確認することも欠陥を修正する上で大切な作業です。

まとめ

ソフトテストにおいて、一般的なガイドラインとして使われているテストの原則には７つがあります。原則そのものを覚えることよりも、実際のテストの現場で何が起こってしまうのか、イメージして理解することが大切です。

ソース｜JSTQB Foundation