偽陽性を懼れるふるさと

先日こちらの記事読みまして、素晴らしいことが太字で書いてありました。

偽陽性であることを懼れずに遠慮なく不具合票を挙げるべきです。

(もちろん僕も太字で引用)

note.comこんなビッグな方の記事を勝手に貼って良いのだろうか？…と思いつつも貼っちゃいます。僕らのバイブル"ソフトウェアテスト技法ドリル"は大好評発売中です()

さてテストのおける"偽陽性"がなにかは是非上記の記事を読んでいただきたいのですが、以下これより実体験に基づくフィクション(?)でお送りします。

～～～

Once upon a time...　SES企業に勤める僕はとある組込系ソフトウェア開発プロジェクトに参画し、日々テストにいそしんでいました。

そこは独立性の高い組織によるテストを重視しており、複数の組織(企業)で競い合わせるように探索的テストを実施する文化がありました。

そしてそこには厳しい掟があったのです。

・同件は決して挙げるべからず

・制約事項は指摘するべからず

・仕様書に記載されていることを質問するべからず

・指摘する根拠を明確に述べよ

～～～

…ん？"全部あたりまえじゃないですか！"と思ったソコのアナタ。そうですその通りです。仮にこれらを守らない場合、デバッグしていただく開発の方々に余計な工数が発生したりするわけですから。

また掟が厳しめになる理由として、組織同士で競い合っているがために"有効なバグの報告数"と"却下されたバグの報告数"が定量的に評価できる適当な値であることも挙げられます。(もちろん各個人の評価も)

こういった環境に問題があるかと言われるとそうではなく、問題はこの掟を守らない人を強めに咎める一部のメンバーの存在です。

ねちっこく"なんで？どうして？"で責められるのはともかく、メンバー間の笑い種にするような空気がそこにはありました。(酒の席なんかではまーひどいひどい…)

こうなってしまうと経験の浅い方やメンタル的に少し打たれ弱い方は、インシデントの報告に非常に慎重になってきます。"偽陽性＝恥"ということが頭にインプットされてしまうワケですね。特に性能面やユーザビリティ観点の報告数というのは極端に減ってしまいます。 

以下個人的な意見になりますが、僕も偽陽性は懼れずにドンドン報告をすべきだと思います。仮に偽陽性の報告があったとして、それは全くの無駄ではありません。むしろプロジェクトの改善につながるヒントになるものだと思っています。仕様書が誤解を招くような記載になっていないか…暗黙知が盛りだくさんになっていないか…などなど...。(もちろんトンでもない報告はアレですが)

少なくとも"ああ、これは勘違いしても仕方がないな"と思える偽陽性な報告は優しく受け止め、また質問＆相談しやすい環境づくりも大切なことと思います。そして質問＆相談に答えた側がキチンと評価される世界が理想です。(これが評価されないと、工数的な負担が不満につながることもあるので)

優れたテスターの要素の一つとして、アウトプットが多い人であることは非常に重要だと思います。(去年のJaSST Tokyoでこのことをどなたか仰っていて、とても共感しました)偽陽性報告を懼れ、アウトプットが減り、精神的にもあまり良い状態でなくなってしまったとしたら、なんだかもったいないですよね。ソフトウェアテスト界としても損失になってしまいます。(少し大げさでしょうか)

テストの世界に飛び込むキッカケや、それまでの生い立ちは人それそれです。飛び込んできてくれた人のサイダネ(古い！？)が芽を出せる環境づくりを、僕は心がけていきたいと思います。そして僕がテストの仕事をここまでやれてきているのは、周りに恵まれている面も大いにあるハズなので、改めて感謝したいです。

僕は文章の最後に()を付けることが多いなと思いつつ、この記事を〆ます。