はじめに
JSTQBの勉強をしていて、テス友で問題を解いていて、最も簡単だと思う箇所があります。
それこそが、
1.3.1 ソフトウェアテストの原則
です。
テス友の問題だと、もはや疲れて頭が回っていないか、問題文を見間違える等のケアレスミスでしか間違えません。
それでは何故記事にするのでしょうか？
ズバリ、簡単だけど重要だからです！
ソフトウェアテストを行う上での心構えだと捉えてもらってもいいかもしれません。
もちろん、開発者の皆様もコンポーネントテスト等をするにあたって再認識しておくのは大事ですよね。
私は８月からテストチームにアサインするのですが、この基本原則は忘れないでいたいと思います。
1つ前に投稿した記事（上司「〇〇君、オブジェクト指向ってわかる？私「・・・」）でも書いたように、〇大原則とかそんな感じのやつ好きなので記事にしてみました。
ソフトウェアテスト７原則一覧
| 原則 | 内容 |
|---|---|
| 1 | テストは欠陥があることは示せるが、欠陥がないことは示せない |
| 2 | 全数テストは不可能 |
| 3 | 早期テストで時間とコストを節約 |
| 4 | 欠陥の偏在 |
| 5 | 殺虫剤のパラドックスにご用心 |
| 6 | テストは状況次第 |
| 7 | 「バグゼロ」の落とし穴 |
以上がソフトウェアテストの７原則です。
１つずつまとめていきます。
1 テストは欠陥があることは示せるが、欠陥がないことは示せない
（ ＾ω＾）・・・ﾃﾂｶﾞｸｶﾅ？
いきなり小難しいですが、考えてみると当たり前のことです。
「テストをした結果、欠陥が見つりました。ので、その欠陥を修正してプロダクトリスクを下げることに成功しました。」というのは十分に考えられるケースですよね。
「テストをしたけど１つも欠陥が見つかりませんでした。」というのも考えられるケースですが、ではそのシステムは欠陥が１つもない完璧なシステムだと言えるでしょうか？
たまたま今回は欠陥が出なかっただけかもしれません。
「そんなことを言っていたらきりがない」と思う人もいるかもしれません。
しかし、それ故に欠陥がないことは示せないのです。
2 全数テストは不可能
ズバリ！
あまりに非効率的すぎるからです。
全数テストは文字通り考えられるすべてのテストケースをテストするやり方です。
１～１００までの入力した整数が出力されるプログラムを組んだとして、単純なテストケースでも１～１００の１００通り。その他にも-１などの負の数や、少数、文字列なんかを入力した場合も考えると、このような簡単なシステムでさえも全数テストは現実的に考えて不可能だと感じるはずです。
3 早期テストで時間とコストを節約
単純に間違いを見つけるなら早い方が良いという話です。
学生時代にマークシートのテストを受けて試験終了１０分前にマークシートが１つずつずれているのに気づいて大変な思いをした、という経験をした人はいるでしょうか？
もし、１つの章ごとにチェックしていたらそのようなことにはならなかったかもしれません（実際、そんな人はあまりいないとは思いますが・・・）。
気づくのが遅れると時間とコストにかかるリスクが指数関数的に上がっていくため、これは私が個人的にも特に重要だと感じている原則です。
4 欠陥の偏在
ソフトウェアテストをすると、欠陥は均一に散らばっているというよりも１か所に集中していることの方が多いと気づきます。このような欠陥の偏在は、過去の不具合分析や直近のテスト結果によって予測することができるため、その予測結果に基づいて重点的にテストする箇所を絞るのが良い、とされています。
5 殺虫剤のパラドックスにご用心
（ ＾ω＾）・・・？ｲﾐﾜｶﾝﾅｲﾃ
「ほんとかよ」と思われるかもしれないですが見ていきましょう。
虫を退治するのに同じ殺虫剤ばかり使っていると、じきにその殺虫剤に抵抗のある虫がでてきます（ほんとかよ）。まぁでも進化の歴史をたどってみてもそうですよね。これがソフトウェアテストについても同じことが言えるらしいのです。
１つのソフトウェアに対して同じテストばかり行っているとそのテストで新しい欠陥を見つけることができなくなります。
つまり、ソフトウェアテストでは新しい内容のテストを常に作っていく必要があるということです。
こうしてパターンを追加するごとに欠陥が減ってきたならそのソフトウェアの品質が向上してきたということになります。
ただし、リグレッションテストに関してはソフトウェアに対して何も変更していないので本来は「問題ない」はずの部分にもテストを行うものなので有効だと言えます。
6 テストは状況次第
どのようなシステムをテストするかによってテスト内容も変わってきます。
これがテストは状況次第ということです。
例えば、24時間稼働し続けなければならないシステムのテストをする場合、「どんなことがあってもシステムダウンしてはいけない」ということが重要になってきます。つまり「どうすればシステムダウンするか」という観点でテストする必要があるということになります。
以上のように、「何を求められているか」によってテストは変わってくるということを念頭に入れておかなければなりません。
7 「バグゼロ」の落とし穴
ソフトウェアテストで欠陥を完全に修正したとしてもソフトウェアとして使い物にならなくなってしまうというケースがあります。
例えばメールアドレスを入力する際に、４文字までしか入力できないという欠陥が発見されたとします。
ではその欠陥を直して50000桁まで入力できるようにしてとします（実際、そんなことはないと思いますが極端な例として）。
するとソフトウェアの動作が遅くなり使い物にならなくなってしまいました。
今度はそちらのクレーム対応で忙しくなるでしょう。
欠陥レポートを受けとって、修正することも大事ですが、機能や性能、システム全体に影響はないかということも考慮しなければならないということです。
おわりに
いかがでしたでしょうか。
以上、まとめたものはJSTQB Foundation シラバス2018対応 第4版をまとめたものになります。興味がある方や、詳しく知りたい方は是非そちらをご参照ください。
では最後にJSTQB Foundation シラバス2018対応 第4版より引用させていただき、終わりとしたいと思います。
テストの一般原則について、原則そのものを覚えることよりも、実際のテストの現場で何が起こってしまうのか、イメージして理解することが大切です。