テストの目標とは
引用してますが、以下はskimuraさんだけ宛というわけではなくて一般論混ぜ混ぜで話してみます。長いけど、くだんない・当たり前のことしか書いてないかも。
テストは、いっぱいバグを見つけるのが目標で、目標の達成基準が、バグを見つけた数が、 目標値以上っておかしい。 テストは、正しく動作する事の確認作業で、バグを発見するのが目的の作業ではないです。 なので、目標として、自分の作ったソースにバグが少ない事っていうのは、合ってると思う。
このへんってたしかにその通りなんですが、本末転倒なプロセスを大事にすることに意味がないわけでもない側面もある(凄くはぐらかした言い方…)、と思います。
テストという工程において、「そのソフトウェアに対するテストが充分であるか」というのは「そのソフトウェアの品質・信頼性は充分であるか」というものに繋がります(と、考えられているはずです)。
テストが「充分」という尺度は定量的でなくてはなりません(と、考えられているはずです…ってこういう注釈は以下略。だって人によって違うし、おれだって結構違うもん...)
そこで、各社標準として
- 規模に対するテスト工程ごとの試験項目密度 (何件/ks @ なんちゃら試験フェーズ)
- 規模に対するテスト工程ごとのバグ検出密度 (何件/ks...)
というものがあるわけです。これはまあ、なるほど頷けますね。項目数は多い方がいわゆる網羅性が高い状態にあるわけです。ウソみたいに冗長な項目をいっぱい展開して無理に基準を達成するトンでもない人もいますが、このケースは基本的にレビューで排除する考えのようです。
さて、これで「テストのやり方」自体はいいとして、テストの目標をどこに置くか?というと、こんな感じなんじゃないでしょうか?
- テスト項目を全て網羅したか
- テスト項目は最終的に全て合格となったか
- テストによってバグを目標通り検出したか
スケジュール管理的な面を含めると以下のデータや結果も重要ですね
- テスト項目の消化速度 (何項目/人日 のような)
- 修正工数の累積
- 再テスト実施率やその項目数
さて、くだんの「バグを目標通り検出」ですが、この考え方の根底にある「規模に対するバグ検出密度」という標準値(この標準を持っている会社は多い)は、要するに『1ksあたり何件のバグは絶対あるはずなんだ』という想定に立ってます。モジュールの担当者によってバラつきもあるでしょうし、1ksってなんやねん、ＬＯＣなんてハヤンネーヨという意見ももちろんですが、だいたいの標準はこれを言語や担当者スキルの掛け算なんかをパラメータとする関数で出すようになっていたりして、一応の説明は付いていたりします(projectのafter reviewとしてこの関数を修正する情報を集める、というのもやってるとこが多いですね)
まあ、おしなべて たとえば 1ksあたり20件のバグが出るはずだ、という観点は、1ksあたり何項目テストしなければいけない、というのとは別です。強いていうなら、1ksあたり●●項目テストすれば、必ず●●件のバグがあるはずなんだという前提があります。ここだけ抜いて考えるとスゴいことを言っているように見えます。でも確かにそんな標準が多いですし、頷ける点もあります。
だから「目標通りバグを検出する」というのは目標たりえる正当性を持っている、というわけです。しかし、上の引用にあるような
目標の達成基準が、バグを見つけた数が、目標値以上っておかしい
これはたしかに謎すぎます。目標値以上に必ずならないといけないのは確かにヘンです。少ないことに対する説明、多くなってしまったことに対する説明(品質見解、なんて名前になって標準化されてるトコもありますね)は必要ですが、それ自体(検出超過)が目標足り得ることはちょっとヘンです。
現在私が参加しているプロジェクトというか事業部の標準は項目数の目標は乏しいのですが、いわゆる信頼度成長モデルに基づいています。要するに「後半でバグばんばん出たけど全項目終わったんでサイナラ」というのはおかしい、という議論。これはこれでまた別問題がありますが。
信奉者がヨダレをたらす、信頼度成長曲線、ゴンペルツ曲線の分野です…テスト関係の書籍を見ると必ずでてくる時間:項目数グラフの理想形というやつです。
そんなわけで何が言いたいかというと、
テストは、正しく動作する事の確認作業で、バグを発見するのが目的の作業ではないです。
に対しては、「全くその通り」なのは前者なのですが、その手段として「バグを発見する」ことを用いていますので、ここは意見が分かれるところでしょう、と。私はこういった標準に対して「何項目バグを見つけなくては」というのはそれはそれでスジが通っていると思うので、バグが極端に出なければアヤシイと思うのは同意できます。ということは、バグをちゃんと出す、というのがテスト工程の手段であり目的でもあるのでしょう、と。(この「目的」という単語はなんとも…)
.
.
もっと個人的なことをいうと、でかいチームで、ばりばりのウォーターフォールだと、テストラン・セルフデバッグなんて現場では横行してるし、その結果品質数値は捻じ曲がっている(単体試験の120件/ksとかなんて、実は半分ぐらいみんな勝手にやって勝手に修正して、しかも品質数値には登場しない)ので、できれば参加したくない、使いたくないです。
テストの目標は、モノが設計通りに動作することを検証する。まったくその通りです。それに直結した手段、指標、達成評価が出来るのがベストですね。
