自己紹介• 属性
• 川崎の某SIer(エンプラ系)
• 全社技術セクションにいます
• 本業はレビュー(Quality Inspectionでググってください)
• Twitter:@mori_ryuji
• 出没場所
• 「実践アジャイルテスト」読書会
• テスト自動化研究会(STAR)
• WACATE2
講演のきっかけ• 「実践アジャイルテスト座談会」(5/29)打ち上げにて
• 「XP祭りつーイベントがあって」
• (森)「こんなネタあるんすけど」→「ODC」
• 「ぜひやって!」• (森) (゜Д゜)マジデ!!
3
Janet Gregory
アジャイルとバグ票• 「実践アジャイルテスト」におけるバグ票の扱い
• できるだけ書かない
• 解決に時間がかかる時→アジャイルでは少ない
• 市場流出バグ→これはアジャイルでも一緒のはず• 上司「おいどうなってんだ!」
• オレ「こんなこともあろうかと」→【ODC分析結果】サッ
• かこいい!!(^_^)v
4
ODCとは
• Orthogonal Defect Classification
• 直交(交差)欠陥分類
• 定量的分析と定性的分析の両方の性質を併せ持つ技法
• 障害の性質とその数から次のアクションを考えるための技法
例 長所 短所定量的 信頼度成長曲線 実施コスト低い
障害の性質そのものはよくわからない
定性的 原因分析手法 問題の根本的解決を図る 実施コストがかかる
7
ODC略歴• 90年代初頭にIBM Researchで開発
• 以降プロジェクトに適用を重ねる
• 2011年現在 v 5.11
• 開発の中心人物はRam Chillarege氏
• www.chillarege.com
8
最初に• この章の内容はURLからの情報を翻訳、まとめています。疑問点は原文をあたってください。
• http://www.research.ibm.com/softeng/ODC/ODC.HTM
• SQuBOKは少し情報が古いかも
13
ODCの特徴• 8つの属性• 互いに観点の異なる属性に基づく分類• 属性とその取り得る値同士は重なりがない(直交)• 開発プロセス、技術に非依存
• 幅広い検証対象• 要件定義書、標準規約以外のすべての成果物
14
8つの属性一覧時期 属性 Attribute 概要
検出Open
欠陥除去作業 Defect Removal Activities 欠陥を発見したフェーズ検出
Openトリガー Trigger 欠陥を発見する観点
検出Open
インパクト Impact お客様に与える影響
修正Close
ターゲット Target 修正対象の成果物
修正Close
欠陥種類 Defect Type
修正した欠陥の種類修正Close 状態 Qualifier 欠陥種類の状態修正Close
履歴 Age いつ作りこまれたか
修正Close
ソース Source 成果物の出所15
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氏講演より
設計レビュー・コードレビューのトリガー# トリガー 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
状態状態 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
高コストの原因究明
T2中心にバグを発見しているためコスト高
Triggerを見るとT1でつぶすべきバグがT2まで残っているように見える。これが原因
T0:設計・コードレビューT1:単体テスト・結合テストT2:システムテスト 37
設計・コードの完成度
アルゴリズムの誤りが多い【診断】詳細設計の完成度がいまいち
設計変更が必要なバグで、漏れと誤りがほぼ半々【診断】要件定義の漏れが多いか、要件をうまく設計に落とし込めていない
Defect TypeとQualifierの関係
40
実バグ票への適用• とある過去プロジェクトの詳細なバグ票について実施• 約550件のバグ票のうち分類可能は約350件
• 「状態」は漏れと誤りがほぼ同数、無関係はごく少ない• 欠陥種類のトップ3• アルゴリズム• 検証• インターフェイス• 大人の事情で詳細はごめんなさいm(_ _)m
43
• 属性が多い• 属性のとりうる値はさらに多い
• 欠陥除去活動とトリガーの間に妙な依存関係がある• どれに該当するか迷う• テストケース・テストデータの誤りをどう扱うか不明
問題点1:分類自体の難しさ
44
問題点2:バグ票とのマッピングID サマリ 入力 期待結果 出力 重要度 原因
1 ~バグ ボタン押下 Aと表示 Bと表示 高
要件漏れ設計書の記載ミスコーディングミス設計との不整合
.
.
.
状態(Qualifier)
漏れ誤り無関係
修正対象(Target)
要件定義書設計書コード
トリガー(Trigger)
設計との整合性ロジックフロー後方互換性横の一貫性
あらかじめ定義しておく45
問題点3:バグ1件の定義
• 現実のバグ票では同じようなバグを何件にもカウントしていたり、逆に1件でカウントされていたりとばらばら
• 野中先生のSQiP 2010併設チュートリアルより
• 「成果物に含まれる問題の原因部分について1件と数える」• 原因が成果物にある場合→原因1件につき1件
• 原因がプロセスにある場合→修正箇所ごとにカウント• ODC分析の前にバグ票のカウント方式について確認する必要がある
46
まとめ• ODCとは「直交(交差)欠陥分類」
• 定性的分析と定量的分析の両方の長所をとった分析方法
• 8つの属性を持ち、各属性の取り得る値は重ならない(直交)
• 実適用した結果
• 分類自体の困難さ
• バグ票とのマッピングが必要
• 欠陥1件の定義を決めてからカウントする
• うまくいくと欠陥の収束状況やリリース判断、プロジェクトコストの見積もりなどできる
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
告知!•「ソフトウェア病理学」読書会第1回
(9/25)• (株)エクサ 13F セミナールーム
• 「ソフトウェア病理学」で検索。続きはWebで
• 「ソフトウェア開発プロジェクトはなぜ失敗するのか」
• プロジェクトの中断・赤字・低品質• 症状・治療法・予防• これらの話にご興味のある方はぜひ
51
会場
Recommended