S4）セッション「これからの“バグ”の話をしよう」
JaSST‘13 Kyushu

ソフトウェアテストシンポジウム 2013 九州
2013年11月1日(金)1© 2013 IBM Corporation

はじめに
概要:
欠陥エンジニアリング
欠陥エンジニアリングという未踏分野が注目されています。
欠陥エンジニアリング
未だに欧米ではエンジニアリング研究が進んでいない「欠陥」を科学することで、開発者、PM、経営者等にとって様々な利得について考察します。
今後のIT産業発展の一翼を担う欠陥エンジニアリングの技術について歴史的俯瞰
歴史的俯瞰、今までなぜ普及しなかったのか
なぜ普及しなかったのか、そ歴史的俯瞰
なぜ普及しなかったのかしてどこに向かうべきなのか？を議論し、九州から日本全国と世界に向けて新しいレビューやテストの概念を提案します。

ルール:
Lots of Parking… （寄り道をたくさん）– Raise your hands• たくさん発言してください

2

IBM Confidential: NDA© 2013 IBM Corporation

Chapter #1
Dawn of Defectology（欠陥学の黎明）© 2013 IBM Corporation

1976 : L.L. Lehman : リーマンの法則

テスト箇所「進化するシステムは特別な取り組みをしない限り、複雑さは上昇し続ける」という法則「進化するシステムは特別な取り組みをしない限り、複雑さは上昇し続ける」という法則

点の数（＝コード本数）

線の数（＝テスト箇所数）n ( n -1 )2

複雑度＝テスト工数はプログラムを追加する度に指数関数的に増加する

３

４３６

５
PGM本数１０© 2013 IBM Corporation

1978～1989 : Donald Ervin Knuth : The Errors of TeX
 「アルゴリズムの神様」と呼ばれるドナルド E. クヌース博士がプログラム進化の事例研究として発表した1989年の論文。
 組版システム「TeX」の１０年に渡る開発を通じたプログラム進化と、開発中に得られた850項目のエラーロ
グを分析し、15のカテゴリ分類を提示した最初の論文

Source: Software – Practice & Experience, eds. Cambell, J. and Comer, D., Vol.19, No.7, 1989, PP. 607-685© 2013 IBM Corporation

賢者への道とはそう それは平凡で言うのは簡単
誤りを犯し
そして 誤りを犯しまた 誤りを犯すこと
しかし その誤りを減らし
そして 誤りを減らし誤りを減らすこと

Source: Piet Hein, Grooks, MIT Press 1966
© 2013 IBM Corporation

The history of “Defect Engineering” #1 : The Errors of TeX
15種類のカテゴリー（最初のバグ分類）
種類のカテゴリー（最初のバグ分類）
A. アルゴリズムの不首尾（an algorithm awry)
B. 不手際または台無し（a blunder or botch）
C. 一貫性または明快さのための美文書化（a clean-up for consistency or clarity)
D. データ構造の崩壊（a data structure debacle)
E. 効率の増強（an efficiency enhancement）
F. 忘れられた機能（a forgotten function）
G. 一般化または能力の成長（a generalization or growth of ability）
I. 対話性の改善（an interactive improvement)
L. 言語の責任（a language liability)
M. モジュール間の不適当な組合せ（a mismatch between modules）
P. 移植性の増進（a promotion of portability）
Q. 品質の追求（a quest for quality)
R. 堅牢性の強化（a reinforcement of robustness）
S. 想定外のシナリオ（a surprising scenario)
T. ちょっとした誤植（a trivial typo)© 2013 IBM Corporation

The history of “Defect Engineering” #1 : 欠陥は進化する欠陥に対する最初の所見
 簡単に修正できるタイプの欠陥 （Level1））– 正しく掛けていたが実際のタイピングで誤る（T）– 正しく考えていたが書くときに誤る(B)– 正しく知っていたが考慮するのを忘れる（F）– ツール（Ｌ）– 仕様の知識不完全（Ｍ）

 Level１より一段難しい問題 （Level2））– アルゴリズム欠陥（A）– データ構造上の誤り（D）

 機能強化する派生で増加する欠陥 （Level3）– 美文書化（C）– 効率性向上（E）– 一般化（G）– 対話性（I）– 移植性（P）– 品質（Q）

TeX78のタイプ別エラー数累積のタイプ別エラー数累積© 2013 IBM Corporation

Boris Beizerによる分類（1983年） 全欠陥数に対する欠陥分類毎の比率例
Beizerによる分類：による分類： 番号付けと出現頻度に着目した分類 バグの分類について述べたものである。当初，IEEEのバグの分類に関する標準化原案(ANSI87E)を採用しようとしたが，網羅範囲が不十分であったために断念した。
 ここでは，バグを4桁の数字に使ったポイントシステムで分類する。たとえば，「1234.1.6」である。このポイントシステムに拡張性を持たせるために「x」という記号を設ける。「x」は，今後バグの分類を拡張するときのための予備として用いる。たとえば，開発したソフトウェアの構造不良

3xxx

処理不良

32xx

数式評価不良

322x

演算不良

3222
3222.1

誤操作 それぞれの分類の最後のコードは，つねに9である。たとえば，9xxx，39xx，329x，3229，3226.9である。より詳
細な適切な分類が出来ない場合に，ここに分類するためのものである。 たとえば，以下のとおりである。
9xxx：

未分類の「不良」

39xx：

未分類の「構造不良」

329x

：

未分類の「処理不良」

3229

：

未分類の「数式評価不良」

3222.9 ：未分類の「演算不良」

 この分類では，いろいろ異なるさまざまな資料からデータを収集できるようにするために，このような数字によるポイントシステムを採用することにした。
Source: Boris Beizer, “Software Testing Techniques”, Van Nostrand Reinhold; 1990 ISBN 978-0442206727「ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために」ボーリス バイザー (著), Boris Beizer (原著), 小野間 彰 (翻訳), 山浦 恒央 (翻訳) , 1994, ISBN-13: 978-4822710019© 2013 IBM Corporation事例） Boris Beizerによる分類（1983年） によって何がわかるか？

© 2013 IBM Corporation

Chapter #2
欠陥とはなにか？

© 2013 IBM Corporation

欠陥を測定・分析することは必要。しかし限界も存在欠陥を定量的側面だけでは管理するには限界がある
欠陥を定量的側面だけでは管理するには限界がある 欠陥は「消し去るもの」「あってはならないもの」「憎むべきもの」
 今目の前にある欠陥を除去すればいい（=“討ち取る”もの）→ 本当に除去するだけでよいのか？

そもそも定量的に欠陥が測定できた時点は「混入後」 ＝ 手遅れに！！
組織で発生頻度の高い欠陥ベスト10があげられますか？
その頻出欠陥１０種類のうち、再発確率が最も高いのは？
その１０種類の欠陥のうち同一原因のものは？
© 2013 IBM Corporation

そもそも、欠陥とは何か？
 メモリーリークの例：
State1：
コードに欠陥が埋め込まれた状態

State2：
コードがメモリ上で実行された状態

コード中にメモリを解放するコードがない・抜けた状態

コードがメモリにロードされ処理が終わり、わずかに解放されないメモリが残る状態

State3：
リソースが食いつぶされマシンが停止した状態

メモリ資源が徐々に食いつぶされ（＝リークし）、マシンが停止する状態

欠陥に関する厳密な定義・ノウハウが伝承されていない典型例© 2013 IBM Corporation

欠陥学とは？
欠陥学（Defectology）とは、欠陥の混入確認・存在確認や、各種ソフトウェア開発と）とは、欠陥の混入確認・存在確認や、各種ソフトウェア開発と欠陥学（検査を助けるための欠陥情報と標本の提供を目的とする研究です。

標本化１） 欠陥標本の作成とその技術
欠陥標本の作成とその技術 （固定・抽象化・分類・保存）（固定・抽象化・分類・保存）
１）

標本利用

２） 欠陥標本を利用した検査の実践
欠陥標本を利用した検査の実践
２）

欠陥の予測と予防３） 欠陥標本を利用した障害予測・障害予防の実践
欠陥標本を利用した障害予測・障害予防の実践
３）

欠陥ｴﾝｼﾞﾆｱの育成

４） 欠陥標本を利用した技術者の育成と「悪さの伝承」
欠陥標本を利用した技術者の育成と「悪さの伝承」
４）

14© 2013 IBM Corporation

“悪さの知識” = 欠陥知識移転の重要性

 欠陥情報は、誰かに伝達・伝承して初めて意味を持ちます。様々な「欠陥のユーザー」は、発見者が伝達した欠陥情報から利得を得ます
１）他の検査者
１）他の検査者

欠陥（Defect）
）

検出！
検出！

移教育・
転

２）IT技術者
２）２）IT技術者
技術者
２） 技術者

共有化・開公
除 去・ 警戒指示
検査者・QE
検査者・または発見者

15

報告・ 意思決定
促進

３）開発者
３）開発者

４）経営者
４）経営者

© 2013 IBM Corporation従来のバグ票でダメな理由、この研究をしているか
１）プロジェクトで発生する個々のバグ票は、プロジェクト固有条件を含むため欠陥の「インスタンス」である
２）現場プロジェクトでいつでも観察・参照可能な欠陥情報として、欠陥マスターの存在が必要不可欠

 プロジェクトと欠陥の関係を整理すると次のような関係。
1.

プロジェクトには複数の欠陥が発生する

2.

一つの欠陥は複数のプロジェクトで検出される

プロジェクトプロジェクトOperation
Attributes

＊

欠陥
欠陥
Operation＊

Attributes

 上記多対多
上記多対多の関係は、１対１関係の「関連エンティティ」をおくと整理できる
多対多の関係は、１対１関係の「関連エンティティ」をおくと整理できる
1. プロジェクトと欠陥の間に「プロジェクト欠陥」エンティティを設定。
2. 各１対多の関係でリレーションを整理②①

プロジェクトプロジェクトOperation
Attributes

1＊

プロジェクト欠陥
プロジェクト欠陥
Operation
Attributes

＊

1

欠陥
欠陥
Operation
Attributes

プロジェクト欠陥（①）をどれほど多量に集めても、観察・参照・利用可能できない
プロジェクト欠陥（①）をどれほど多量に集めても、観察・参照・利用可能できない欲しいのは②の「欠陥マスター」情報。
欲しいのは②の「欠陥マスター」情報。固定化・抽象化・整理
欲しいのは②の「欠陥マスター」情報。固定化・抽象化・整理されなくては参照できない
固定化・抽象化・整理されなくては参照できない© 2013 IBM Corporation

16欠陥情報の記録 ： 従来の欠陥記録とマスターDBの必要性
 従来、開発中・改変時に関わらず「バグ報告書」として欠陥情報が記録されてきました。
しかし、本来は欠陥をインスタンス情報として捉えてはいけません。

従来の欠陥記録
従来の欠陥記録==バグ報告書
バグ報告書
ソフトウェアのライフサイクルにおける特定の品質特性のソフトウェアのライフサイクルにおける特定の品質特性の一静的断面をあらわす情報の塊
一静的断面をあらわす情報の塊

将来の欠陥記録
将来の欠陥記録==欠陥のマスター情報記録
欠陥のマスター情報記録
不連続に変化するソフトウェア品質において、期待と現状の不連続に変化するソフトウェア品質において、期待と現状のGAPが大きくなった時に欠陥を固定化・抽象化・整理して保存が大きくなった時に欠陥を固定化・抽象化・整理して保存GAPが大きくなった時に欠陥を固定化・抽象化・整理して保存が大きくなった時に欠陥を固定化・抽象化・整理して保存
し誰かに改善・受容を促すための情報群
し誰かに改善・受容を促すための情報群© 2013 IBM Corporation

参考） 医学との対比

医学には医学には．．．
医学には．．．

IT業界には業界には．．．
業界には．．．

医学では、稀な症例や現場の事例を学会等
医学では、稀な症例や現場の事例を学会等を通じて共有する仕組みがある 稀なバグや被害の大きな欠陥を業界全体で共有する仕組みがない現場の実例から抽象化して「病気」だけを定現場の実例から抽象化して「病気」だけを定義・管理・維持する学会・権威機関がある。そういう医学分野がある そもそもバグを研究する「バグ屋」という分野の人材も・技術分野も存在しない

現場医師は最新動向や検査・対処方法を継現場医師は最新動向や検査・対処方法を継続的に学ぶ習慣が付いている 現場は「除去」さえできればよいため欠陥の情報の獲得を行わない

PubMedPubMed comprises more than 20 million citations
for biomedical literature from MEDLINE, life sciencejournals, and online books. Citations may include links to full-text content from PubMed
Central and publisher web sites.
医学分野で世界最大の文献データベース。1966年からNLM（米国国立医学図書館）でデータ収集が始まり，現在毎月約3万件の文献万件を毎月約 万件の文献が新たに追加される。現在では，米国を中心に約70ヵ国から，900万件超える文献が収録される。

© 2013 IBM Corporation18

Chapter #3
The needs of “Defect Modeling”
Modeling”（欠陥をモデリングするということ）

ー もしも美しいものを作りたいのならその壊し方・壊れ方を知っておいたほうがいい ー© 2013 IBM Corporation

例題１） 例外処理が抜けている© 2013 IBM Corporation

例題１） 例外処理が抜けている ： 代表的な現象

1.コメントが一切記載されていない形式。完全に空欄
2.「処理なし」「NOOP」という記述。処理がない
3.例外処理が記載された後コメントアウトされている© 2013 IBM Corporation

パターン１）時間がないから正常ケースのみ
 コメントが一切記載されていない形式。完全に空欄

典型的な例1 ：16:
17:} catch (Exception e) {}典型的な例2 ：16:} catch (Exception e) {}© 2013 IBM Corporation

原因： 多くの場合「時間制約」が原因© 2013 IBM Corporation

パターン２） 「しようがない」または「負荷移転」
 「処理なし」「NOOP」という記述。処理がない

典型的な例1 ：

16:
17:
18:

} catch (Exception e) {// 処理なし（NOOP)}

典型的な例2 :

16:
17:
18:

} catch (Exception e) {// ここには制御がこないハズ}© 2013 IBM Corporation

原因： 部分最適化・責任範囲・「言われたことだけ実装」© 2013 IBM Corporation

パターン３）「やっぱやめた」「努力は認めてもらおう」

 例外処理が記載された後コメントアウトされている典型的な例1 ：16: //
17: //
18: //
19: //
20: //
21: //
22: //} catch (Exception e) {Logging(msgID, message.toString(msgID));
fis.close();// ファイルクローズに失敗した場合、エラーRaise＋表示
addActionError(e);showError();}© 2013 IBM Corporation

原因： 圧倒的な時間不足+短期的な関係© 2013 IBM Corporation例題１-a） 例外処理が抜けている 11:} else {

 12:

try {

 13:

//log.debug( "REMOVE_SESSION--->" + paramString);

 14:// その他操作の場合、Sessionに値があれば削除する

 15:

this.session.removeAttribute(paramString);

 16:} catch (Exception e) { 17:;

 18:
 19:}｝© 2013 IBM Corporation

パターン３）の変形： 「例外の握りつぶし」 または「怠慢」© 2013 IBM Corporation

欠陥の抽象度と展開幅
欠陥保存時の情報抽象度の高さに依存して横展開幅（＝欠陥情報の適用範囲）が決定される■ 逆に広範囲な展開を狙わない場合には、抽象度を高めなくてもよい（←本当？）
■

抽象度

元欠陥

同システム

同企業同業ドメイン

エンプラ／組込

普遍的

適用・展開幅© 2013 IBM Corporation

パターン認識とフレーミング
 医学の世界で「誤診」を避けるための方法として「フレーミング・バイアスの考慮」があります。フレーミング・バイアス（枠への偏執）とはある特定の特徴／兆候のみに固執して、重大欠陥（＝医学の場合は病気）を看過することです。
 欠陥マスター情報に登録される情報は十分に抽象化された欠陥情報の「枠組み」すなわちパターンの集合体です。このフレームに固執することは、一般的でない・稀な症状を呈する重大な欠陥を見過ごすリスクがあります。
 品質エンジニア（レビュー担当者／テスト担当者）が品質活動を行うためには、欠陥マスター情報や欠陥モデルの持つ典型的な症状に固執することなく、広く中立的な視点での品質検査が必要です。
ユーザ参画がユーザ参画が得られない得られない
プロジェクトプロジェクト要件の欠落
要件の欠落（＝要件がない）（＝要件がない）「納期必達」のラッシュ

協力会社への外注

テストで何とかする思考

設計上の機能欠落
設計上の機能欠落（＝漏れ／忘れ）（＝漏れ／忘れ）機能の「不」実装
機能の「不」実装
1.
2.
3.

• 書かれていない
仕様やコードはレビューできない

機能欠落による機能欠落による機能欠落によるダウン
機能欠落によるダウン

不要と判断した設計どおりの実装（言われた通り）
気づいていない（うっかり）レビュー時のレビュー時の“すり抜け”“すり抜け”© 2013 IBM Corporation

Chapter#3

Defects are also artifacts(欠陥もまた人工物である）© 2013 IBM Corporation

欠陥を検出する能力： 知覚と認知Ａ）知覚する能力（Perception））:Ａ）知覚する能力（観察（ぼんやりと全体を俯瞰すること）や洞察（ある程度細部を注視）すること、系統立てた点検作業を通じて「欠陥がそこに存在すること」を感覚的に対象を捕らえること。経験的学習や推測・過去パターンとの照合によって実現。
Ｂ）認知する能力（Cognition））:Ｂ）認知する能力（
知覚した欠陥の意味づけ、所見を確率する作業等を含む分析作業（種類や位置）。特に異常性や特異性を検出する際に論理的思考を通じて「存在した欠陥そのものを理解し説明できる」ようになること。

Ａ）知覚する能力（Perception）Ｂ）認知する能力（Cognition）

両方の能力をバランス両方の能力をバランスよく有することで良質のよく有することで良質の検査が成立する検査が成立する

事例

過去経験
右脳

左脳
© 2013 IBM Corporation

Chapter3: バグ検出する際の脳の動き 一般的な開発者は日々の活動（テスト、レビュー、デバッグ、その他）の中で、「バグの存在に気付く」瞬間があります。最初に欠陥に気付く瞬間は多くの場合、右脳が認知します。
 次にこの欠陥を論理的に「これは何のバグ？」「こんなバグがどうしてここに？」とその原因を考えますが、その真因考察の結果が得られる・得られないに関わらず、いずれかの脳で「除去方法」を考察します。
 そして選択した最良（であると思われる）除去方法を実践し、除去できたことを再度確認します。これはほぼ左脳で論理的に除去していくと思われます。

①欠陥に気付く
②これは何？と考える③直す方法は何通り？
④最善策の選択右脳⑤欠陥の除去左脳© 2013 IBM Corporation

Chapter3: バグ検出する際の脳の動き 前頁図の「③直す方法は何通り？」のところで、開発者個人の過去経験に基づいて欠陥の除去方法を感覚的に選んでいました。
 これを「欠陥のマスターDB」を使って論理的かつ確率論的に左脳で考察することができれば、更に欠陥の検出効率を高めることができるばかりでなく、①の欠陥に気付く力（欠陥兆候情報を追加）を強化したり、③で他者の除去方法（欠陥除去情報）を利用し、長期的には混入を防ぐことができるようになります。

①欠陥に気付く
②これは何？を調べる③直す方法は何通り？

欠陥マスター
DB④最善策の入手⑤欠陥の除去⑥処置の記録左脳

右脳⑦欠陥兆候の学習と記憶© 2013 IBM Corporation

Chapter X：
Defect Engineering and the future© 2013 IBM Corporation

DEBOK & DefectEngineering.NEXT
 Review / Inspection / I-V&Vs

 Defect Engineering Process / Cost of Quality

 Worldwide standards

 Quality Metrics

 Open source?

 Carrier of Quality Engineer

 Socialize?

 Defect Engineering© 2013 IBM Corporation

医学的アプローチ::免疫メカニズムの実装
 免疫のメカニズムはAD1000年前後には「天然痘」のかさぶたを乾かしたものを経口摂取することで、能動的免疫処置の原型を実現していた

病原体採取

欠陥採取

分析・観察分析・観察

培養

培養投与
抗体増により病気予防

抗体注入
既知種欠陥を含むコードのリリース予防© 2013 IBM Corporation

医学的アプローチ::免疫メカニズムの実装
 検出した欠陥を採集すると、抽象化／固定化を経てフィードバックとフィードフォワードのプロセスを実施。他システムに「欠陥ワクチン（感知器と抗体）」を投与することで、同種欠陥の再発と新規の混入（＝コードリリース）を予防する

設計 & 実装

テスト (V&V）

運用（リリース後）システム A
Feedforward

３）根本原因分析
3-1）混入原因分析3-2）残存原因分析

欠陥検出（=標本採集）４）抽象化
4-1）固有情報の除去

５）抗体作成（Defencine））

４）固定化
4-1）過失因子と増幅因子特定4-2）関連欠陥・再混入予防

Feedback

１）基本情報記録
２）既知種の照合・同定

5-1）感知器作成
5-2）抗体作成

Feedforwardシステム B© 2013 IBM Corporation

医学的アプローチ::併発症の研究１）ある欠陥兆候を検知できると、一つの欠陥の存在が予測できる
２）ある欠陥の存在は、共通原因を持つ他の欠陥の存在をユーザビリティー欠陥
予測可能にし、結果として検出漏れを予防できるようになる。→欠陥を単一で検出しない
H
H

DBデッドロック「大規模開発経験の不足」

M
M
H

H

H

チーム内の認識齟齬
プロセス欠陥（DB作成順序等）

M
M

２

H

H

５

MM

「チーム間確認不足」「業務知識の不足」

M
M

３
MM

M
M

業務経験年数が少ない
若手中心・指導者不足
ユーザー参画不足

インターフェース定義エラー
インターフェース定義エラー

H

H
H
H

H

H

H
H

H

L

１ L

H

H
H

HH

H
H

チーム間コミュニケーション不足
相互レビュー不足

データ項目の意味取り違い© 2013 IBM Corporation

医学的アプローチ::診断学への応用

診断レベル

現時点

欠陥マスタ

欠陥の定性測定||診断学||
病理学

定量測定

欠陥追跡&収集
レビュー&テスト時間© 2013 IBM Corporation

ソフトウェアの歴史が進化しない理由は、欠陥を研究しないから

To be continued …..

© 2013 IBM Corporation

Thank you ☺

43© 2013 IBM Corporation