テスターのテストによる開発者のためのテスト

システム業界で思ったことをそのまま言葉にしよう

テストってなんだろう?第7回「バグゼロの落とし穴」

あれから5日。「なそ」です。

 

定期的な更新を心がけ1週間くらいのサイクルで更新を目指してます。

 

とりあえず3回目。これで三日坊主になれる。続けることに意義がありますね。

 

7つの原則も最後。今回は「バグゼロの落とし穴」です。

簡単に説明すると、全部テストしたからって安心しないでねって言うことです。

 

ここでバグゼロって無理だよって説明してたくせに何を言い出すんだと思ったあなた!

鋭いですね。ここは原則6「テストは条件次第」を使って絞り込んだ状態のテストをすべて確認が終わった状態だと思ってください。

 

当然すべてのテストが一回で確認終わると思いません。障害として報告され、修正されることがあります。その中で修正した結果、報告したAは修正できたけど、Bが新たに発生しているということがありますよね。いわゆるデグレート、デグレですね。他のテストで確認できればよいのですが、仕様外のものは見つけにくいですね。Aの修正結果で動作が重くなったり、セキュリティに穴を開けてしまったりとなり、他の障害になっては目も当てられません。Aを直したけど、今までできたCができなくなるっていうものありますね。

 

そうなるとお客さんからのクレームにつながります。結果的に自分達の信用を傷つけてしまうということがあります。

しかし、決められたテストはすべてパスしているという矛盾。修正を行う際は、Aができるだけではなく他の機能に影響しないかという視点でものを見ていく必要があります。

ちょっとめんどくさいと思いますが、これも重要な作業になるでしょう。

 

そういう意味では、リリース前のテストを決めておくべきでしょう。機能テストとシナリオテストを用意しておけば大丈夫でしょう。そして、できることなら自動化できていると作業が楽になるでしょう(毎度、ほぼおなじテストになるはずので手動でやるよりも断然効率がよいです)

でも、自動化したらOKというわけでなく、原則5の「殺虫剤のパラドックス」に注意してくださいね!

 

バグゼロと言うのは原則6の「テストは条件次第」で、テストする部分を絞り込んでいます。絶対的に原則2の「全数テストは不可能」がありますので、バグゼロなんてありえないんですよね。原則1の「テストは「欠陥がある」ことしか示せない」ですので、漏れていたら残念ですが見つけられないですね。

 

なんか原則の復習もできたのでいい感じですね。

それでは、今回は原則7の「バグゼロの落とし穴」でした。

 

次回からJSTQBの違うものを見ていきましょう。