ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

第3回ソフトウェアテストセミナー ─ その2

 第3回ソフトウェアテストセミナー(1)の続き!よかった、ちゃんと続いて。

www.kzsuzuki.com

 ダラダラにならぬよう、今回は箇条書きで書いてみました。

欠陥密度

  • コードのstep数をプログラムの大きさと捉えて、そこに存在する欠陥の数を行数で割った「欠陥密度」を、絶対的な指標として使うべきではない。solidに仕上げたステキコード100行と、同じ内容だけど冗長な150行で、1件の結果があったときに前者の方が欠陥密度が高い=品質が悪い、というパラドックスが起きる。
  • step数を使用するとしても、そこに含まれるクラスの数を意識すべき。10,000stepのクラスが1つあるのと、200stepのクラスが50個あるのでは、同じ10,000stepでも意味が違う。
  • 欠陥密度を適用するのであれば、初期の開発に対する追加開発の欠陥密度は、といったように「同じ算出方法」「同じ条件下」で比較するのが最低条件。

GQM

こんなダメ感想を箇条書きにしてもね。。。全然まとめになっていません。ちゃんと勉強します(20年以内に)。

指標の例

  • 変数名の長さ:変数名のつけ方によって、コーディング担当者の開発言語経験の傾向を読み取る。平均的な長さが8文字以下の場合はCOBOL経験者かも・・・?とすると、Javaでのコーディングでおかしがちなミスとして・・・?
  • MS Wordの編集時間:ドキュメントをWordで作っているのであれば、プロパティから、そのドキュメントの編集の所要時間がわかる。316ページあるのに編集時間が17分しかないということは・・・?
 ・・・まったくもって、このような指標を思いつく発想力には、どこから来るのでしょう。この他にも、クラス間の依存関係を可視化したり、step数とコメント数とifの数を軸にした3次元グラフで、アノマリーなクラスを見つけ出したりと、ただただ帽子を脱いではかぶり、脱いではかぶりしてしまいますね。
 同じ人類として悔しいので、「人間的な」指標を自分でも編み出そうと、社内の有志で知恵を絞っております。