ODC入門森　龍二

1

XP祭り2012

自己紹介• 属性

• 川崎の某SIer（エンプラ系）

• 全社技術セクションにいます

• 本業はレビュー(Quality Inspectionでググってください)

• Twitter:@mori_ryuji

• 出没場所

• 「実践アジャイルテスト」読書会

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

• WACATE2

講演のきっかけ• 「実践アジャイルテスト座談会」(5/29)打ち上げにて

• 「XP祭りつーイベントがあって」

• (森)「こんなネタあるんすけど」→「ODC」

• 「ぜひやって！」• (森) (゜Д゜)ﾏｼﾞﾃﾞ!!

3

Janet Gregory

アジャイルとバグ票• 「実践アジャイルテスト」におけるバグ票の扱い

• できるだけ書かない

• 解決に時間がかかる時→アジャイルでは少ない

• 市場流出バグ→これはアジャイルでも一緒のはず• 上司「おいどうなってんだ！」

• オレ「こんなこともあろうかと」→【ODC分析結果】ｻｯ

• かこいい！！(^_^)v

4

目次

• ODCとは

• ODC概要

• 適用してみて

• まとめ

5

ODCとは

6

ODCとは

• Orthogonal Defect Classification

• 直交(交差)欠陥分類

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

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

例 長所 短所定量的 信頼度成長曲線 実施コスト低い

障害の性質そのものはよくわからない

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

7

ODC略歴• 90年代初頭にIBM Researchで開発

• 以降プロジェクトに適用を重ねる

• 2011年現在 v 5.11

• 開発の中心人物はRam Chillarege氏

• www.chillarege.com

8

信頼度成長曲線１件のバグの重みは？

件数はわかるが、今出ているバグの種類と対処法がこれ

ではわからん！

確かに収束方向にあるがこんなフェーズの後半で改善プ

ロセス回せない！

9

原因分析手法これも重み不明

何件ぐらい起こってるの？

いわゆるフィッシュボーン

現場・アプリを知る専門家が必要

10

ODCのイメージバグの種類別に

分類

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

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

11

ODC概要

12

最初に• この章の内容はURLからの情報を翻訳、まとめています。疑問点は原文をあたってください。

• http://www.research.ibm.com/softeng/ODC/ODC.HTM

• SQuBOKは少し情報が古いかも

13

ODCの特徴• ８つの属性• 互いに観点の異なる属性に基づく分類• 属性とその取り得る値同士は重なりがない（直交）• 開発プロセス、技術に非依存

• 幅広い検証対象• 要件定義書、標準規約以外のすべての成果物

14

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

検出Open

欠陥除去作業 Defect Removal Activities 欠陥を発見したフェーズ検出

Openトリガー Trigger 欠陥を発見する観点

検出Open

インパクト Impact お客様に与える影響

修正Close

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

修正Close

欠陥種類 Defect Type

修正した欠陥の種類修正Close 状態 Qualifier 欠陥種類の状態修正Close

履歴 Age いつ作りこまれたか

修正Close

ソース Source 成果物の出所15

欠陥の分類時期

• Opener Section

• 欠陥検出時に確定する情報

• Closer Section

• 欠陥修正時に確定する情報

16

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

• 欠陥を検出した開発フェーズ• 活動ごとに対応するトリガーを変える

• トリガー(Trigger)

• 欠陥を顕在化させた状況、条件、検証の観点• 影響(Impact)

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

17

Error Fault Failure

18

※SQuBOKガイドより

FaultBug

DefectFailure

ErrorMistake

人間の頭の中のある状態

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

Faultが実行され、機能が達成されな

い状態

トリガーとは

19

Fault FailureTrigger

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

レビュー・テスト観点

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

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

欠陥除去活動とトリガー

欠陥除去活動

トリガーのセットレビュー用

設計レビューコードレビュー機能テストシステムテスト

20

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

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

設計レビュー・コードレビューのトリガー＃ トリガー 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 想定外または言及されていないシステムの振る舞い21

レビューのトリガー

レビュー対象

相互作用する仕様

前工程の設計書

後工程の設計書

前工程の設計書

レビュー対象

相互作用する仕様

後工程の設計書

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

レビュー対象外

レビュー対象外

レビューワー

1:設計整合性

1:設計整合性

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

3:後方互換性

4:並行互換性

6:内部ドキュメント

8:副作用

22

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

単純パス Simple Path

いわゆるホワイトボックステストによって見つかる欠陥。市場に出たバグを含まないが、顧客がビジネスパートナーやベンダーでコードに明るい場合はここに分類される。（例)case文のdefaultを通そうと思ったがdefaultがそもそも存在していなかった

複合パス Complex Path

ホワイトボックス・グレーボックステストで見つかるバグ。いくつかの分岐やテスト条件が組み合わさって起こった者。Simple Pathに含まれない通常の市場バグはこれ。(例)ある箇所で使うはずのメモリーを別の場所で解放してしまった

23

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

カバレッジ Coverageブラックボックステストで、一つの機能をパラメータなしまたは単一のパラメータで呼び出した場合の欠陥

組み合わせ Variationブラックボックステストで、一つの機能を入力やパラメータの組み合わせで呼び出した場合の欠陥

連続処理 Sequenceブラックボックステストで、複数の機能を一連の流れに従って呼び出した場合の欠陥

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

24

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

負荷・ストレス Workload/Stress

システムをリソースの限界またはその前後の環境下で使ったときの欠陥

回復・例外 Recovery/Exception

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

起動・再起動 Startup/Restart

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

ハードウェア設定 Hardware Configuration

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

ソフトウェア設定 Software Configuration

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

ブロックテスト Blocked Test負荷テスト中、限界以下の負荷でシナリオテストを実行できない。ただし顧客が報告するバグは含まない

25

影響(Impact)影響 Impact 内容設置性 Installability ソフトウェアを使える状態にするまでのしやすさ

完全性/セキュリティ Integrity/Security システム、プログラム、データなどの悪意のある破壊・置き換え・公開

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

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

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

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

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

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

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

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

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

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

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

ImpactとISO 9126Installability

Integrity/Security

Performance

Maintenance

Serviceability

Migration

Documentation

Usability

Standards

Reliability

Requirements

Accessibility

Capability9126にマップできそう

→標準なのでこちらに準拠すべき？27

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

• 欠陥を修正した成果物

• 欠陥種類(Defect Type)

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

• 状態(Qualifier)

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

• 履歴(Age)

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

• ソース(Source)

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

28

修正対象修正対象 Target 内容

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

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

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

ビルド/パッケージ Build/Package

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

ドキュメント Information Development

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

29

欠陥種類欠陥種類 Defect Type 内容代入/初期化 Assignment/

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

検証 Checkingパラメータや条件文のデータミス。条件文はif文やfor/while

ループの出口判定を含む

アルゴリズム/メソッド

Algorithm/Method

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

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

Function/Class/Object

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

タイミング/直列化

Timing/Serialization

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

インターフェイス/O-O

メッセージInterface/O-O

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

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

30

トリガーと欠陥種類

31

Fault Failureトリガー

欠陥検出のよしあし

要件定義 設計 実装 テスト

欠陥種類作り込み工程

状態状態 Qualifier 内容

漏れ Missingある状態が「ない」ことによる欠陥例：代入文がない

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

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

32

履歴履歴 Age 内容

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

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

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

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

33

ソースソース Source 内容

内製 Developed In-House

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

再利用 Reused From Library

既存のライブラリを使った部分にある欠陥。ライブラリの使い方が誤っていたか、ライブラリ自身の欠陥

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

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

34

ODCでわかること参考資料

http://www.research.ibm.com/softeng/ODC/ODCEG.HTM

35

バグの収束判定

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

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

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

36

高コストの原因究明

T2中心にバグを発見しているためコスト高

Triggerを見るとT1でつぶすべきバグがT2まで残っているように見える。これが原因

T0:設計・コードレビューT1:単体テスト・結合テストT2:システムテスト 37

バグはどこにあるか？Ageの分布

Base(潜在バグ)が大半を占める。前ページと合わせて考えると・本体部分に多くの積み残しバグ・一旦テストを中断して本体部分の既存バグ改修を優先すべき

38

真の顧客満足とは？製品Aは仕様バグ(Capability)がほとんど

Impactの分布

製品Bは信頼性(Reliablity)と仕様バグがほぼ同数

究極の選択？！39

設計・コードの完成度

アルゴリズムの誤りが多い【診断】詳細設計の完成度がいまいち

設計変更が必要なバグで、漏れと誤りがほぼ半々【診断】要件定義の漏れが多いか、要件をうまく設計に落とし込めていない

Defect TypeとQualifierの関係

40

維持管理の戦略システムテストのトリガー分布

起動、復旧、設定に関するバグは比較的初期に収束する

性能問題はカットオーバー後1年以上経って現れる

運用ポリシーの参考にする

１年目 ２年目

41

適用してみて

42

実バグ票への適用• とある過去プロジェクトの詳細なバグ票について実施• 約550件のバグ票のうち分類可能は約350件

• 「状態」は漏れと誤りがほぼ同数、無関係はごく少ない• 欠陥種類のトップ３• アルゴリズム• 検証• インターフェイス• 大人の事情で詳細はごめんなさいm(_ _)m

43

• 属性が多い• 属性のとりうる値はさらに多い

• 欠陥除去活動とトリガーの間に妙な依存関係がある• どれに該当するか迷う• テストケース・テストデータの誤りをどう扱うか不明

問題点１:分類自体の難しさ

44

問題点２：バグ票とのマッピングID サマリ 入力 期待結果 出力 重要度 原因

1 ～バグ ボタン押下 Aと表示 Bと表示 高

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

.

.

.

状態(Qualifier)

漏れ誤り無関係

修正対象(Target)

要件定義書設計書コード

トリガー(Trigger)

設計との整合性ロジックフロー後方互換性横の一貫性

あらかじめ定義しておく45

問題点３：バグ１件の定義

• 現実のバグ票では同じようなバグを何件にもカウントしていたり、逆に１件でカウントされていたりとばらばら

• 野中先生のSQiP 2010併設チュートリアルより

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

• 原因がプロセスにある場合→修正箇所ごとにカウント• ODC分析の前にバグ票のカウント方式について確認する必要がある

46

まとめ

47

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

• 定性的分析と定量的分析の両方の長所をとった分析方法

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

• 実適用した結果

• 分類自体の困難さ

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

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

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

48

資料• 後日Slideshareに上げます

• WACATE向け勉強会資料

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

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

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

49

今後の予定• 手近にあるレビュー結果へのODC適用

• 時系列データの取得• 時間的変化からプロジェクトへの提言へ• BTS・ITSへのODCスキーム組み込み

• 分析結果グラフの自動生成など• ODC普及活動

50

告知！•「ソフトウェア病理学」読書会第１回

(9/25)• （株）エクサ 13F セミナールーム

• 「ソフトウェア病理学」で検索。続きはWebで

• 「ソフトウェア開発プロジェクトはなぜ失敗するのか」

• プロジェクトの中断・赤字・低品質• 症状・治療法・予防• これらの話にご興味のある方はぜひ

51

会場

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

52