65.テストの7原則 その⑤
テストの7原則「欠陥の偏在」
欠陥、つまりバグは全体的に均一に存在するわけではなく、特定の機能などに集中してあったりするよ、ということ。
これを言うと「何を当たり前のことを…」という人も多いけど、実際のテストケースはそうなっていないことが多い。
全体的にノッペリとしたテストケースはよく見る。
そうするとどうなるかというと、本当に注力しなければいけないテストが薄いとか、他の場所に時間を取られて、注力すべきところにそこまで時間を割いていない、なんてことが起こったりする。
あと、テストはお尻の工程にあったりするため時間が足りなくなってしまうことがある。
そんなときに「選択と集中」の決断をするときがあるが、その際の判断材料にもなるゾ。
開発者に聞く
テストは独立すべき！開発には聞かない！俺らは俺らのやり方でやる！みたいな場所もある。
それはそれでバイアスがかからなくていいかもしれないが、経験上、開発者と話をして情報をもらった方が問題点の洗い出しや計画を立てやすいし、後から「ここらへんどうなっています？」「ええっ、そこまで影響範囲が！？」みたいなウッカリもなくなったりする。
自社開発の場所は開発者と話し合いをした方がより漏れも少なく安心感があるテストができる。
バグが集中しやすい場所
ここについては、プロジェクトによって様々。
古来よりし語り継がれてきたイニシエのスパゲティコードなどもそれにあたる。
仕様書を読んでみて、ぱっと見よくわからない条件分岐の場所もかなりアヤシイ。
（〇の場合こうだが、△の場合はこうなる。ただし△の場合は×にチェックがある場合は□となる……みたいな）
条件が複雑だとパターンが漏れていたりすることよくある。
可哀そうだが、ドメインに入ってきたばかりの人が作った場所もアヤシイ。
そのプロダクトに伝わる謎の暗黙知があったりするからだ。
（ここを直すと実はこういうところに影響あるから気を付けようね！みたいな曰くつきな場所など）
レビューがしっかり通っているならばいいが、レビューがそこまでしっかりしていないところは要注意。
俺、この戦いが終わったら結婚するんだ
よくある「俺～したら結婚するんだ」というフラグ。
原典はどうやら「ジオンの亡霊(1991ガンダムマガジン)」というマンガとのこと。
