プログラマとプロマネのあいだ

プログラマもやるし、プロマネもやるし、たまに似非アーキとか営業っぽいこともやるITエンジニアがスキルアップの話を中心に日常を綴るブログです。

テストケースをどのように設定するか

この間、しょうもない障害を出したので、その反省と対策の意味を込めて書いてみる。
出た障害は、charで日付を保持しているテーブルに対して、date1 < '20050626'のような条件を切っているところで、date1がスペースの場合、意図せずこの条件にマッチしてしまうというところで発生した。(データベースの実装によっては、マッチしないこともありえるだろう)
恐らくテスターが行ったであろうテストケースは、想像するに以下のようなものである。(もちろん、過去の資料を探せばテストケースは見つかるだろうとは思う。)

  • date1が'20050625'の場合、データは抽出される
  • date1が'20050626'の場合、データは抽出されない

一見、何の問題もないテストケースに見えるが、そこにとんでもない落とし穴があったということになる。もちろん、今回の場合は、以下のようなテストケースの設定も必要だったということになる。

  • date1が' 'の場合、データは抽出されない

では、どのようにすれば、このようなテストケース漏れを防ぐことができるのか。よくある対策は、「レビューが足りなかったので、レビューを複数人にすることで強化する」とかいうのがあるが、レビューする人のレベルが低く、気づかなければそれでおしまいなのである。
レビューという作業は、レビュアの経験や知識や基準に基づいて、成果物のよしあしを判断する作業となることもあると思うが、チェックリストやガイドラインに沿って、成果物のよしあしを判断した方が、一定のレビューを行うことができるし、一定の品質を保てるように思う。そう、つまり、テストケースの作成ガイドラインみたいなものが必要だと考えている。
「テストケースの作成ガイドライン」って、ある程度の規模の会社や、テストに対する取り組みがしっかりしている会社には、当たり前のように存在していて、利用されているように思うが、うちの会社のように、そうでない会社も多く存在するように思う。しょうもない障害をなくすには、このような取り組みが無ければ、根本的にはなくならないのだと思う。
単体試験レベルであれば、あるロジックに対して設定すべきテストケースは導き出しやすい。まずは、単体試験レベルをターゲットにした「テストケースの作成ガイドライン」を作成していこうと思う。