ブロッコリーさんの記事を読みました。
にしさんの主張「テストとは納得してもらうことである」の原点〜「テスト設計コンテスト2013 関西地域予選 招待講演」一部文字起こし〜 - ブロッコリーのブログ
そして記事中に出てくるにしさんの主張「テストとは納得してもらうことである」というのが、いいなぁと思っています。
ただ「いいなぁ」で済ませるとなんだか浅いので、どのへんに良さを感じているのか自分なりに考えてみたところ、減点法でなく積み上げ思考になっているからかなという仮説を得ました。
ソフトウェアテスト、減点法になりがち問題
があるのではないか、と以前から考えています。
ブログネタのリストにもだいぶ前から居ました。
減点法になりがち、不足に目が向きがちというのはどういうことか。
「網羅」とか「充分」といった単語に含まれるニュアンスなのですが、テストすべき範囲やバグの総量があって、それをどの程度満たせたかを測るという考え方のことです。たとえばコードカバレッジなどは総量があってそのうちどの程度をカバーしているかなので似ているように見えるかもしれませんが、ここでいいたいのは違います。
もっと計測が難しい・不可能なふわっとしたものに対して、あたかも計測可能かのように扱ってしまってはいないか、ということです。
計測できないのにできるかのように扱う問題としては、100%満たしていることが基準＝当たり前になっていて、少しでも低いとダメだとみなされてしまうことです。「充分テストしたのか？」「はい！」みたいなやりとりをしたあとで少しでもバグが見つかると「充分じゃなかったじゃないか！」と言われるようなやつです。（このやりとりはどちらにも問題がありますが。）
これを指して「減点法になりがち」だと感じています。
納得してもらうこと、は、積み上げの思考に近いように思う
一方でにしさんの言っている「テストとは納得してもらうこと」というのは、減点法ではなく何かを積み上げていくような、そういう思考に近いように思うのです。
テストをすることで、テスト対象に関する情報を集めて、より皆が納得する材料にする。そして、完璧はないんだけれども、目指すレベルになるように（なっていることが確かめられるように）がんばる。
これだと、仮にテストしてバグを見逃したとしても「テストエンジニア（かだれか）に落ち度があった」「100点を取れなかった」という思考にはならず、もっと建設的な「より情報を集めるにはどうすればよかったかな」を一緒に考える形になるような気がするんですよね。もちろんバグを見逃してもかまわないと言っているわけではありません。が、マインドセットというか全体の働き方として、よりポジティブにやれるのがにしさんの考え方だと思っています。
とりとめない感じになってしまいましたが、これが個人ブログだ。
自分としては、減点法のソフトウェアテストよりも「いかにしてテスト対象の状態に関する情報を集めて、納得できる意思決定ができるか（あるいはその精度を高められるか）」だと思っているので、加点・積み上げ思考でやっていきたいものです。
誰かがどこかで同じようなことを、よりわかりやすい言葉で言ってる気がします・・・。見つけたら教えてください。