単体テストとバグ登録

Twitterでつぶやいていたら反応があったのでブログにも書いてみる。

僕が見たり聞いたりしてきた品質管理のやり方としては

試験工程として単体テスト、結合テスト、総合テストがあり、それぞれの工程毎にステップ数あたりのバグ件数を出す。で、指標値があるのでそれよりも多かったら品質悪いのでもっとテストしろー、少なかったらテストが足りないからテストしろー、え？正解は何ですか？みたいなｗ

いやまあ理解はできるんですよ。単体テストのバグ数をチェックしないと品質をチェックできないじゃん、本当に結合テストに進んでいいのっていう気持ち。でもいまいち納得できない。とくに単体テスト。

単体テストは必要ですよ。ただバグ登録する必要あるのかなと。

ここでいう単体テストは入力、確認、完了のような一連の機能、ユースケースをExcelのテスト仕様書を書いて手動で実行するものです。ブラックボックステストです。

ありがちな作業の流れはだいたいこんな感じ。

１．仕様を理解して実装を始める。当然動かしながら作る。途中でおかしい動きがあったらすぐ修正する。バグ登録はしない。

２．実装がひととおり終わったのでテスト仕様書をつくる。作ってる最中に考慮漏れに気づいたのでソース修正。バグ登録はしない。

３．テスト仕様書をレビューしてもらう。観点漏れを指摘されたのでテスト仕様書を修正するとともにプログラムの動作も確認し、問題があれば修正する。バグ登録はしない。

４．テスト仕様書をもとに単体テストする。バグが見つかれば登録するが、上記１．から３．のことをやっているのでバグ０が普通

５．バグ０と報告する

６．リーダーからそれだとテスト足りないとか上から言われて面倒って言われる。

７．なので上記で見つけたバグをてきとーに見繕って登録する。

完全に数字いじりですねｗ　数字厨を相手にするとこうなる典型例です。

単体テストのバグを登録するにしても、僕の感覚だと上記１〜３で見つけたバグは疎通レベルであって単体テストレベルではないので登録する必要無いんじゃねって思うわけです。登録するの面倒だし数が多くなって誰も見ないでしょ。その労力は結合レベルのバグを登録するのにとっておこうよって思うわけです。

思うわけなのですが、、、これが有効なのは小規模に限るのかなという気もしています。

大規模だと目が届かない範囲が広くなるので数字で一括して管理したいのはわかります。その方が楽だもん。ただそれが有効かというと疑問。バグ数だけ見て品質がわかるとは思えない。数字のひとりあるきがはじまるだけ。品質状況を知りたいなら自分で実際に触って叩いてバグを見つけたりしてフィジカルに感じたほうがいい。人のフィジカルな感覚に勝るものは無い。数字はただの数字。意味無いわけじゃないけどそれを解釈して意味を見いだすのは人間。てなことを考えてます。

考えてますが、、、ちなみに僕はテストはすぐ飽きます。キリ！
いいテスターにはなれないなｗ