酔っ払った勢いで書きたいことを書きましょう。
よく誤解されていると思うのですが、テストをしたら品質が上がるのではないです。
バグ摘出→テスト項目の追加→テスト→最初に戻る
このフィードバックループを回すから品質があがるのです。
どんなフィードバックも、以下のどちらかの振る舞いを持ちます。
収束する
発散する
テストにおける発散は、いくらバグを摘出しても、バグの摘出率が下がらないことでしょう。
収束もゼロに収束すればよいですが、定常偏差的な摘出率をなかなか下回ることができない状況も多いです。
いずれにしても、バグの修正というプロセスのアウターループとしてテストのフィードバックループは必要です。
バグがどんどん摘出されるとテスト項目が伏増えすぎて大変なことになるという人は、
テスト項目の増大を嘆くのではなく、
実装の品質の低さを嘆くべきです。
なので対策すべきは、実装の品質向上であり、実はそれは
いくらテストを増強しても改善されない
ということに気づく必要があります。
ただなんとなく品質が低いと嘆いている状態をイノセンスの状態とすると、テストが発散気味の状態は気付きの前の段階です。
そこで必要な気付きは、実装品質をどうやったら向上することができるかです。
実装品質を手っ取り早く向上させるには、コードレビューの導入では不足があります。徹底的なレビューをおこなうべきなのは、設計レビューです。
とりあえず実装を修正してみよう
などという無手勝流で品質が担保できるわけが無いのです。それでうまく回っているなら、テストなんかしないで作りっぱなしのコードを垂れ流しておればよいのです。
設計レビューが繰り返されておれば、議事録から詳細な仕様も自然に洗い出されます。
コードレビューが繰り返されておれば、見るのもイヤになるスパゲッティコードの引継ぎなども発生しなくなります。
いまだにカウボーイ開発している現場は、そうとう気合を入れないと、品質の改善は難しいでしょう。
2,3人で面倒を見れる規模とそうでない規模の見極めがまず必要でしょう。
ゲリラ戦をするのか、小隊規模で戦線を構築するかで、やり方はぜんぜん違うのです。
コメント