ソフトウェアテストの7原則

ソフトウェアテストの業界に身を置く人なら、「ソフトウェアテストの7原則」は誰しもが一度は聞いたことがあるかと思います。
今回はそんな有名な「ソフトウェアテストの7原則」についてあらためて触れたいと思います

「ソフトウェアテストの7原則」ってそもそもなに？

国際的な資格であるISTQBで解説されており、ISTQBの国内版であるJSTQBのFoundation Level（FL）のシラバスでも最初の方のページでも触れられている、ソフトウェアテストで提唱されている原則です。

テストは欠陥があることは示せるが、欠陥がないことは示せない
全数テストは不可能
早期テストで時間とコストを削減（初期テスト）
欠陥の偏在
殺虫剤のパラドックス
テストは条件次第
バグゼロの落とし穴

「ソフトウェアテストの7原則」の内容について紹介

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

これは書いてある通りですね。
テストでは欠陥があることを示すことはできます。
ただ、テストをやったからと言って、欠陥が無いことは示せないです。
これは、用意したテストケースが全てPassだとしても、それで「欠陥がありません」とは言えませんよね？

テストでは、バグが無いことを証明するのではなく、バグがあることを証明するのではないでしょうか。

2.全数テストは不可能

昨今のシステムは機能数が膨大にあり、入力条件などの組み合わせを全てをテストするには莫大な時間がかかってしまいます。
また、様々なシステムと関連しているシステムの場合には、その関連しているシステムの条件も考慮しなければなりません。
それこそ天文学的な数字のテストケース数となり、テストは不可能かと思います

3.早期テストで時間とコストを削減

テストを早期に実施することで欠陥をより早く見つけ出すことができます。一般的な開発サイクルでは、テストは最後にやることになっている場合が多いかと思います。
その場合、テストで見つかった欠陥を修正すると、その欠陥があった箇所以外にも影響し更なる欠陥に繋がることがあるかと思います。
そうして見つかった欠陥を修正するのに、時間・金がかかります。

そうならないよう、テストは早期に実施することが提唱されています。
テストはコードがないとできない物ではありません。
ドキュメントへのレビューや静的テストなどアプローチの仕方は数多くあります。
早期に欠陥を改善することで、結果的に時間とコストを節約することができ、品質もより良いものになるかと思います。

4.欠陥の偏在

欠陥はシステム内で全般的にあるわけではなく、特定の箇所に集中しています。これを「欠陥の偏在」と呼びます。
テストを行う際には全体的に満遍なくテストをするのではなく、過去の不具合傾向や、類似システムの不具合を参考にして、重点的にテストを行う箇所を決めることができます。

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

例えば、殺虫剤をずっと使っていると、その殺虫剤への抵抗力を持った虫が生まれてきます。
テストも同じで、ずっと同じテストケースや同じ観点のテストを続けていくと、最初こそ欠陥を見つけることができますが、いずれその箇所での欠陥は品質が上がり、欠陥が見つかることは無くなってきます。

6.テストは条件次第

システムをテストするときの条件にもよってテストも変えていくことが必要です。
例えば、自動車をテストする場合と、スマホゲームをテストする時は条件が異なります。
車であれば欠陥があると最悪、人命にも影響を及ぼしてしまいます。そのため、アクセルやブレーキといった制御部分に重きを置くかと思います。
スマホゲームでは欠陥があったとしても、人命にはあまり影響がありません。課金要素があるゲームの場合では、二重決算などのお金に関することに重きを置いたりするかと思います。
同じテストを異なるシステムでは行わないですよね

7.バグゼロの落とし穴

テスト技法などを用いて作成したテストケースが全部Passで欠陥が見つからないと言っても、それは品質が高いと言うことにはすぐには繋がらないです。
欠陥がゼロだからと言って、そのシステムが絶望的に使いにくかったら、それは品質が高いとは言えません。
テストで欠陥をなくすことはもちろんですが、我々はより良い品質のものを提供するんだ！と言う気持ちを持って、テストに取り組むべきかなとマーガリンは考えています。

終わりに

この記事を書くのにあたり、あらためて「ソフトウェアの7原則」を読んでみると、初めてこの原則を読んだときとは、違った感想を抱きました。

おそらく、また期間を開けてこの原則を読むと違った感想を持つのかな？って思います。

今回の「ソフトウェアテストの7原則」を初め、様々な原則や定石があるので、今後それらをまとめて行きたいと思います。