![見出し画像](https://assets.st-note.com/production/uploads/images/20745050/rectangle_large_type_2_19df2474e461126b94a5d2e473eccd80.jpg?width=1200)
探索的テストでは品質保証ができない#2
1点補足しておきます。
ただし、「網羅的テスト」でも気を付けなければならないのは、
所詮、品質保証できるのは、理論上の最高値(100%)である
という点です。
よくやってしまうのが、「100%だと思っているけど、それを証明する術がない」ケースです。ほとんどのプロジェクトにおいて、上記のように、「100%だと思っているんだけど、実際には不足していた(誤っていた)」と言うケースは後を絶ちません。「網羅的テスト」を実施していたとしても、です。
それは偏に、「網羅的テスト」の本質を理解しておらず、論理的にテストケースを洗い出す術を修得していないからです。
結果、これは探索的テストと大差がなくなってしまいます。
品質保証をおこなうだけのスタートラインに立っていません。
また、この理論値をどれだけ実態に近づけられるか?については、
「どれだけ「答え」を用意できるか」
に依存することになります。
そう、仕様書や設計書をどれだけ過不足なく、また読み間違いや認識齟齬が起きないように、記録として、証拠として、残せるかという部分に依存するということです。
用意できる「答え」の量や質によって、そもそも保証できる品質の上限値が左右されるのです(そこもアジャイルには不向きなポイントなのでしょう)。
もちろん、探索的テストと同じように、テスト実行者の「センス」や「嗅覚」に頼って、品質向上を果たし、50%…60%…70%と底上げすることは可能です。
実際、そう言うテストの仕方をするチームは、私が知る限りは相当多いような気がします。
ですが、この方法では決して『品質保証』はできません。
絶対に、です。
運よく、品質が100%になったとしても、それを証明する方法が無いのです。
(厳密には、1つだけあります。それが、JSTQBでは不可能と言われている「全数テスト」です)
いいなと思ったら応援しよう!
![Takashi Suda / かんた](https://assets.st-note.com/production/uploads/images/15070049/profile_7d39d4033cfa5aee6486482a9901291a.jpg?width=600&crop=1:1,smart)