評価者によるODCを使用した不具合分析の現場展開〜属人化を排除していく試み〜

2015-2-21
アヴァシス株式会社
小島義也

1

せっかく蓄積したバグデータを有効に活用できていないü バグ票データが活用できていない！ 	
ü バグ票データは収集していますが、相変わらず「経験」や「勘」に頼っています！	
ü バグ票の改善をしても効果が見えない！	

バグ票から開発やテストの診断・改善ができるとみんな思っているからやっているのに！
2

はじめに・背景* 評価業務において、不具合分析を実施し、その内容を顧客あるいは社内開発へフィードバックしている。
* 不具合分析には評価メンバーがあたっているが、評価者によって、その分析結果の粒度やアウトプット形式がマチマチであり、どうしても分析能力が高い評価者に分析業務が集中してしまい、ボトルネックとなってしまうことが多々ある。
3

はじめに・背景* 分析能力が高い評価者を育てることも重要だが、誰が分析しても同じ結果になるよ
うな方法がないかを模索し、不具合分析手法のひとつ、ODC(Orthogonal	  Defect	  Classiﬁcation)分析を使用した。

4

ODC分析とは？
統計的手法

ODC

原因解析

すべてを調べる

全体量を眺める* タグだけを見て、定量・定性的に分析する
5

①欠陥データ信頼性の向上
n バグ票の記載データを均一化し、信頼性を向上	  * ODC 8つの分類属性	  * バグの分類時期	  * 評価者用ODCテンプレート	  * 検出トリガー
6

ODC

８つの属性

属性

概要

検出工程
トリガー
市場影響
修正対象
欠陥タイプ
起因世代
発生源

欠陥を発見したフェーズ
欠陥を発見する観点
お客様に与える影響
修正対象の成果物修正した欠陥の種類
欠陥実装した種類
いつ作りこまれたか
成果物の出所 概要は森  龍二さん（エク7サ）のODC紹介資料を参考にさせて頂きました	  問題に対する施策* 計測が割合に簡単な分類属性に関しては、分類集計することにより、品質の傾向を見ることは可能になった。
* しかし、原因系の項目設定は評価者によって、マチマチとなってしまい、開発側で必要と思われるアウトプットには課題が残ってしまった。
* そこで分析の視点をまず評価者と開発者に分け、まずバグ検出時点での分類属性設定の正確度を上げるために分析の手順を論理的に組み立て、属人的にならない方法を考案した。
8

バグの分類時期(事実を整える)* 【検出】トリガー* 欠陥検出時に確定する情報* 【修正】トリガー* 欠陥修正時に確定する情報

検出トリガー

評価者が検出した時点で行える対策を考える
潜在バグの推測	
9

実装の成熟度	検出トリガーで使用したODC属性* 検出工程* 欠陥を検出した開発工程* 発生要因(=検出トリガー)* 欠陥を検出した要因、状況、状態* 市場影響* お客様に与える影響の種類
10

発生トリガーの
考え方については山崎隆さん（オリンパス・ソフトウェア・テクノロジー）のODC紹介資料を参考にさせて頂きました	  バグ票へのODC属性を設定
障害番号 障害概要 対象バージョ
障害度
ン

再現性
発生種別 回答概要 対処バージョ
原因分類
ン
確認日
確認時刻 発生分類
ステータス再現手順 結果
備考
O D C → 発生要因 市場影響 品質特性
α5.0で
tail:	 readcld100-00001[cld]	 syslogにread	 
α1.0 error:M 	 is	 directoryが書き出さ
確実
新規れ続ける‐-その他########
15:12 cld	 F W修正確認完了デバックモードで、リモートコンソールにログインし基本操作、sysl保守性
ogをtail保守性	 -f	 で参照する
再現せerror:	 Is	 a
1.デバッ
起票ミス
cld100-00002[cld]	 [cld100-00003同類]	 
α1.0
S
通常起動し確実 た場合、新規
D H C P サーバより
α5.0から発生しIP‐
が振らない
れない
-その他########
11:36 cld	 F W修正確認完了W iFiルーターより、リースIP アド
基本操作レス(クライアント信頼性モニタ信頼性ー)一覧にプリンターホスト名(printeクモードを修正しEN P C で
1.通常
cld100-00003[cld]	 デバッ
α1.
クモード
0
でないとS、EP確実S O N 	 N etconf
新規igで検索されない α4.0
設計ミス########
11:36 cld	 F W修正確認完了プリンタが表示（※デバッ検索）クモード
されないで起動し基本操作た場合は表示さ完全性/セキュリ
機能性れるティ
はシリアモードで
EN P C で
1.デバッ IP アドレ ※手順5
cld100-00004[cld]	 E P S Oα1.
N 	 N 0etconfi
SgでIP を設定後、確実 設定し新規たIP が表示されないα4.0
設計ミス########
17:29 cld	 F W修正確認完了
基本操作 信頼性
信頼性はシリア
クモード スがの後「最事前準
cld100-00005[cld]	 Q R コード
α1.の印刷中央で、0F
カッ確実
トされる 新規
ecsファイルのカッ‐
トがフ
環境設定ミ
ィードカッストでなく########、フィードなし
10:
カッ01 トclとd	 なっF W ているため。
修正確認完了Q R コードの印刷中央で、カット基本操作
される
信頼性
信頼性
備：
1.88V プリ開発のマ
cld100-00006[cld]	 通常起動しα1.1 た場合に、
S
W inS確実
C P でログイン可能新規
S S H サーバーを無効に設定変更し
α4.0-その他まし########
た
13:29 cld	 F W修正確認完了
ログインできてしまう
複数機能の相互作用
完全性/セキュリ
機能性ティ
ンターのイルス[一次解・プリンタ ・V G A 	 4cld100-00009[cld]	 escposwα1.
.exeから
1
S添付ファイルを印字すると不確実
新規 印字される場合とα5.
されない場合がある
0-その他########
20:41 cld	 F W修正確認完了1.escposw .exeから添付ファイル「H T _800.基本操作txt」
を印字さ
完全性/セキュリ
せる
機能性
ティ
析]
から印字 ポートモ
1.レシート A P I認証 期待値：
cld100-00010[cld]	 A P I認証用のI
α1.1 D のキー名が異なる
M
確実
新規printersrvの不具合です。
‐
コーディングミス########
10:30 P rinter	 S rv
修正確認完了
複数機能の相互作用
完全性/セキュリ
機能性
ティ
データを 用のID の client_id「ABC-------cld100-00011[cld]	 escposw
α1.
.exeから
1
S添付ファイルを印字すると確実新規 期待通り
コマンドに印字さパーサーの不具合。
α4.
れない
0
コーディ
工場設定コ
ングミス マンド群を送信するとcld	 F、Wデータが処理中に変化し返却済
1.てしescposw
まう。
.exeから添付ファイル「E$_3900.
基本操作txt」を印字さ完全性/セキュリせる 機能性ティ
D EF」と印 -------1.escpos 印字結果 文字化け
cld100-00012[cld]	 escposw
α1.
.exeから
1
S添付ファイルを印字すると確実
新規 文字化けしコマンドたデータから‐テキストがクラウド変換処理の仕様です。
-その他に上がる ########
10:06 cld	 F W修正確認完了他サービスと完全性/セキュリの互換性
機能性
ティ
w .exeか と異なる として起
1.escpos 印字結果
cld100-00013[cld]	 escposw
α1.
.exeから
1
S添付ファイルを印字すると確実
新規 印字結果とプリンタ
クおよびテキスト
ラウド‐ に上がるデータ-その他抽出の仕様です。
が異なる########
10:08 cld	 F W修正確認完了#N A M E?
他サービスと完全性/セキュリの互換性
機能性
ティ
w .exeか とクラウド
cld100escposw .
初回~4回
cld100-00014[cld]	 escposw
α1.
.exeから
1
S添付ファイルを印字し確実
新規ようとすると印字されない
α4.0
コーディングミス
cld	 F W
返却済
印字されない、もしくはアプリケーショ基本操作ンが停止する
信頼性
信頼性
00011とexeを用程度で印「
H T _4200
1.escpos 以下のよ N V ビット
cld100-00015[cld]	 [H T 水平]	 
α1.1escposw
S .exeから確実添付ファイルを印字すると新規ラインスケールのみ印字さ
α4.0
コーディングミれるス
cld	 F W
返却済基本操作 完全性/セキュリ
機能性
ティ.txt」
w .exeか うにライ イメージ
printhand・プリンタ
cld100-00016[cld]	 [H T 水平]	 
α1.1escposw
S .exeから不確実添付ファイルの「
新規 H T .3300.txt」を印字するとα2.0
印字さコーディれる場合とングミス 印字されない場合がある
cld	 F W
返却済
1.escposw .exeから添付フ#N Aァ
Mイル「E? H T _3300.
基本操作txt」を印字さ完全性/セキュリせる 機能性ティ
elerの不から印字
cld100プリンタ -------cld100-00017[cld]	 [LF印字改行]	 
α1.1
escposw
S.exeから確実添付フ新規
ァイルの「LF.1500.txt」
α4.
が印字さ0れない
コーディングミス
cld	 F W
返却済
1.escposw .exeから添付ファイル「LF_1500.
基本操作txt」を印字さ完全性/セキュリせる 機能性
ティ
00011とから印字 -------現象１
現象1
現象1-------cld100-00018[cld]	 [ES C 	 α1.
倒立印字の指定･解除]	 
1
S
確実
escposw新規.exeから印字すると印字結果が異なる又P
α4.0
コーディングミ
rinterS
ス rvInspectorへデータ
cld	 がP
F WO S T されない返却済
複数機能の相互作用
完全性/セキュリ
機能性
ティ
仕様通り
印刷結 -------	 
印刷結 -------cld100-00019[cld]	 [ES C 	 α1.
倒立印字の指定･解除]	 
1
S
確実
escposw新規.exeから印字すると期待結果の画像が間違っ印字結果が異なる‐-その他ていると考えます。
########
10:10 cld	 F W修正確認完了基本操作 完全性/セキュリ
機能性ティ
1.escpos 果異なる -------	 
添付ファ
cld100-00020[cld]	 [ES C 	 α1.
倒立印字の指定･解除]	 
1
S
確実
escposw新規.exeから印字するとコマンドから
P‐riテキスト
nterS rvI変換処理の仕様です。
nspectorへP-その他- O S########
T されるデータが文字化けする
10:10 cld	 F W修正確認完了
複数機能の相互作用
完全性/セキュリ
機能性ティ
1.escpos P rinterS r イル補足
印字しな	 ・印字さ -------cld100-00021[cld]	 [ES C 	 α1.
倒立印字の指定･解除]	 
1
S
確実
escposw新規.exeから「E{____3600.txt」‐ 印字すると-その他印刷されない########
10:13 cld	 F W修正確認完了
基本操作 完全性/セキュリ機能性ティ
い→スク
1.escpos れない-------	 
・印字さ 添付ファ
cld100-00022[cld]	 [ES C 	 α1.
倒立印字の指定･解除]	 
1S
確実
escposw新規.exeから「E{不具合です。
____3500.txt」
α5.
印刷する場合、
0コーディbatフングミァス
イルを2回押下しないとcld	 印字さF W れない 返却済
複数機能の相互作用
完全性/セキュリ
機能性ティ
1.escpos れない
イル補足
107_G S _( バー印刷 他のコマ
cld100-00023[cld]	 [G S 	 kα1.
_機能367]	 
1
R
S EC V 内クリ
確実
ア後、Feedボタ
新規 ンが効かず、不具合です。
フリα4.
ーズし修正し0 たようまし
コーディたに見える(ングミ+カッス トもしない)
cld	 F W
返却済複数機能の相互作用
信頼性
信頼性
K _機能がされた ンドでも【バグ票の整理】	  ①ODC分析に適したバグ票の設計を実施	  	  ②評価者が分類設定できる属性項目を追加	  ↓	  ※人によって異なってくるデータの分類作業の誤差をなるべく小さくする工夫を考える11評価者用ODCテンプレート* 対象としたODC属性* 検出工程  （Defect	  Removal	  Activities）* 発生要因  （Triggers）* 市場影響 (Impact)	  * 画面レビュー  (Triggers	  -­‐	  GUI	  Review)	  * 対象とした一般属性* 品質特性(ISO/IEC	  9126-­‐1)	  * 利用時の品質特性(ISO/IEC	  25010)	  * 機器分類
* 機能分類* 重要度
12

Ø 評価業務において、バグを検出した時点で行える分析の確度を上げる。	  
Ø ここから、潜在バグの推測を行う。

検出トリガーの分布

13TM(佐藤正美さんのビジネス分析手法)を用いて、バグ票を構成している属性を可視化	  ②分析効率化の向上

n 評価側での分析の方法を均一化し、課題を視覚化する* 発生要因	  * 市場影響	  * 品質特性	  * 画面系テスト	  * アウトプット・テンプレート
14評価者による発生要因の選び方
軽ドキュメン
ト不正単機能操作
複数機
能の相互作用設計との整合性

他サービ
スとの互
換性

構成変更

重特殊な状
況

• ドキュメントが不完全？
• 単機能でのバグ？
• 複数機能が影響したバグ？
• 設計と実装に矛盾がある？要件漏れている？
• 他システムやサービスと互換性がない？
•HW/SW/サービスの構成を変更したらバグがでた？
• 上記以外の想定外のバグ？
15

発生要因の分布（工程別）
バグ件数
発⽣生要因

100	  90	  80	  70	  60	  50	  40	  30	  20	  10	  0	  検出⼯工程

特殊な状況
構成変更
他サービスとの互換性
設計との整合性
複数機能の相互作用
単機能操作
ドキュメント不正
結合テスト

機能テスト

総合テスト

工程毎の発生要因に着目し、前工程の除去すべき障害の傾16
向を考察して、追加テストの検討材料とする。

市場影響の分析【設計時における⽋欠陥の傾向】ユーザが直接受けるインパクト、リスク 　2014/4/1
①信頼性

影響

・ソフトウェアが意図しない中断をしてしまう
・機能が目的を遂げられない

25

②保守性
・ソフトウェアの保守がしにくい
・予防保守が行われていない

20③要件適合性15

・製品に対する要求が抜け漏れている・製品の機能が顧客の期待と異なっている

10
集計
5

④移行性
・H T からiO S H T へ機能移行する際の課題など⑤有用性
・失敗の診断がつかない

0⑥標準適合性・プロトコル、通信などの標準に適合していない⑦ユーザビリティ
・ユーザが機能を正しく扱えない

ユーザが直接受けるインパクト、
17
リスク	

⑧可能性
・ソフトウェアが既知の要件を満たしながら、演繹的な目的が果たせない⑨文書化の度合い・ソフトウェアの意図する使い方がきちんと文書化されていない

市場影響→品質特性
設定した市場影響の分類結果から自動的に品質特性を設定する	
市場影響

説明(市場影響)	

自動変換 品質特性との結びつき

説明(品質特性)	

設置性

ソフトウェアを使える状態にするまでのしやすさ⇒

使用性

分かりやすさ、使いやすさの度合い

完全性/セキュリティ

ユーザ目的に合った正確な動作を満たすか。システム、プログラム、データなどの悪意のあ⇒る破壊・置き換え

機能性

目的から求められる機能の実装度合い

パフォーマンス

顧客または顧客のエンドユーザが想定するソフトウェアの処理スピード⇒

効率性

目的達成の為に使用する資源の度合い

保守性

ソフトウェアの保守しやすさ。予防保守と是正保守の両方を含む⇒

保守性

保守(改訂)作業に必要な努力の度合い

有用性

失敗(Failure)の診断のしやすさ⇒

保守性

保守(改訂)作業に必要な努力の度合い

移行性

新しいリリースへの移行しやすさ。例えば互換性が失われる場合など⇒

移植性

別環境へ写した歳、そのまま動作する度合い

文書化の度合いソフトウェアの構造や意図する使い方がきちんと文書化されているか⇒

保守性

保守(改訂)作業に必要な努力の度合い

ユーザビリティ

ソフトウェアや文書が理解しやすく正しく目的を遂げられるか⇒

機能性

目的から求められる機能の実装度合い

標準適合性

関連する標準に適合しているか。業界標準、プロトコルなど⇒

機能性目的から求められる機能の実装度合い

信頼性

ソフトウェアが意図しない中断をしないで目的を遂げられるか⇒

信頼性

機能が正常動作し続ける度合い

要件適合性

製品に対する顧客の要求が抜け漏れていたり、期待と違っている⇒

機能性

目的から求められる機能の実装度合い

アクセシビリティ

障碍のある人が情報に継続的に情報にアクセス・利用できるか⇒

使用性

分かりやすさ、使いやすさの度合い

可能性

ソフトウェアが既知の要件を満たしながら意図した目的を果たすか⇒

機能性目的から求められる機能の実装度合い18品質特性→テスト内容検討（派生開発）	
品質特性との結びつき

テストタイプ1

テストタイプ2

テストタイプ3	

テストタイプ4	

機能性

機能テスト

機能部分テスト

機能組合せテスト

手続きテスト

信頼性

負荷テスト

回復テスト

大容量テスト

信頼性テスト

使用性

ユーザビリティテスト

導入テスト

効率性

性能テスト

記憶域テスト

保守性

保守テスト

運用テスト

移植性

データ互換性テスト

環境テスト

テストタイプ5	
適合性テスト

テストタイプ6	
シナリオテスト●品質特性分析の流れ①②③④

開発者テスト結果を評価者テンプレート(ODC分類)にて設定する。
対象バージョン毎に、発生要因・品質特性で分類し、グラフ集計し、傾向を確認する。
対象バージョンで比較し、障害の複雑度を確認し、現行バージョンで影響範囲が大きい障害が出ていないことを確認する。
品質特性の集計結果の傾向を確認し、総合テスト内容を組み立てる。
19

内容検討からのテスト効果（派生開発）	

120	  

バグ数

100	  80	  テスト前半にて大半のバグを見つけられている終盤のランダムテ
ストにて、前verより多く、バグを検出できている。

テスト計画は予定通りに進めることができている

テスト後半での期間・工数の確保が可能となった

60	  

改善前

40	  

改善後

20	  
前バージョンとの比較

0	  
3日目

6日目

9日目 12日目
テスト日計
20

15日目

18日目

GUI	  review	  を用いた画面テストの検証

この属性を利用して画面系テストで検出されたバグを分類集計した21画面テスト  -­‐	  GUI	  review
11月25日設計との整合性外観

11月17日文字列入力デバイス

11月10日ナビゲーション
部品の動き

11月5日
0%	  20%	  40%	  60%	  80%	  100%	  「設計との整合性」や「ナビゲーション」といった重たいバグが解消されていっているのが22わかるアウトプットテンプレート【アウトプットの定型化】	  	  ※だれが分析しても同じ結果となるように手順を定型化する	  	  ※更なる手法の洗練と分析の効率化
市場影響
70	  60	  50	  40	  バグ発生時点の要因と市場影響を開発側に提供することにより、早期に品質の改善へ導いていく。
23

RV:並行互換性
RV:内部ドキュメント30	  RV:同時実行性20	  RV:設計との整合性

10	  

RV:言語依存性0	  RV:ロジックフロー

苦労？した点* これまでバグの内容に関しては、分析らしい分析はしてこなかったため、そんなもんできません、という抵抗が強かった。	  
* 何度か説明会をしたが、ダメ。でも、ひとりがやり始めて、開発部門から、いいじゃん、当たってる、というコメントをもらってから、続く人が出てきました。	  
* やり方を変える(ODCを導入する)のは、抵抗が多いのですが、やはりひとりでも賛同者が出てくると、評価者も変わってきます。	  
24

今後の展開* 活用するODCの属性拡張（分析可能性）* 新規プロジェクトへの予測* 時系列データの蓄積による傾向対策* 評価者用テンプレートの充実* 最終的にはソフトウェアの品質を担保する説明根拠としたい25

ご清聴ありがとうございました

Yoshiya.kojima@avasys.jp

26