日記 20081217

あまりにも間が空いてしまった。約1ヶ月ぶりの更新。

■事実
最近は品質保証の仕事をしている。品質保証チームが立ち上がって最近ようやく回ってきたところ。なんだかんだである程度大きなシステムは工程移行時に必ずうちのチームを通すことになってきている。

今日はちょっと大きめなプロジェクトの決裁があったが、このプロジェクト、品質がよろしくない。いや、レビューは非常に綿密にやっていて、ドキュメンテーションも申し分なしだが、どうもテスト結果が怪しい。結合テストを完全に消化し不具合を治し終わったソースに対して、結合テストケースをある程度抜き取ってテストしてみたところ、結合テスト時と同じようなバグが出る、なんてことに。

品質保証チームが考えた大きな原因は、
「テストケースの書き方に問題があるのではないか」
ということだ。
この場合のテストケースは、xUnitを使う前提ではなくExcelで手書きするものの前提。

当たり前すぎるかもしれんが、テストケースは、具体的であればあるほど良いと思っている。
理想的なテストケースについて、思うところをまとめようかと思ったが
http://blog.goo.ne.jp/ka_hayst/e/a7f178e2c14719b1596d20160c7060df
http://blog.goo.ne.jp/ka_hayst/e/0ab063f8cb04306fac3226628f919118
に思ってたことが書かれていたのでそちらにゆずる。

具体的なテストケースは、作るのに時間がかかる。ましてや、手順を、誰がどう見ても絶対同じやり方になるように書いたり、想定されるデータを事前に全部定義して名前付けし、テストケースの中でそれを使うように規定する・・・なんてことをやってると、テストケース作るだけであっという間に時間が経ってしまう。エンジニアは実装を優先しがちだから、納期が迫っているときに作ったテストケースはとても抽象的になってしまうのかもしれない。
今回のプロジェクトも、テストケースにあいまいな表現が多く、プロジェクトに対する理解度や前提知識によって実施結果に差が出てしまった、というのが真相なのかもしれない。

ま、追ってさらに分析しないとわかんないけど。

■発見
テストケースは、やっぱ具体的であればあるほど良い。だけど一番いいのは、やっぱxUnitとか使ってInputとOutputを明確に厳密に定義することだ。

■教訓
xUnitを使おう。最初は時間かかるかもしれないけど絶対後でそうしておいたことに感謝できる。

■宣言
xUnitを推進する。Seleniumとかもなるべく使う。