「再発防止策」は常に仕組み化で考える

ソフトウェアテストの小ネタ Advent Calendar 2019の21日目の記事です。遅刻申し訳ない...

言ってしまえばタイトルで終わるようなことで、ほとんどの方が理解されていることではあると思うのですが、改めて自分に言い聞かせる意味も込めて記事化します。

再発防止策、この響きが好きな人は多分少数派ではないでしょうか。バグ、オペミス、コミュニケーション不足など、様々な原因でソフトウェアが期待の性能を発揮しない時、決まって「二度と起こすな！」と言わんばかりに再発防止策が求められます。

しかし「再発防止策」とは、チェックリストに項目を作成して終わるものでは本来ないはずです。「二度と同じ問題を起こさない策」は、問題を防ぐ仕組みでなければいけません。

例えば、テストを再発防止策にする

ある入力が与えられた時想定外の動きをするバグが見つかったとして、その入力を自動テストに書き加え、CIで必ずテストされるようにすれば、同じ問題はほぼ確実に防げるはずです。

最初から完璧は目指さない

私はTDDが好きで、実務でも実践しているのですが、最初から全てのテストを書けるとは思っていません。テスト駆動しつつも、レビューでテストを加えることはよくあります。

なので自動テストを書きつつも、必ず何パターンかの手動テストもやります。たまに自動テストに書き忘れた、そもそもテストコードの書き方を間違っていたといったケースを見つけてヒヤリとします。

見つけた問題に関してはすぐテストケースに反映して、再発防止とします。

人間の注意力なんてものに期待するな

人間は間違う生き物ですが、仕組みは間違いません。結局は動かして期待と違う場所を見つけて、仕組み化して再発防止という繰り返しでしか、問題の少ないコードは書けないのだと思っています。

テストではなくとも、再発防止策は常に仕組みで考えるというのが正しいエンジニアリングの形であると信じています。