« コードレビューは緩いペアプログラミング | トップページ | Mercurial以前と以後のチケット駆動開発 »

2009/12/15

メトリクスでソフトウェア品質を見える化する

現場で使えるソフトウェアテスト Java編」を読んで内容がとても素晴らしいのでメモ。

【1】「現場で使えるソフトウェアテスト Java編」の対象読者は、Java開発者。
内容は、Eclipseの下記のテスト用プラグインで、Javaプログラムのテストや品質を解説している。

【本書で解説するEclipseプラグイン】
・Checkstyle → コーディング規約チェック
・FindBugs → バグパターン検出
・JUnit → 単体テストの作成/実行
・TPTP → プロファイリング(非機能テスト)
・djUnit → カバレッジ計測
・StepCounter → ソースコード行数測定

上記のプラグインのうち、全てを使いこなしている開発者はどれくらいいるのだろうか?
僕は、Checkstyle・FindBugs・JUnit・djUnitは使った事があるが、TPTPやStepCounterは知らなかった(^^;)

JUnitを使った単体テストで網羅的なテストを行う為に、境界値分析や同値分析をどのように使うか、静的解析とJUnitの使い分けも、分かりやすく説明されている。

【2】特に「現場で使えるソフトウェアテスト Java編」の第8章「ソフトウェアの品質評価~メトリクスで品質を「見える化」する」の内容がとても素晴らしい。

CHAPTER 08 ソフトウェアの品質評価~メトリクスで品質を「見える化」する
8-1 品質評価の進め方
  8-1-1 品質評価とは?
  8-1-2 品質評価の作業手順
8-2 品質評価の技法
  8-2-1 メトリクスを使った評価(定量評価)
  8-2-2 時系列データによる品質評価(バグ収束曲線)
  8-2-3 定性評価
8-3 例題による実習~プロセス/技法の実践方法
  8-3-1 メトリクスの測り方
  8-3-2 品質評価

メトリクスを利用した評価方法について詳しく説明されている。

日本の品質管理が生み出した手法「QC7つ道具」のうち「管理図」というものがある。
管理図は、品質の折れ線グラフが上限と下限の間の管理限界線内に含まれていれば、品質OKと評価する為の図。
例えば、メトリクスを管理図に応用して、上限と下限の範囲を品質の許容範囲と見なせばいい。

この時、メトリクスには色んな指標がある。
LOC、サイクロマチック数(複雑度)、凝集度、結合度。
テスト密度、コードカバレッジ、バグ密度、など。
これらの値は、SVNやRedmine、Hudsonにあるから自動集計できるだろう。

僕は、StatSVNStatCVSをcronで動かし、システムのLOCや開発者のコミット具合をメンバー全員が見れるようにしている。
StatSVNを見ていると、結構気づきが多い。

次は、Sonarを試してみようと思っている。

【3】また、テスト密度とバグ密度、テスト密度とコードカバレッジのマトリクスによる品質評価技法の解説も面白い。
例えば、テスト密度とバグ密度では、下記4ケースが考えられる。

3-1.テストが足りなくてバグが多い場合
→根本的にテスト計画をやり直した方がいい。

3-2.テストが足りないのにバグも少ない場合
→テストをもっと追加実施した方がいい。まだバグが出る可能性があるから。

3-3.テストを実施しすぎたためバグが多い場合
→本当にバグを出し切ったのか確認した方がいい。まだバグが出る可能性があるから。

3-4.テストを実施しすぎたのにバグは少ない場合
→品質に問題がある可能性は少ない。

テスト後に上記のように分析すれば、テストの傾向が見えるはず。
あらかじめテスト計画で上記の分析を考慮すれば、テスト時に意思決定に混乱する事もないはず。

TestLinkCnvMacroを使えば、TestLinkのテスト実績を簡単に集計できるので、代用できるはず。

【4】又、バグ収束曲線の解説も分かりやすい。
バグ収束曲線は、横軸に時間、縦軸に累積のバグ数を取った時系列の折れ線グラフ。
バグ収束曲線は普通、S字カーブでバグが増えるものの、テストが進むにつれてバグが検出されなくなる状態になる。

このバグ収束曲線の品質評価を下記3パターンで説明している。

4-1.バグの目標値に向かって収束している場合
→理想的なパターン。
 但し、バグの増え方の角度によって、品質評価が微妙に異なるので注意。
 「Γ」「S」字ならば品質をコントロールできているが、ギザギザ型ならば、収束するのか注意が必要。

4-2.バグの目標値を超えて増えている場合
→とても危険なパターン。
 バグの目標値を越える時点、あるいはそれ以前に早く異常を検知し、根本原因を分析すべき。
 実際のSW開発では、バグ修正しながら仕様追加にも対応するから、スコープを制御できなければ、このパターンに陥りやすいと思う。

4-3.バグの目標値を超えて高い値で収束している場合
→バグの目標値を超えた時点で品質は悪いけれど、収束に向かっているので、潜在バグは少ないと想定できる。
 実際のSW開発では、当初よりもコストが増えても、このパターンに落ち着く場合が多いように思う。

バグ収束曲線とテストケース消化曲線を重ねたグラフがあれば、テストの生産性や品質の測定が分析しやすくなる。
このグラフ生成も、TiDD上で自動生成できるはず。

【5】バグの傾向分析として、T型マトリクスというマトリクスがある。
T型マトリクスは、縦軸にバグ発見工程、左横軸がバグを作りこんだ行程、右横軸がバグを発見すべき行程で表を作る。

設計・開発における 品質保証・ミス防止活動のあり方

対角線上にあれば問題ないものの、対角線以外で発見されたバグは、潜在バグや同類バグが残っている可能性を示すから、更に分析が必要というもの。

JaSST関西2009のTEF関西コミュニティセッションでも紹介された手法で知っていたが、使いこなしてないので、やってみたいと思う。


品質管理は日本のお家芸とも言える分野。
特に製造業は品質管理が世界一だから、今まで世界を制覇してきた。
しかし、IT産業の品質管理は正直ボロボロと言ってもいいだろう。
ソフトウェアのメトリクスの知識はおそらく、テスターは知っていても、開発者は意識していないのではなかろうか?

この本は入門書としても実践書としても読みやすいので、まずこのやり方を真似ればいいと思う。
そして、できれば、品質評価もTiDD上に載せて、品質評価プロセスを自動化したい。
SVNやRedmine、Hudsonに品質評価で使われる元ネタは存在しているからだ。

|

« コードレビューは緩いペアプログラミング | トップページ | Mercurial以前と以後のチケット駆動開発 »

ソフトウェア工学」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック


この記事へのトラックバック一覧です: メトリクスでソフトウェア品質を見える化する:

« コードレビューは緩いペアプログラミング | トップページ | Mercurial以前と以後のチケット駆動開発 »