カバレッジがもたらす災い。カバレッジ率なんてゴミ箱に捨てて、みんなで飲みに行け。
Table of Contents
コードカバレッジについて思うことを書きました。 テスト添削以外でもリリース速度を上げる方法はありますが、ここではそれは記載していません。 ここで言いたいのは、
- インパクトの小さいテストは計画的に優先度下げればよい。
- カバレッジだけでは、テストの優先度判断ができない。
の２点になります。
リリーススピードとプロダクト品質の天秤
早くプロダクトをリリースするには、必要な作業だけを行えばいいです。 プロダクトの品質保証も最小労力で最大効果を得られるテストを行い、重大な障害に繋がらない保証をできればいいです。 なぜなら、大したことない細かい障害リスクは、リリースして次のサイクルで解消すればいいのです。
具体的には、プロダクトバックログのストーリーに重要とそれ以外の2つのテストストーリーを用意しておき、POに2つのストーリーの内容やリスクを説明して判断してもらいましょう。 POが判断するれば、予めテストストーリーを落とすことによる障害を許容され、あとでゴタゴタに巻き込まれない。
こうすることで開発者は本当に重要な要素と最低限のテストのみでリリースにすることができます。 結果、リリーススピードより優先度の低いテストが落ちた分だけ期待されるリリーススピードにつなげることができる。 これはPOが希望するリリーススピードと許容する品質低下の天秤をPO自身が判断したことになります。
単体テストはエンジニアのものマネージャーのためではない
本来単体テストはエンジニアが不安を取り除くために存在する。それ以上の期待をしてはいけない。 単体テストが完璧でも繋ぎこみ部分のテストである結合テストがうまくいく保証ができないからです。
しかしながら、マネージャー層は定性評価はせず定評量化でしか判断できない。つまりカバレッジに強い興味を持つ。 そもそもの問題として、それが手軽に測れるし、それ以外が手間という原因もある。
よくあるマネージャーによるカバレッジの使い方
カバレッジ率が一定水準より以下だと、理由を求められる。 開発者は、わざわざカバレッジが低い所を洗い出し、一つ一つに説明をしなければいけない。 これはとても面倒で価値を産まない作業で、上の人達を説得するしか役に立たないものだ。
そもそもカバレッジが高ければ良いと定めたルールが歪んでいる。 カバレッジとはテスト結果による網羅性という副産物であって、テストによって得られる安定性・信頼性を証明したものではない。
そもそもカバレッジが100%でもそのコードがそもそも想定した作りであるかは証明できない。
開発者はカバレッジにのまれてはいけない
開発者としては、１０時間リソースがあったとしたら、カバレッジ率を一定水準上げる作業に１０時間より、 複雑な処理の単体テストに１０時間費やしたほうが、安心するし、ビジネスダメージも抑えられる。 これを事業部・会社の決まりだからと言って、カバレッジを水準を超えることを優先したテストを書いてしまうと、 単体テストがゴチャゴチャしたものになるし、本当にテストしたほうがいいケースを見失うことになる。 結果、障害に繋がり最後には開発者が責められることになる。
承認者と信頼関係を結ぶほうが早い
開発者がカバレッジ率を通して承認者から信頼してもらうよりも、開発者が直接承認者と信頼関係を結べるほうが話が早い。 そのほうが最終的には、「君が大丈夫だと思っているなら、僕は君を信じるよ」というベースの上で話が進むので円滑にことを進められる。 当然信じてもらっているからには、それだけの品質を保証する必要がある。 障害が発生したときには、きちんと原因追求を行い、そこがただの設定画面なのか、会員登録画面なのか明確にし報告することは重要だ。 それを怠ると、信頼は下がり数値的判断ができるような資料を用意せざる得なくなる。
