JaSST’17 Tokyo Workshop
TEF道 Presents

テストとメトリクスの素敵なマリアージュ

このワークショップでは典型的なメトリクスの使い方や、メリット・注意点・テスト方針への活かし方を、演習を通じて得ていただくことを目的としています。

JaSST’17 Tokyo ©TEF道1

TEF道紹介

正式名称：TEF北海道ソフトウェアテスト勉強会 Testing Engineer’s Forum HOKKAIDO
会費は無料。ほぼすべて手弁当で対応。隔週で一回2時間程度の開催。
たまに公開ワークショップと合宿。しょっちゅう飲み会。他地域勉強会連携など。
参加メンバーは10名程度で、常時5～6名のメンバーが参加。
【これまでの戦績】

2006年～2008年 JSTQBテスト勉強会として発足。断続的な活動。
2009年

JaSST北海道にて成果発表

2010年

JaSST東京に事例発表、JaSST北海道でワークショップ実施

2011年

HOTATEｗワークショップの不定期運営開始
JaSST北海道にて初心者向けワークショップ実施

2012年

JaSST東京にてTEF道

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

派生ユニット“チームYuki Da RMA”にて「テスト設計コンテスト」出場

派生分科会、USDM分科会を発足し、要求仕様に関する勉強を開始。
SQiPシンポジウム、JaSST東海にて、SIG開催。

2013年 JaSST東京にて “チームYuki Da RMA”「テスト設計コンテスト」準優勝
書籍「ソフトウェアテスト技法ドリル」を使った勉強会を開催。

…

SQiPシンポジウムにてSIG開催。
2016年

各月1回持ち寄り勉強会開催。
JaSST’17 Tokyo ©TEF道2

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

JaSST’17 Tokyo ©TEF道3

簡単に言うと・・・「メトリクス」＝「指標」＝物事を判断したり評価したりするための目じるしとなるもの（デジタル大辞泉より）「目的」の為に集められる、「観点を持った」デー
タの集計方法と言える例）【目的】システムの品質を確かめたい【データ集計方法】バグの数をカウントする⇒これを「バグ数」という名前のメトリクスと定義する【活用方法】
バグ数の大小で、品質の良し悪しを判断する
JaSST’17 Tokyo ©TEF道4

もっと簡単に言うと・・・• プロジェクトやプロダクト状況を「数値化」すること（定量化）• 定量化する事により、客観的な状況分析ができる• 「バグがたくさん出ているので大変です！」よりも「バグが○ ○件出ていますので、大変です！」の方が、報告としての価値が高い

JaSST’17 Tokyo ©TEF道5

「メトリクス」 クイズ！とあるシステムについての想定バグ数と、実際にテストチームが発見したバグ数は以下でした。この結果から言えることは？
想定 発見バグ数

100件

実績 発見バグ数

5件① システムの品質がとても良かった② テストチームのテスト技術不足③ バグ数の情報だけでは、①とも②とも言える
JaSST’17 Tokyo ©TEF道6

わかったこと①

単一のメトリクスだけだと、事実を正しく把握できない場合がある

JaSST’17 Tokyo ©TEF道7

メトリクス分析 例題• とあるシステムのバージョンごと（V15～V24）のテストフェーズのバグ検出件数のグラフがあります。
• V18～V20にて「仕様書レビューの改善」を実施して、プロダクト品質向上の施策を行いました• 結果として、V21以降のバグ検出数が減っていることがグ
ラフから確認でき、上司は「レビュー改善の効果が出て、プロダクト品質が向上した！」とドヤ顔で言ってます
発生バグ件数
66

70
6055

60
52

51
4550
40

28

30

25

レビュー
改善

20

18

22

100
V15

V16

V17

V18

V19

V20

V21

V22

V23

V24

これは本当でしょうか？本当かどうかを確かめるためには
JaSST’17 Tokyo ©TEF道
他にどのようなメトリクスが必要でしょうか？

8メトリクス分析 例題 回答例
必要なメトリクス
レビュー指摘件数 / 開発対象機能数
レビュー指摘重要度の割合 等々
発生バグ件数

平均残業時間開発対象機能案件数80バグ指摘件数／開発対象機能レビュー指摘件数/案件
8.0

60

6.040

4.020

2.00
V15 V16 V17 V18 V19 V20 V21 V22 V23 V24

0.0
V15 V16 V17 V18 V19 V20 V21 V22 V23 V24

開発機能数に対するバ
実際は･･･
グ検出件数をみると、残業規制が掛かっていて、1バージョンあた
JaSST’17 Tokyo ©TEF道 プロダクト品質の向上
りの開発対象機能数が半分になっていた。
は見られない。

9わかったこと②複数のメトリクスを組み合わせることで、初めて事実を把握できる場合がある

JaSST’17 Tokyo ©TEF道10

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

11

メトリクスを収集・分析する
メリット
プロジェクトの正しい情報を得ることができ、プロジェクトの問題を早めに特定して、是正できるステークホルダに、客観的な情報を提供できる重要なトレードオフの客観的判断を下す事ができる判断に対しての客観的正当化が行える
JaSST’17 Tokyo ©TEF道

12

ワークの説明JaSST’17 Tokyo ©TEF道

13

a.ワークの全体像

ワークの説明間違ったメトリクス分析をレビューして、正しい分析とテスト計画へと修正するワークです。

JaSST’17 Tokyo ©TEF道

14

b.プロジェクト背景

ワークの説明対象製品は、「湯沸しポット」（仕様は後述）
機能テストとシステムテストまでは完了
しかし、まだ製品の品質に不安があるため、弱点部分の「品質強化試験」を実施したい

JaSST’17 Tokyo ©TEF道

15

ワークの説明ｃ.「品質強化試験」の方針

システムテストまでの各種メトリクスから、プロダクト品質の弱点とリスクを分析する
分析結果より、テスト方針を作成する
新米社員が頑張って作成した「メトリクス分析結果」と「テスト方針」を、上司であるあなたがレビュー実施するところからワークが始まります。
JaSST’17 Tokyo ©TEF道16ワーク① オープンクローズチャート
オープンクローズチャートを元にした「メトリクス分析結果」のレビューをお願いします。
主な分析メトリクス
配布資料④-２（オープンクローズチャート）※全てのメトリクス資料を参考にしてみてください。

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

JaSST’17 Tokyo ©TEF道17ワーク② BTS：バグ登録状況
バグ登録状況を元にした「メトリクス分析結果」のレビューをお願いします。
主な分析メトリクス
配布資料④-３（BTS）＆配布資料④-４（BTSの集計）※全てのメトリクス資料を参考にしてみてください。

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

JaSST’17 Tokyo ©TEF道18

ワーク③ テスト密度
テスト密度を元にした「メトリクス分析結果」のレビューをお願いします。分析が終わったら「テスト方針」（どいういうテストをすべきか）も考えてみてください。
主なメトリクス資料
配布資料④-５（テスト密度）
レビュー観点分析が間違っていると思われる点／分析が足りないと思われる点
他の解釈が可能と思われる分析
各種メトリクス分析をもとに「こういうテストが必要では？」の検討

JaSST’17 Tokyo ©TEF道19全体のまとめ
メトリクス分析により、「気になる箇所」の類推が素早く行える
正しいメトリクス分析により、プロジェクトへの有用な情報を提供できる
単一メトリクスだけではなく、複数のメトリクスで補完して分析すること仮説を立てる→別のメトリクスまたはインタビューにて検証の流れメトリクスに振り回されない（メトリクス収集を目的としない）
JaSST’17 Tokyo ©TEF道20

ありがとうございました
Satomi Ogusu
Noriyuki Nemoto
Makoto Nakakuki
Kazuki Ueda
andTEF-DO
JaSST’17 Tokyo ©TEF道21

ワークに興味がある組織やコミュニティはTEF道までご連絡を！
TEF道メンバーがお伺いするかも？？
tefdoblog@gmail.com

JaSST’17 Tokyo ©TEF道22