ソフトウェアテスト必須事項、押さえておきたい「テストの7原則」

テスト、品質保証、QAに関わるエンジニアの方は、馴染みが深いと思いますが、JSTQBのFoundation Level シラバスにて定義されているテスト7原則に関してまとめます。

【この記事作成の背景】

僕自身、JSTQBの学習の際に、どうしても参考書、シラバスだけでは理解しきれなかった部分があり、他の方の説明／解説を聞いて、理解を深められた部分があるので、今回、JSTQBで最初に覚える『テストの7原則』に関してまとめます。
そこで、これからJSTQBの取得を目指す方向けに、実際の現場でのケースを含めて説明ができればと思っています。
僕もJSTQBの受験をするときは、JSTQB参考書（お馴染みの青い本）とyoutube動画で勉強をしていました。
また、JSTQB取得予定はない現場のエンジニアの方（開発、QA問わず）も頭に入れておいて損はない内容かなと思います（現役エンジニアの方からしたら、当然でしょ、、、という当たり前の内容かもですが）。

【対象読者】

・JSTQBのFoundation Levelを学習中の方、受験予定の方
・若手エンジニア
・JSTQBの内容を忘れかけているQAエンジニア／テストエンジニアの方
・JSTQBとあまり馴染みがない開発エンジニアの方も是非

【この記事で記載すること】

JSTQBのFoundation Level シラバスに定義されているテストの7原則について、1個ずつの解説として、
　これ、なんのことを言いてるの？
　実例は？
　現場での活用事例は？
を、僕の理解と解釈で書かせて頂きます。

【この記事では記載しないこと】

・テストの7原則以外の部分のJSTQBのFoundation Level シラバス記載内容
※他の内容も今後、記事で投稿するかもです。

【テストの7原則】

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

■解説■
簡単に言うと悪魔の証明です。
誰もないことは示すことができないです。
なので、いかなる場合も、「バグはありませんでした。」とは言えずに、
「テストの過程でバグは検出されませんでした。」や「今回の検証範囲では問題事象は見つかりませんでした。」というような表現が適切になります。
▲実例／活用例▲
つまり、
とあるWebサービスの機能追加に対して、100件のテストをしたがバグが出なかった。
→誤り：機能追加の開発対応で、バグは発生していない
→正しい：機能追加の開発対応に対して、テストをした100件の部分に関してはバグはない
と言うことになります。

#2.全数テストは不可能

■解説■
全パターンの組み合わせは実質テストできない（テストケース数が爆発する）よ。ってことです。
考えられる全パターンをテストしようとすると、工数的に現実的でなかったり、パターン数的に現実的でない場合がほとんどです。
そこで、テストパターンの作成方法（簡単に言うとテストパターンを絞る方法）として、オールペア法や直交表がよく知られていると思います。
▲実例／活用例▲
全数のテスト実施を目指す訳ではなく、バグが出そうなところや優先度が高いところにスコープを当てる、テストパターンを効率良く実施できるテスト技法を選択するといった部分が重要になってきます。
何も考えずに全パターンをテストする、と言うよりも、どのようにテストするかを考えるというのが、この原則の言いたいところかなと思っています。

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

■解説■
上流工程からの品質の作り込みが大切と言うことです。
レビューも静的テストの一部に含まれるので、レビューよりの原則かと思います。
また、全部の機能の開発が完了してからテストを開始するのではなく、実装が完了した機能から順次テストを対応していくこともバグを早期に見つけられる活動の一つになります。
▲実例／活用例▲
上流からレビューや各工程でのトレーサビリティ担保をすることで、後続工程での手戻りの防止に繋がります。
言い換えると、手戻りの工数は本来不要な工数（時間／コスト）なので、そこの部分をかけずに進めましょうってことですね。
また、ウォーターフォールでの開発手法のV時モデルの左側（要件定義〜設計）の部分は、品質を作り込む部分になります。
この部分でいかに品質を作り込めるかで、結合テスト以降でのバグ検出数や件数含めて妥当なバグ検出ができるか、に影響がしてきます。

#4.欠陥の偏在

■解説■
パレートの法則（20：80の法則）のことです。
パレートの法則に則っると、「バグ全体の80％は、全体機能の20％に集中する」と言うことになります。
▲実例／活用例▲
ある程度テスト実施の進捗率が出てくると、バグ傾向が見えてくると思います。
その際のバグ分析でこの原則が適用できます。
バグ傾向をその後のテストスコープや強化テスト方針に活用できます。

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

■解説■
同じテストケースを繰り返し実施をしても、そのテストケースではバグの検出ができなくなります。
同じ殺虫剤を使い続けると、虫にその殺虫剤に耐性が生まれるように、
同じテストケースでバグ検出を繰り返すと、そのテストケースに対して開発チームが耐性を持つようになります。
該当部分の修正が繰り返されるので、バグが取り除かれるたびにコードの品質が良くなっていくイメージです。
▲実例／活用例▲
開発中の機能に対して、同じケースを何度実施しても2回目以降のテスト実施では、バグ検出率は下がります。
しかし、テストパターンやテストデータを更新することで、1回目に検出できなかったバグの検出に繋がることもあります。
ただし、全機能リグレッションといったデグレード確認や全体の正常性確認、性能面での劣化確認に関しては、繰り返し実施をすることに意味が出てきます。
繰り返し実施をし、前回結果と比較することで、機能劣化や性能劣化がないこと、予期せぬデグレードが発生していないことの担保に繋げることができます。

#6.テストは状況次第

■解説■
記載の言葉の通りそのままですが、テスト対象によってテスト条件が変わると言うことです。
テスト対象の製品／システム毎にテスト観点やテスト条件を洗い出す必要があります。
▲実例／活用例▲
検索システムのテスト観点と通販サイトのテスト観点では、全く異なるテストになることは想像しやすい思います。
例えば、検索システムでは、検索結果の妥当性や検索条件の組み合わせがメインのテスト観点になってきます。
一方で通販サイトでは、購入までの一連のシナリオや決済処理に不正がないか、セキュリティ妥当性がメインのテスト観点になってきます。
このように、テスト対象によって、どのようなテストをするか、どの部分がテストとして重要かが変わってきます。

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

■解説■
シラバスでは、「#1.テストは欠陥があることは示せるが、欠陥がないことは示せない」と「#2.全数テストは不可能」の原則があるために、バグを全て検出できる訳ではないと言うことです。
また、バグは製品／システムが使われなければ検出されません。
そのため、たとえバグが0件であったとしても、品質に問題がある可能性は残っており、バグが表面化していないだけの可能性があると言う原則です。
また、バグがなかったとしても、イマイチなUIだったり性能が悪かったりすれば、ユーザにとって使いやすい製品／システム（品質が良い）とは言えません。
▲実例／活用例▲
「#1.テストは欠陥があることは示せるが、欠陥がないことは示せない」でも記載したようにテスト結果でバグ0件だったとしても、そのテストでバグが出なかっただけであり、バグがないとは言い切れないです。
僕の実体験ですが、結合テストでバグが0件だったが、テスト観点漏れが発覚して、結合テスト完了後にバグが20件近く検出されたことがあります（苦い思い出）。
また、開発規模にもよりますが、個人的に「バグ0件でした。」のテスト結果報告は少し不安になります（笑）。
現場（僕のチーム）では、観点漏れがないか、テスト漏れがないかをテスト実施レビューと言う形でクロスチェックをしています。

以上が、『テストの7原則』の僕なりの解説になります。
今後JSTQBの資格取得を目指す皆様の理解のサポートになれば幸いです。
また、JSTQBを知らない方、開発エンジニアの方、JSTQB取得後しばらく経っている方の気づきや思い出しに役立てれば光栄です。

では、ありがとうございました。

【参考文献、兼、引用元】
・JSTQB　Foundation Levelシラバス（Version 2018V3.1.J03）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf