【ソフトウェア開発】「日時」をテストパターンとする場合の観点網羅

たまたま、ある開発チームにて品質トラブルが発生し、その内容確認のため、色々調べてみたら

　「日時」の加工を誤って、別の日時扱いにしてしまった

…という問題に会ってしまったので、簡単に整理しておきたいと思います。

こうした不良はよくあることです。特に「日付(Date)」だけでなく、「時間(Time)」まで一緒に取り扱うとなると、ちょっと面倒な仕様になっていることも多く、"プログラミングが得意です！"と言う若手エンジニアくんの場合、ポロポロと注意すべき観点が抜けてしまっていることがあります。

こうした問題に対して、よくあるのが

　「有識者が多忙のため、レビューに割くが不足していた」

と言った、「人」に依存した責任転嫁です。言い換えれば「言い訳」です。私も立場上、数え切れないほどの「言い訳」を聞いてきましたが、その度に優しく相手に説明してあげています。

「それを、自分の中でこう問いただしてみごらん。
　『じゃあ、それさえ解決していれば、
　　問題は絶対に発生しなかったのか？』
　もしそれで、大丈夫と思ったモノだけしか言い訳にしない方がいいよ」

と。

残念ながら、そういった意味から「有識者のレビュー不足」は、言い訳には不適切です。なぜなら、その有識者の注意から抜け落ちていたら、結局問題を見つけることができないからです。

その有識者の注意力を100%の状態にし続けられる保証があれば、大丈夫かも知れません。けれども、「人」相手に"完璧"とか"絶対"なんてことを求めても、現実は不可能なのです。

ですから、私は常に「仕組み」にします。