ちょっとした矛盾

世の中は矛盾に満ちているパターン。

  

 

まっとうなソフトウェアテストにおいては、潜在バグを実装規模に比例するとして定義しているようです。

  

たとえば、イカのような潜在バグ期待数です。

  

   

Javaソース1KLOCあたり、潜在バグ3個

  

なんでそんなものが必要かというと、試験の終了判定に用いるからです。

  

潜在バグ数を仮定しないと、白いカラスはいない、の証明と同じで、どこまでテストを増強し続ければよいかわからないからです。

  

# 世間では、そんなこと考えもせず、

  

# のんべんだらりと無駄なテストを繰り返しているのがデフォルトでしょうが

  

さらに、イカのような定義もあります。

  

   

試験項目数100個あたり、摘出バグ1個

  

これはテスト自体の品質あるいは性能を定義するものです。1万項目のテストでバグを1個見つけるのと、100項目で1個見つけるのと、どちらが優秀かはいうまでもありません。

  

試験項目は作成するのにも実施するのにも工数とコストがかかるのですから。

  

 

  

テストに使える工数や日程は一般的なプロジェクト計画では決まっていますから、潜在バグ数が多すぎると、そりゃもう日程遅延は確定的になります。

  

 

  

よくある間抜けな風景は、イカのようなものです。

  

   

テストを100万項目実施して

    

バグが摘出されなかった

    

これなら出荷しても大安心

  

自分で決めた「潜在バグ期待数」を摘出しないで安心する馬鹿の典型ですな。

  

 

  

潜在バグ期待数が小さいほど、プログラムの品質は高いと考えられますが、決してゼロにはなりません。SLOC規模に比例するというのもかなりノンキな考えです。

  

一方、阿呆な口入屋や、それが出入りする企業の阿呆な資材購買部門では、イカのような阿呆な値決め(=工数見積もり)をおこなっています。

  

   

1日当たり生産性 200~300ステップ

  

「ステップ数」撲滅運動家のごみためとしては、ステップに噛み付きたいところですが今は横においておいて、SLOCと読み替えることにしましょう。ステップ数撲滅運動の軌跡 ごみため(ー日ー膳!)

  

   

1日当たり生産性 200~300SLOC

  

で、月次の生産量が4000~6000SLOCに満たないと、値切りするわけです(笑

  

   

お前のところのプログラマは、

    

一日あたり100SLOCしか書いてない。

    

見積もりの半分なのに、定価分支払えるわけがないだろう

  

というわけです。

  

阿呆な資材購買部門は、重さで値決めすることしか知りませんから、

  

   

プログラムを決まったフォントサイズで印刷して

    

紙の総重量で値決めする

  

ためにはSLOCに比例させるしか能がないわけです。

  

 

  

さて品質が一定=潜在バグ期待数が一定のプログラムを書くプログラマがいたとして、

  

   

100SLOCで1個なら

    

200SLOCで2個

    

300SLOCで3個

  

となるのは説明するまでもないことです。

  

極論ですが、阿呆な資材購買部門がやっていることは、

  

   

潜在バグをいっぱい作りむほど

    

カネをたくさん払ってやるよ

  

ということになってませんか。

  

 

  

コンパクトな実装を心がけ、潜在バグのトータル数を抑えようとすればするほど値切られるとして、そんなことを何十年も続けていたら、最後に残るプログラマはどんな連中か、利口な皆様ならお分かりかと思います。