JaSST’13 Hokkaido Workshop
TEF道 Presents

このワークショップでは典型的なメトリクスの使い方や、メリット・注意点を、演習を通じて学んでいただきます。
メトリクスをテストのインプットに活用する演習を通じて、メトリクスの使い方を実践し、その効果を実感していただきます。

テストとメトリクスの素敵なマリアージュ
初心者〜中級者向けワークショップ

JaSST’13Hokkaido ©TEF道

TEF道紹介メトリクスとは？
ソフトウェア開発で、ソースコードの品質を数値化して定量的に評価することや、その際の評価手法や基準などの体系のこと（IT用語辞典 e-Wordsより）

正式名称：TEF北海道ソフトウェアテスト勉強会 Testing Engineer’s Forum HOKKAIDO
会費は無料。ほぼすべて手弁当で対応。隔週で一回2時間程度の開催。
たまに公開ワークショップと合宿。しょっちゅう飲み会。他地域勉強会連携など。
参加メンバーは10名程度で、常時5～6名のメンバーが参加。
【これまでの戦績】
2006年～2008年 JSTQBテスト勉強会として発足。断続的な活動。
2009年 JaSST北海道にて成果発表
2010年 JaSST東京に事例発表、JaSST北海道でワークショップ実施
2011年 HOTATEｗワークショップの不定期運営開始
JaSST北海道にて初心者向けワークショップ実施1

http://ameblo.jp/tef-do/
tefdoblog@gmail.com

2012年 JaSST東京にて
TEF道 派生ユニット“チームYuki Da RMA”にて「テスト設計コンテスト」出場
派生分科会、USDM分科会を発足し、要求仕様に関する勉強を開始。
2013年 JaSST東京にて “チームYuki Da RMA”「テスト設計コンテスト」準優勝
書籍「ソフトウェアテスト技法ドリル」を使った勉強会を開催中（ほぼ隔月で）！！
JaSST’13Hokkaido ©TEF道

2

簡単に言うと・・・

JaSST’13Hokkaido ©TEF道

3

もっと簡単に言うと・・・「メトリクス」＝「指標」• プロジェクトやプロダクト状況を「数値化」すること（定量化）• 定量化する事により、客観的な状況分析ができる＝物事を判断したり評価したりするための目じるしとなるもの（デジタル大辞泉より）「目的」の為に集められる、「観点を持った」デー
タの集計方法と言える例）【目的】システムの品質を確かめたい【データ集計方法】バグの数をカウントする• 「バグがたくさん出ているので大変です！」よりも「バグが○ ○件出ていますので、大変です！」の方が、報告としての価値が高い⇒これを「バグ数」という名前のメトリクスと定義する【活用方法】
バグ数の⼤⼩で、品質の良し悪しを判断する
JaSST’13Hokkaido ©TEF道

4

JaSST’13Hokkaido ©TEF道

51

メトリクス例「メトリクス」 クイズ！ ①

成⻑オーダー（アルゴリズム解析、O記法など参照）
ソースコードの⾏数
循環的複雑度ファンクションポイント法
ソースコードの⾏当たりのバグ数
コード網羅率
顧客要求仕様の⾏数
クラスおよびインタフェースの個数
Robert Cecil Martin のソフトウェアパッケージ測定法
凝集度
結合度(Wikipedia「ソフトウェア測定法」より)とあるシステムについての想定バグ数と、実際にテストチームが発⾒したバグ数は以下でした。この結果から言えることは？
5件① システムの品質がとても良かった② テストチームのテスト技術不⾜③ バグ数の情報だけでは、①とも②とも言える「メトリクス」 クイズ！ ②とあるシステムのバージョンごとの発生バグ件数のグラフがあります。上司はV18〜V20 にて実施
したレビュー改善の効果がでて、バグ件数がV21から少なくなったと言っています。
これは本当でしょうか？本当かどうかを確かめるためには他にどのようなメトリクスが必要でしょうか？

バグ率

プロジェクトA

10時間

5.0%

プロジェクトB

20時間

2.5%

プロジェクトC

50時間

1.0%

7

JaSST’13Hokkaido ©TEF道

メトリクス分析 例題

プログラム品質改善のため、開発仕様書レビュープロセスを導入し、レビュー実施時間とバグ率のメトリクスは以下でした。この結果から言えることは？
レビュー時間100件

実績 発⾒バグ数

6

JaSST’13Hokkaido ©TEF道

プロジェクト名称

想定 発⾒バグ数

発生バグ件数80①②③66

レビュー時間とバグ率には相関関係が無く、レビュー時間を増やしても、バグは減らない
レビュー時間とバグ率には相関関係があり、レビュー時間を増やすほど、バグは減る。
レビュー実施とバグ率の直接の因果関係は、このメトリクスだけでは分からない

60

45

発生バグ件数
80

6.0

60

4.040

2.0

平均残業時間V15

開発対象機能案件数

200.00V15 V16 V17 V18 V19 V20 V21 V22 V23 V24

レビュー改善の効果は⾒られない。

25
18

220

必要なメトリクス
レビュー指摘件数 / 開発対象機能数
レビュー指摘重要度の割合 等々
レビュー指摘件数／開発対象機能レビュー指摘件数/案件

28

レビュー
改善

20

メトリクス分析 例題 回答例

8.0

52

51

40

8

JaSST’13Hokkaido ©TEF道

55

60

V15 V16 V17 V18 V19 V20 V21 V22 V23 V24

実際は･･･
残業規制が掛かっていて、1バージョンあたりの開発対象機能数が半分になっていた。 10
JaSST’13Hokkaido ©TEF道

V16V17V18

V19

V20

V21V22V23V24

JaSST’13Hokkaido ©TEF道

9

メトリクスを収集・分析するときの失敗リスク
誤ったデータ集計により、誤った判断や報告をしてしまう。
誤ったメトリクスの認識により、誤った判断や報告をしてしまう。
恣意的なデータ集計により、偏った意思⼒が働いてしまう。
メトリクスへの過剰な信頼により、プロジェクトが非効率化する。
JaSST’13Hokkaido ©TEF道112

①ワークの説明

メトリクスを収集・分析する
メリットa.ワークの全体像

プロジェクトの正しい情報を得ることができ、プロジェクトの問題を早めに特定して、是正できるステークホルダに、客観的な情報を提供できる重要なトレードオフの客観的判断を下す事ができる判断に対しての客観的正当化が⾏える

間違ったメトリクス分析をレビューして、正しい分析とテスト計画へと修正するワークです。
シチュエーション。
システムテスト後の強化試験の計画中みなさんに取り組んでいただくことダメ社員のダメな分析結果をレビュー。
メトリクスを分析し、テスト計画・分析を修正する。
12

JaSST’13Hokkaido ©TEF道

13

JaSST’13Hokkaido ©TEF道①ワークの説明b.プロジェクト背景
対象製品は、「湯沸しポット」
機能テストとシステムテストまでは完了。
しかし、まだ製品の品質に不安があるため、弱点部分の「品質強化試験」を実施したい。
システムテストまでのテスト結果・分析結果をもとに弱点を探してピンポイントで突く！
そのテスト計画を策定中。。
JaSST’13Hokkaido ©TEF道①ワークの説明c.「品質強化試験」の方針

14

システムテストまでの各種メトリクスより、プロダクト品質の弱点とリスクを分析する
分析結果より、テスト方針を作成
方針を元に、実施済みテストからの【抽出】や、【追加作成】を⾏う⇒ダメ社員が頑張ってやってみたので、上司（皆さん）でレビューをするところからワークが始まります。。。
15

JaSST’13Hokkaido ©TEF道

グループワーク①グループワーク①-1

JaSST’13 メトリクスWorkshop≪あなた方は、Aさんの上司です≫≪計画を承認する⽴場です≫グループワーク①・・・方針のレビュー

Aさんが作った「メトリクス分析結果」のレビューをお願いします。

グループワーク②
・・・テスト設計の検討

JaSST’13Hokkaido ©TEF道

16

JaSST’13Hokkaido ©TEF道

17

3

グループワーク①

グループワーク①-2

グループワーク①

グループワーク①-3

レビュー観点

レビュー対象分析が間違っていると思われる点
分析が足りないと思われる点
他の解釈が可能と思われる分析

メトリクス資料（オープンクローズチャー
ト：バグ数の積み上げ推移／テスト残数の推移）
余⼒があれば、他のメトリクスのレビューも⾏ってみてください

18

JaSST’13Hokkaido ©TEF道

グループワーク①

ヒント
まず分析結果を読む。（いきなりメトリクスを読まない）
最初はメトリクスの細かい所を気にしない
ざっとメトリクス全体を眺めて感覚的に「気になる」箇所にチェックを入れる
グラフの形に違和感がある／不⾃然である
突出した数字がある「重要な項目」を特定して、注視する「気になった箇所」の詳細を他のメトリクスなどで内容を確かめる

グループワーク①

グループワーク①のまとめ・講評

グループ発表と講評

20

JaSST’13Hokkaido ©TEF道

19

JaSST’13Hokkaido ©TEF道

21

JaSST’13Hokkaido ©TEF道

グループワーク①

例：休⽇を抜かしてみると・・・
欠陥件数…

休日あり
80

メトリクスの分析方法（提案）

修正件数…

まずは全体を把握して、「気になる箇所」を特定した後、そこから詳細分析を⾏う

604020

欠陥件数…

休日なし
80

5/27

5/20

5/13

5/06

4/29

4/22

0

いきなり、アテもなく詳細分析を⾏うと⼤変・・・
たとえば、三⾊ボールペンなどでチェックを⾏う「詳細分析」を⾏った結果から「仮説」を⽴てて、他の⼿段にて検証を⾏う

修正件数…

たとえば補完する他のメトリクスなど
仮説が正しいかどうか単一メトリクスで判断するのは危険604020

JaSST’13Hokkaido ©TEF道

5/17

5/08

4/22

022
傾きの印象が変わる

JaSST’13Hokkaido ©TEF道234

グループワーク②

グループワーク②-1

JaSST’13 メトリクスWorkshop

Aさんはギブアップしてしまったので、みなさんで【グループワーク①】（レビュー結果）の結果と各種メトリクスを利⽤して、テスト設計を⾒直してみましょう。

グループワーク①・・・方針のレビュー

グループワーク②
・・・テスト設計の検討

24

JaSST’13Hokkaido ©TEF道

JaSST’13Hokkaido ©TEF道

25

グループワーク②

グループワーク②-1

ヒント• 品質強化試験を⾏う上で、重要と思われる仕様に重要度（◎、○、△、×）を記入してください• 余⼒があれば、「機能テスト」をやるのか「システムテスト」をやるのかな
どの「テストカテゴリ」や「テスト条件」なども考えてみてください

⽋陥重要度ランクAのバグが出た機能に起こりえることは・・・？
修正のオープン日数が大きいと何が考えられる・・・？
プロジェクト状況を考えて、エンジニアに何が起こっているかを想像してください
システムテスト突入の判断は正しかったのか？
そもそも、品質強化試験開始が果たして出来る状況なのか？

JaSST’13Hokkaido ©TEF道26

JaSST’13Hokkaido ©TEF道27

グループワーク②

グループ発表たとえばこんな感じ
⽋陥重要度ランクAのバグが出た機能に起こりえることは・・・？
デグレードのリスクがある
修正のオープン日数が大きいと何が考えられる・・・？
修正に時間がかかる⇒難易度が⾼い⇒デグレードリスクが・・・
プロジェクト状況を考えて、エンジニアに何が起こっているかを想像してください
急激に慌てて修正されている⇒ちゃんと修正されていない？
システムテスト突入の判断は正しかったのか？
安全性試験と負荷試験は、再度実施が必要？

グループ発表と講評

JaSST’13Hokkaido ©TEF道28

JaSST’13Hokkaido ©TEF道29

5

グループワーク②

グループワーク②のまとめ

全体まとめ
メトリクス分析により、「気になる箇所」の特定が素早く⾏える
正しいメトリクス分析により、プロジェクトへの有用な情報を提供できる
単一メトリクスだけではなく、複数のメトリクスで補完して分析しよう
仮説を⽴てる→メトリクスにて検証の流れメトリクスに振り回されない（メトリクス収集を目的としない）

メトリクスを正しく収集分析すると、プロジェクトの意思決定に有用な情報となる
たとえば、品質状況の把握やテスト方針決
定
前工程の状況や、前回プロジェクト状況や、類似プロジェクトとの状況が参考になる
プロダクトメトリクスとプロジェクトメトリクスの両面から考える
意外なメトリクスも参考になる場合がある
30

JaSST’13Hokkaido ©TEF道

複数のメトリクスで分かること
⽋陥率

31

JaSST’13Hokkaido ©TEF道

よくよく調べてみると・・・

欠陥率（重複あり）※１
欠陥率 ※２

無駄なテストケース数が増えると、今回の定義の「欠陥率」では、⽋陥率がどんどん下がっていく！

1.400
1.200
1.0000.800
0.600
0.400
0.200

テスト密度

0.000
アイドル機能

沸騰機能

保温機能

給湯機能

テストケース数

総計

120

給湯機能のバグ率が低く、品質が良いように思えるが・・・・

25.00

100

20.00

80
15.00
60
10.00
40

テスト密度が突出してい20
る⇒冗⻑なテストを実施しているのではないか？
JaSST’13Hokkaido ©TEF道―

仕様に対して、テストケース数が多すぎる？（全組合せを実施している）

2.6給湯―
ボタン
260-11 ■熱湯によるやけど・空焚き・電源 給湯ボタンの動作条件の確認
異常時の使⽤による事故を防⽌する ・各条件の組み合わせ 2^6ため＜ポンプを作動できる場合＞以下の条件を全て満たすとき、給湯ボタンを押している間、ポンプを作動する（給湯する）。一つでも条件を満たしていなければ給湯できない。
・ロック解除状態であること
・⽔量が適正であること
・蓋センサがonであること
・ヒータ用電源がonであること
・温度エラーを検知していないこと
・保温⾏為中であること

645.00

320

アイドル

8給湯機
能給湯ボタン

0.00
沸騰機能

保温機能

JaSST’13Hokkaido ©TEF道33

給湯機能

今回の分析で足りないもの
今回のリスク分析は「品質リスク」のみです。（対象システム自体の品質リスク）「ユーザーにとって不利益な問題が起きてはいけない」という「ユーザーリスク」の分析も合わせて考慮してくだ
さい

ありがとうございました
資料に対する問い合わせはこちら
tefdoblog@gmail.com

たとえば、ユーザーへの影響（直接的危険性／経済的損失）が大きい機能は重要
JaSST’13Hokkaido ©TEF道34

JaSST’13Hokkaido ©TEF道356