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

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

www.kzsuzuki.com

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

欠陥密度

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

GQM

• Wikipedia先生のご説明によると、「ソフトウェア工学における計測の枠組みおよびモデル化手法」
• 『Empirical Software Engineering』は読んでおけ。
  

  Foundations of Empirical Software Engineering: The Legacy of Victor R. Basili

• う～ん、このモデルを適用して何が嬉しいのか、どうも理解できない・・・。

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

指標の例

• 変数名の長さ：変数名のつけ方によって、コーディング担当者の開発言語経験の傾向を読み取る。平均的な長さが8文字以下の場合はCOBOL経験者かも・・・？とすると、Javaでのコーディングでおかしがちなミスとして・・・？
• MS Wordの編集時間：ドキュメントをWordで作っているのであれば、プロパティから、そのドキュメントの編集の所要時間がわかる。316ページあるのに編集時間が17分しかないということは・・・？

　・・・まったくもって、このような指標を思いつく発想力には、どこから来るのでしょう。この他にも、クラス間の依存関係を可視化したり、step数とコメント数とifの数を軸にした3次元グラフで、アノマリーなクラスを見つけ出したりと、ただただ帽子を脱いではかぶり、脱いではかぶりしてしまいますね。
　同じ人類として悔しいので、「人間的な」指標を自分でも編み出そうと、社内の有志で知恵を絞っております。