ODC(直交⽋陥分類)概説(公開⽤)

2015/2/21 株式会社エクサ 森 ⿓⼆

1

JaSST Tokyo 2015

⾃⼰紹介•エンプラ系SIerで第三者レビュー

•最近は品質教育、品質分析⽀援

•その他

•SQiP研究会

•テスト⾃動化研究会(STAR)

•テスト⾃動化の本出ました→

•WACATE

•ソフトウェア病理学NEO

2

本⽇お持ち帰りいただくこと

•現場改善のための⽋陥分類

•ODCという⼀つの考え⽅

•直交する属性やその値に分解する

•定性・定量分析の組みあわせの妙味

3

⽬次•ODCとは

•ODC概要

•ODCの使い⽅

•適⽤事例

•適⽤のコツ

•まとめ

4

ODCとは

5

ODCとは

•Orthogonal Defect Classification

•直交(交差)⽋陥分類

•定量的分析と定性的分析の両⽅の性質を併せ持つ技法

•⽋陥の性質とその数から次のアクションを考えるための技法

例 ⻑所 短所定量的 信頼度成⻑曲線 実施コスト低い 障害の性質そのものは

よくわからない

定性的 原因分析⼿法 問題の根本的解決を図る 実施コストがかかる

6

ODCのイメージ⽋陥の種類別に分類

数えられる＝集中している箇所が明確

傾向がわかれば早期に対処可能

7

ODC概要

8

ODCの特徴•８つの属性(⼀部９つ）

•互いに観点の異なる属性に基づく分類

•属性とその取り得る値同⼠は重なりがない（直交）

•開発プロセス、技術に⾮依存

•幅広い検証対象

•要件定義書、標準規約以外のすべての成果物

9

８つの属性時期 属性 Attribute 概要

検出 Opener

⽋陥除去活動 Defect Removal Activities ⽋陥を発⾒したフェーズ

トリガー Trigger ⽋陥を発⾒する観点インパクト Impact お客様に与える影響

修正 Closer

ターゲット Target 修正対象の成果物

⽋陥種類 Defect Type 修正した⽋陥の種類

状態 Qualifier ⽋陥種類の状態

履歴 Age いつ作りこまれたかソース Source 成果物の出所

10

⽋陥検出時(Opener) ⽋陥修正時(Closer)⽋陥検出活動 トリガー 影響 修正対象 ⽋陥種類 状態 履歴 ソース

Design Review Design Conformance Installability

Design/Code

Assignment/Initialization Missing Base

Developed In-House

Code Inspection

Logic/Flow Integrity/Security

Checking Incorrect New Reused From Unit Test Backward Compatibility Performance Algorithm/Method Extraneous Rewritten Outsourced

Function Test Lateral Compatibility Maintenance Function/Class/Object

Refixed Ported

System Test Concurrency Serviceability Timing/Serialization

Internal Documents Migration Interface/O-O Messages

Language Dependency Documentation RelationshipSide Effect Usability

Rare Situations StandardsSimple Path Reliability

Complex Path Requirements(Test) Coverage Accessibility(Test) Variation Capability

(Test) Sequencing(Test) InteractionWorkload/Stress

Recovery/ExceptionStartup/Restart

Hardware ConfigurationSoftware Configuration

Blocked Test11

Opener Sectionの属性•⽋陥除去活動(Defect Removal Activity)

•⽋陥を検出した開発フェーズ

•活動ごとに対応するトリガーを変える

•トリガー(Trigger)

•⽋陥を顕在化させた状況、条件、検証の観点

•影響(Impact)

•お客様に与える影響の種類(影響度ではない)

12

トリガーについて

13

Error Fault Failure

14

※SQuBOKガイドより

Fault Bug

DefectFailure

Error Mistake

⼈間の頭の中 のある状態

Errorを実装したもの まだ実⾏されない

Faultが実⾏され、機能が達成さ

れない状態

トリガーとは

15

Fault FailureTrigger

・電源の抜けを探す ・リモコンの電池を替える ・本体の故障を疑う

何を⾒逃してしまったか、を表す

テレビが点かない・電源が抜けてた ・電池切れ ・基盤が壊れてた

2011/12/7 Ram Chillarege⽒講演より

⽋陥除去活動とトリガー

⽋陥除去活動

トリガーのセット コードレビュー⽤

設計レビュー コードレビュー

単体テスト 機能テスト

システムテスト

16

トリガーのセット 機能テスト⽤

トリガーのセット システムテスト⽤

トリガーのセット 設計レビュー⽤

トリガーのセット 単体テスト⽤

ある程度絞ると分類しやすい？

設計レビュー・コードレビューのトリガー＃ トリガー Trigger 内容

1 設計との整合性 Design Conformance

設計書やコードが前後の⼯程の成果物・開発標準と⽭盾を起こしている、要件が漏れている・曖昧である

2 ロジックフロー Logic/Flow ⾔語知識から論理・データの流れに⽭盾がある

3 後⽅互換性 Backward Compatibility

過去のバージョンの機能が損なわれている

4 並⾏互換性 Lateral Compatibility

検査対象のシステムとやりとりする他システム、サービス、コンポーネントとの間に⽭盾がある

5 同時実⾏性 Concurrency 共有リソースをアクセスする仕組みがない

6 内部ドキュメント Internal Documents

内部ドキュメント（⽬次と内容、コメントとソースコードなど）が不正、不整合、不完全である

7 ⾔語依存性 Language Dependency

⾔語固有のコーディング標準や効率的な実装⽅法に準拠していない

8 副作⽤ Side Effect レビュー対象の設計書やコードが対象外へ及ぼす影響がある

9 特殊な状況 Rare Situations

想定外または⾔及されていないシステムの振る舞い17

レビュートリガー

レビュー対象

相互作⽤するコンポーネント

前⼯程の設計書

後⼯程の設計書

前⼯程の設計書

レビュー対象

相互作⽤するコンポーネント

後⼯程の設計書

現バージョン 前バージョン

レビュー対象外

レビュー対象外

1:設計整合性

1:設計整合性

3:後⽅互換性

4:並⾏互換性

6:内部ドキュメント

8:副作⽤

18

レビューワー

2:ロジックフロー 5:同時実⾏性 7:⾔語依存性 9:特殊な状況

単体テストのトリガートリガー Trigger 内容

単純パスSimple Path

いわゆるホワイトボックステストによって⾒つかる⽋陥。市場に出たバグを含まないが、顧客がビジネスパートナーやベンダーでコードに明るい場合はここに分類さ

れる。 （例)case⽂のdefaultを通そうと思ったがdefaultが

そもそも存在していなかった

複合パスComplex

Path

ホワイトボックス・グレーボックステストで⾒つかるバグ。いくつかの分岐やテスト条件が組み合わさって起こった者。Simple Pathに含まれない通常の市場バグは

これ。 (例)ある箇所で使うはずのメモリーを別の場所で解放し

てしまった19

機能テストのトリガートリガー Trigger 内容

カバレッジ(Test)

Coverage

ブラックボックステストで、⼀つの機能をパラメータなしまたは単⼀のパラメータで呼び出した場合の

⽋陥

組み合わせ(Test)

Variationブラックボックステストで、⼀つの機能を⼊⼒やパ

ラメータの組み合わせで呼び出した場合の⽋陥

連続処理(Test)

Sequencingブラックボックステストで、複数の機能を⼀連の流

れに従って呼び出した場合の⽋陥

相互作⽤(Test)

Interaction

ブラックボックステストで、コードの2つ以上の塊の間でやりとりをしたときの⽋陥。⼀つの機能を独⽴に実⾏すると正常終了するが組み合わせると失敗するときだけに使う

20

システムテストのトリガートリガー Trigger 内容

負荷・ストレスWorkload/

Stressシステムをリソースの限界またはその前後の環境下で

使ったときの⽋陥

回復・例外 Recovery/Exception

例外を発⽣させるコードやリカバリコードが正常に動作しない。失敗（Failure）そのものではなく回復⼒

起動・再起動 Startup/Restart

シャットダウンやシステムの失敗から回復した後に起動・再起動する時の⽋陥

ハードウェア設定 Hardware Configuration

特定のハードウェア設定下で正常動作しない

ソフトウェア設定 Software Configuration

特定のソフトウェア設定下で正常動作しない

ブロックテスト Blocked Test 何らかの原因でテストシナリオを実⾏できない。ただし顧客が報告するバグは含まない

21

影響(Impact)•顧客が直接受けるインパクト、リスク

•分析で最初に注⽬すべきポイント

•いわゆる⼤・中・⼩では表さないところがODCらしさ

•ISO 9126, 25010などの品質特性で表してもいいが、⾸尾⼀貫させる必要がある

22

影響(Impact)影響 Impact 内容

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

完全性/セキュリティ Integrity/Security

システム、プログラム、データなどの悪意のある破壊・置き換え・公開

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

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

有⽤性 Serviceability 失敗(Failure)の診断のしやすさ

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

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

ユーザビリティ Usability ソフトウェアや⽂書が理解しやすく正しく⽬的を遂げられるか

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

信頼性 Reliability ソフトウェアが意図しない中断をしないで⽬的を遂げられるか

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

アクセシビリティ Accessibility 障碍のある⼈が情報に継続的に情報にアクセス・利⽤できるか

可能性 Capability ソフトウェアが既知の要件を満たしながら意図した⽬的を果たすか

23

Closer Sectionの属性•修正対象(Target)

•⽋陥を修正した成果物

•⽋陥種類(Defect Type)

•⽋陥の種類(修正対象に依存)

•状態(Qualifier)

•「⽋陥種類」が今どういう状態なのかを⽰す

•履歴(Age)

•⽋陥のあった成果物がいつ作成されたか

•ソース(Source)

•⽋陥のあった成果物の出所(内製、派⽣開発、アウトソースなど)

24

修正対象修正対象 Target 内容

要件定義書 Requirements 要件定義書を直した場合

設計書 Design （基本・詳細、外部・内部）設計書を直した場合

コード Code コードを直した場合

ビルド/パッケージ

Build/Package ビルドスクリプト、ライブラリ、変更管理・バージョン管理システムなどを直した場合

ドキュメント Information Development

ユーザーガイド、インストールマニュアル、オンラインヘルプを直した場合

⾔語サポート National Language Support 英語以外の⾔語処理の⽋陥を修正した場合

25

⽋陥種類⽋陥種類 Defect Type 内容

代⼊/初期化 Assignment/Initialization

変数の代⼊ミス・初期化漏れ 複数の変数への代⼊ミスはアルゴリズムへ

検証 Checking パラメータや条件⽂のデータミス。条件⽂はif⽂やfor/whileループの出⼝判定を含む

アルゴリズム/メソッド

Algorithm/Method

設計変更なしでアルゴリズムやデータ構造の変更だけで修正できる効率の悪いコード、または⽋陥

関数/クラス/オブジェクト

Function/Class/Object

正式な設計変更が必要な⽋陥。重要な機能、UI、インターフェイス、グローバルデータ構造の変更

タイミング/直列化 Timing/Serialization

共有リソースを直列化していない、直列化対象の間違い、直列化の技術を間違えた

インターフェイス/O-Oメッセージ

Interface/O-O Messages

モジュール・オブジェクト間などのコミュニケーションミス(動的やりとり?)

関連 Relationship プロシージャ間・データ構造・オブジェクトの関連ミス(静的な関連?)

26

トリガーと⽋陥種類

27

要件定義

顧客要求

レビュー

設計 レビュー

要件定義書

設計書

実装 レビュー

コード

デバッグテスト

製品

トリガー： 何を⾒逃したか

⽋陥種類： どんな⽋陥が作り

込まれたか

レビュー・ テストの問題点

開発⼯程の問題点

状態状態 Qualifier 内容

漏れ Missing ある状態が「ない」ことによる⽋陥 例：代⼊⽂がない

誤り Incorrect ある状態が「誤っている」ことによる⽋陥 例：判断⽂の値が間違っていた

無関係 Extraneousドキュメントやソースと関係がない何かによる⽋陥 例：設計書に現在の製品と関係がない章があり、削

除対象である

28

履歴履歴 Age 内容

本体 Base 現在のプロジェクトによる修正部分になく、標準ライブラリでもない潜在⽋陥

新規 New 新規作成部分にある⽋陥

書き直し Rewritten 古い機能を設計・実装し直した部分に混⼊された⽋陥

再修正 Refixed ⽋陥を改修しようとした部分に持ち込まれた⽋陥

29

ソースソース Source 内容

内製 Developed In-House

組織の開発チームによって開発された部分にある⽋陥

再利⽤ Reused From Library

既存のライブラリを使った部分にある⽋陥。ライブラリの使い⽅が誤っていたか、ライブラリ⾃⾝の⽋陥

アウトソース Outsourced ベンダー開発部分にある⽋陥

転⽤ Ported 異なる環境で有効だったソースを転⽤した部分にある⽋陥

30

ODC Extensions (GUI)

31

GUIの属性⼀覧⽋陥検出時(Opener) ⽋陥修正時(Closer)

⽋陥検出活動

トリガー 影響 修正対象 ⽋陥種類 状態 履歴 ソース

GUI Review

Design Conformance

Design/Codeと

同じ

Design/Code

Design/Codeと同じ

Widget/Icon AppearanceScreen Text/Characters

Input DevicesNavigation

Widget/GUI Behavior

※ここでは視覚的な側⾯だけで、背後の機能性は問題にしない

32

GUI固有部分

GUIのトリガー＃ トリガー Trigger 内容

1 設計との整合性 Design Conformance

GUI設計ドキュメントとの整合性

2 画⾯部品の外観 Widget/Icon Appearance

ウィジェットやアイコンの外観(間違った⾊使い、⼤きすぎる、など)に関する⽋陥

3 ⽂字列 Screen Text/Characters

⽂字列(例：ボタンラベルの綴り)の誤り

4 ⼊⼒デバイス Input Devices マウス、キーボード、タッチスクリーンなどの⼊⼒デバイスに関する⽋陥

5 ナビゲーション Navigation ウィンドウ、メニュー、画⾯部品間のナビゲート時に⾒つかる⽋陥

6 画⾯部品の動きWidget/GUI

Behavior

ウィジェットやアイコンの動きに関する⽋陥 【例】ウィジェットにフォーカスが当たらない、リストボックスの複数選択、ヘルプボタンが効かない

33

ODCの使い⽅

34

⽋陥の収束判定

信頼度成⻑曲線上で 収束傾向に⾒えても...

「機能」に関する⽋陥は収束していない。

Period2までに把握して対策を打てる

35

適⽤事例

36

事例２：保守案件の改善提案•開発から保守に移⾏した案件で、お客様から現状のチケットを使ってプロア

クティブな対応が取れないかと求められた

•ODCを実施してみた

•保守なのでCloserは簡単だが、Openerが埋まらない

•トリガーは受動的（監視システムからのエラー検知など）なものを独⾃定義

•優先度、影響度、発⽣頻度など、従来の分類と併⽤

•全体としては使えそうなイメージ

•Closerはそのまま使えた

•トリガーはどうやったら気づきやすいかのきっかけにはなりそう

•もっとOpenerを優先度判定に使いたかった

37

適⽤のコツ

38

•分類⾃体の難しさ

•属性とそのとりうる値が多い

•どれに該当するかの選択の難しさ

•テストケース・テストデータの誤りをどう扱うか不明

•基本的には数をこなすしかない？

•数が増えてくると1件あたりのぶれが少なくなる

コツ１:数をこなす

39

コツ2：バグ１件の定義•バグ1件の数え⽅を定義しよう！

•現実のバグ票ではばらばら

•同じようなバグを何件にもカウント

•１件に複数のバグを集約

•参考となる考え⽅

•「成果物に含まれる問題の原因部分について１件と数える」

•原因が成果物にある場合→原因１件につき１件

•原因がプロセスにある場合→修正箇所ごとにカウント

40

「SQiPシンポジウム2010併設チュートリアル」（野中 誠）より

コツ3：バグ票とのマッピングID サマリ ⼊⼒ 期待結果 出⼒ 重要度 原因

1 〜バグ ボタン押下 Aと表⽰ Bと表⽰ ⾼

要件漏れ設計書の記載ミスコーディングミス設計との不整合

.

.

.

状態(Qualifier)漏れ

誤り無関係

修正対象(Target)要件定義書

設計書コード

トリガー設計との整合性ロジックフロー

後⽅互換性横の⼀貫性あらかじめ定義しておく

41

まとめ

42

ODCまとめ•ODCとは「直交（交差）⽋陥分類」

•定性的分析と定量的分析の両⽅の⻑所をとった分析⽅法

•８つの属性と、各属性の取り得る値は重ならない（直交）

•適⽤のコツ

•数をこなす

•⽋陥１件の定義を決めてからカウントする

•バグ票とのマッピングが必要

•うまくいくと⽋陥の収束状況やリリース判断、プロジェクトコストの⾒積もりなどできる

43

参考資料(1/2)•IBM ResearchのODCサイト

•http://researcher.watson.ibm.com/researcher/view_project.php?id=480

•ODC 5.2

•http://researcher.watson.ibm.com/researcher/files/us-pasanth/ODC-5-2.pdf

•ODC Extensions

•http://researcher.watson.ibm.com/researcher/files/us-pasanth/ODC-5-2-Extensions.pdf

•Ram Chillarege⽒のサイト

•http://www.chillarege.com/

•JaSST ʼ11 関⻄「〜テスト結果は、まだまだ活かせるのではなイカ!?〜」

•http://jasst.jp/archives/jasst11w.html#workshop

•「ODC分析による⽋陥除去と品質成熟度の可視化」⼭崎 隆(オリンパスソフトウェアテクノロジー)

•http://www.ipa.go.jp/files/000040829.pdf

44

参考資料(2/2)•SQuBOKユーザ会ODC勉強会発表資料(2014/1)

•http://www.slideshare.net/mori_ryuji/odc-2014123

•ODCテンプレート(Excel)

•https://drive.google.com/file/d/0B-liQb1TH1GJYVE2eElPVENJMEE/view?usp=sharing

•バグ票ワーストプラクティスに寄稿した論⽂

•http://www.slideshare.net/mori_ryuji/odc-14036416

45

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

46