テスト結果や丌具合管理票を将来に活かすには？
奈良先端科学技術大学院大学 / 静岡大学

森崎 修司
smrs@is.aist-nara.ac.jp
ismoris@ipc.shizuoka.ac.jp

本資料に含まれる研究の一部は文部科学省「次世代IT基盤構築のための研究開発」の委託に基づいて行われたものです。本資料に含まれる研究の一部は同省科学研究補助費（若手B：課題番号21700033）の助成を受けました。本資料に含まれる研究の一部は株式会社東芝 ソフトウェア技術センターとの共同研究の一環として実施しました。

本セッションの総括とあらまし• 総括– テスト結果や丌具合管理表の情報は進行管理やエビデンス作り以外にも積極的に活用できる。

• あらまし（事例）– テスト結果からソフトウェアの品質を推定– 丌具合管理票から修正コストが大きなバグの傾向を抽出– バグ票に載せるべき情報– バグ票ワーストプラクティス収集プロジェクト

国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

1

テスト結果からソフトウェアの品質を推定する事例• 事例1: Salesforceでの開発– 品質保証エンジニアの役割
テスト実施を容易にし、テストに顧客視点をいれる。

• 事例2: twitter.comのダークモード– 品質保証エンジニアの役割
テスト結果や実行時エラーを監視しながら機能のリリースを個別にコントロールする（稼働中の機能を含む）。
精緻化
（事例1）
テスト観点、計画

リリース可？
（事例2）

吟味
（事例1）
テスト対象

テスト結果
品質保証エンジニア

国立大学法人奈良先端科学技術大学院大学

ユーザ© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

salesforce.comでの品質保証エンジニアの役割• 前提– テストコードによるテスト自動化がある程度実施されている。
– 単一バージョンのソースコードで全顧客にサービスする。

• 役割– 自動化テストがやりやすくなるような仕組みを作る。
– テストコードにユーザ視点が入れる。
– テスト結果から品質を推定する。
– 自動化テスト実施後に探索的テストを実施する。
– 70%の自動化と100%のテスト実行を推進する。
出典: 及川喜之, salesforce.comの作り方 どのように世界最大規模のアジャイル開発を実現したか, デベロッパーズサミット2011
Publickey, クオリティエンジニアの役割とは「お客様の視点を提供すること」
http://www.publickey1.jp/blog/11/post_150.html
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

2

twitter (tweet: さえずり、つぶやき)• インターネットを通じて無償で提供されるサービス• ユーザは丌特定多数むけにメッセージ（つぶやき）を配信する。
• 複数のユーザを選び、選んだユーザのつぶやきを時系列に表示する。

国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

twitterのシステム構成• ほとんどの機能はサーバ側のプログラムで実現される。
• サーバ側のプログラムはバージョンアップや変更が容易

twitterプログラム

つぶやき

インターネット

Webブラウザから
国立大学法人奈良先端科学技術大学院大学

携帯電話から© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

3

twitterのダークモード• twitterの運用メンバがツールを操作することによって提供している機能を一時的に非公開したり、公開したりできる。
• ユーザを選んで設定することもできる。
• サービス全体を停止せずに問題のある機能を一時的に利用できなくしたり、復活したりできる。

出典: オライリーVelocity 2010カンファレンス In the Belly of the Whale: Operations at
Twitter http://www.youtube.com/watch?v=_7KdeUIvlvw
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

ダークモードの制御• 実行時のエラーログを監視して機能ごとにリリース管理している。
• メリット– 新しいバージョンのプログラムは特定のユーザに限定してリリースできる。
例） 「リスト」機能や「公式RT」機能はユーザによって開始時期が異なった。
– いったんリリースした機能の調子が悪ければ、使えなくすること、一部のユーザに公開を限定することができる。
– twitterのサーバサイドプログラムが出力するエラーログから、問題を監視する。

• 無償サービス、多尐怒られることはいとわないという前提がある。
• テスト結果や実行結果をもとにリリースを制御している。

出典: オライリーVelocity 2010カンファレンス In the Belly of the Whale: Operations at
Twitter http://www.youtube.com/watch?v=_7KdeUIvlvw
8
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

4丌具合修正時間の分析• 単一要因による分析
丌具合の修正工数をプロットし、現状把握や効率化の施策を検討している。
例: 混入工程別の修正時間
修正工数丌具合1件

基本設計 詳細設計 コーディング ・・・・
混入工程
国立大学法人奈良先端科学技術大学院大学

9© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

過去の丌具合修正時間からのレビュー観点設定• 条件の複合による分類ができれば、さらに詳細な現状把握や対策を検討できる場合がある。
• 「（混入工程＝基本設計）かつ（機能＝A） → 修正時間（平均,16.5時間）」のようなルール形式で丌具合修正時間の傾向を分析している。[2]修正工数

基本設計で混入された機能Aの丌具合基本設計でA以外の機能に混入された丌具合
基本設計 詳細設計 コーディング ・・・・
[2] S. Morisaki, A. Monden, T. Matsumura, H. Tamada and K. Matsumoto, “Defect Data Analysis Based on Extended
10Association Rule Mining,” In Fourth International Workshop on Mining Software Repositories (MSR 2007), pp.017-024
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

5

対象丌具合管理票• プロジェクト
– プローブ情報システムのサーバサイドロジック（自動車から送られる交通情報をもとに最適経路をナビゲーション:経済産業省「先進的ソフトウェア開発プロジェクト」）– C/C++で330KLOC（流用込み）、約1年– 複数ベンダによるウォータフォール型開発• 丌具合– 発見フェーズ 単体～総合試験– 記録丌具合件数 約1,300– 組織内でバグと承認されたもの以外は入っていない。

11
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

対象とした丌具合管理票の項目

変数名

取りうる値

修正工数

修正に必要となった工数（人時）混入工程

混入，修正，発見された工程（基本設計，詳細設計，製造/単体試験，結合試験，総合試験）

発見工程
修正工程
機能

機能名（9機能のいずれか）発見が遅れた理由

レビュー未実施，レビュー指摘もれ，修正確認漏れ，工程間引継ぎ，コミュニケーション丌足，試験項目抽出もれ，テスト計画に含まれていない，環境が整わずテスト未実施，結果確認ミス

優先度

高，中，低重要度

高，中，低

再現性

常に，たまに，一度だけ

出典: 森崎、門田、玉田、松村、松本：“Defect Data Analysis Based on Extended Association Rule Mining”, Proceedings ofInternational Workshop on Mining Software Repository, pp.17-24. http://se.naist.jp/~morisaki/publications/#i-200705
国立大学法人奈良先端科学技術大学院大学

12© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

6

抽出ルールの分布（出現頻度 0.5%以上の17,000ルールを抽出）
修正工数の標準偏差
LLS1, LLS2 and LLS3302520

LLM1-a, 1-b, 1-c and 1-d and LLM2

151050

修正工数の平均（人時）SLM1, 2 and 30510152025

出典: 森崎、門田、玉田、松村、松本：“Defect Data Analysis Based on Extended Association Rule Mining”, Proceedings ofInternational Workshop on Mining Software Repository, pp.17-24. http://se.naist.jp/~morisaki/publications/#i-200705

13
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

抽出ルールの傾向分析
修正工数の標準偏差30Standard deviation of effort

LLS1LLS2

修正工数のばらつきがLLS3大きいルール

252015

LLM1-c
LLM1-dLLM2

10

修正工数の平均が大きいルール

5

修正工数が小さいルール
SLM100

SLM3
SLM2

51015

LLM1-aLLM1-b2025
Mean effort (staff-hours)

修正工数の平均（人時）14
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

7抽出したルール（抜粋）・(再現性＝低）かつ（発見工程＝製造）かつ（修正工程＝製造）・（機能＝データ処理）かつ（混入工程＝製造）

30

LLS1

LLS2

Standard deviation of effort

・（機能＝データ出力） 修正工数のばらつきがLLS3大きいルール
かつ（混入原因＝コー20ディングミス）
LLM1-c LLM1-a・（機能＝入力データ
LLM1-d15
LLM2
LLM1-bチェック）かつ（混入工程＝製造）
修正工数の平均が10255大きいルール

修正工数が小さくなるルール
SLM100

SLM3
SLM25

国立大学法人奈良先端科学技術大学院大学

10・(発見工程＝総合試験）かつ（重152025要度＝高）Mean effort (staff-hours)
・（混入工程＝製造）かつ（検出1515工程＝総合）© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

注目した要因からレビュー観点の設定• 注目したルールに当てはまる
バグの現象説明欄等からレビューの観点として設定できる項目を導出

設計レビューの観点として適当なものを選択 (表中色塗りのセル)

出典: 森崎 修司 “レビュー効率化にむけた産学連携の取組み”,
ソフトウェアプロセス改善カンファレンス 2009 招待講演
国立大学法人奈良先端科学技術大学院大学

分類件数

例外処理

20

パラメータ初期化/クリア8

特殊入力データ/パラメータ8

排他処理5内部シーケンス

5

ユースケース

4アルゴリズム3

バッファオーバーフロー

2

データ領域管理

2

状態遷移

2

条件分岐

2

IF(戻り値)

2

操作ミス

116

© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

8

試行: レビューアへの指示• 割り当てられた「観点」を中心にレビュー対象をチェックする。
• 割り当てられた観点以外の指摘も可

観点
・例外処理
・初期化
・ユースケース

ユースケース
Xとの食い違いAの例外処理がない

観点
・特殊入力
・初期化
・排他処理

レビュー対象レビューアA

レビューアB

出典: 森崎 修司 “レビュー効率化にむけた産学連携の取組み”,ソフトウェアプロセス改善カンファレンス 2009 招待講演
国立大学法人奈良先端科学技術大学院大学

17© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

試行結果• レビュー方法– レビュー対象を事前配布し、各レビューアがチェック– レビュー時間は試行1の外部設計書と同様• レビュー結果– 観点からの指摘が多く見られた。
– 欠陥レベル中以上の指摘率が高い。
⇒ 欠陥レベルの高い問題が見つかりやすく、観点適用の効果も高い。
試行結果1
レビュー工数

試行結果2

6人時

3人時

人数

5名

3名

全指摘件数

11件

9件

欠陥レベル中～高の指摘

6件

8件

観点を適用したと思われる指摘
予測修正工数

1件

6件

7人日

16人日

出典: 森崎 修司 “レビュー効率化にむけた産学連携の取組み”,ソフトウェアプロセス改善カンファレンス 2009 招待講演

国立大学法人奈良先端科学技術大学院大学18© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

9丌具合管理表を用いた修正工数の参考文献• 論文– Shuji Morisaki, Akito Monden, Haruaki Tamada, Tomoko Matsumura,Kenichi Matsumoto：“Defect Data Analysis Based on Extended
Association Rule Mining”, Proceedings of International Workshop on
Mining Software Repository, pp.17-24.
http://se.naist.jp/~morisaki/publications/#i-200705– 森崎 修司, 森 俊樹, 羽原 寿和, 夏目 珠規子, 山田 淳, 松本 健一:丌具
合修正時間の要因分析を目的とした例外ルールマイニングの試行,プロ
ジェクトマネジメント学会 2011年度 春季研究発表大会予稿集, pp.433438 (2011)• Web記事– 森崎 修司, バグ票からひもとくインスペクションとテストのバラン
http://thinkit.co.jp/article/896/1?page=0,1

国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

What makes a good bug report? - 研究論文
• N. Bettenburg, S. Just, A. Schroter, C. Weiss, R. Premraj and T.
Zimmermann, “What Makes a Good Bug Report?”,
Proceedings of 16th International Symposium on Foundations ofsoftware engineering, pp. 308-318(2008)• Apache, Eclipse, Mozillaの開発に関わるメンバにメールでアンケート– バグ報告者• 返信は計310名• 一貫性チェックで95名を削除– 開発者• 返信は計156名• 一貫性チェックで26名を削除

国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

10報告者と開発が考える重要な情報をアンケート

出典: N. Bettenburg et.al “What Makes a Good Bug Report?”, Proceedings of 16th International
Symposium on Foundations of software engineering, pp. 308-318(2008)
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

アンケート結果による項目のランキング

出典: N. Bettenburg et.al “What Makes a Good Bug Report?”, Proceedings of 16th International
Symposium on Foundations of software engineering, pp. 308-318(2008)
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

11報告者が提供する情報 vs. 開発者が必要とする情報

出典: N. Bettenburg et.al “What Makes a Good Bug Report?”, Proceedings of 16th International Symposium on Foundations of software© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.
国立大学法人奈良先端科学技術大学院大学
engineering,pp. 308-318(2008)

報告者が報告する情報 vs. 開発者が役立つと考える情報

出典: N. Bettenburg et.al “What Makes a Good Bug Report?”, Proceedings of 16th International Symposium on Foundations of software© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.
国立大学法人奈良先端科学技術大学院大学
engineering,pp. 308-318(2008)12報告者が役に立つと思っているもの vs. 開発にとって役立つもの

出典: N. Bettenburg et.al “What Makes a Good Bug Report?”, Proceedings of 16th International Symposium on Foundations of software© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.
国立大学法人奈良先端科学技術大学院大学
engineering,pp. 308-318(2008)

アンケートの自由記述から• 困ること– 知識レベルが揃っていないとき– ネチケットを守っていないとき– 再現方法が複雑– バグ報告で別の議論（今後の機能拡張の方針等）がはじまってしまう。

• 報告されたバグへの対応がよくなる条件– バグ報告者のこれまでの評判がよい。（これまでわかりやすい報告をしている等）– 鋭い指摘をしている。
– 優先度が高いと対応するが低いと報告のわかりやすさに依存する。

26
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

13

バグ票ワーストプラクティス収集プロジェクト• 主導（現時点で）: すずき氏、ちかみ氏• 主旨「こんなバグ票ないわー」というのを集めてアンチパターンを作り、みんなで共有し、初歩的な誤りを減らそう。
• 経緯– JaSST Kansai 2010の翌日の大阪ツアー内での会話がきっかけ• これまでの活動– JaSST Tokyo 2011 ライトニングトークス: 「そんなバグ票で大丈夫か？」「一番いいのを頼む」ちかみ氏、すずき氏– Software Testing ManiaX vol. 4: そんなバグ票で大丈夫か？」「一番いいのを頼む」/ バグ票ワーストプラクティス検討project(鈴木氏&森崎)

国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

収集データの項目と協力方法• Webから入力する。
https://spreadsheets.google.com/viewform?formkey=dGtQTWl
UOEpsQjlKb3RYanZfNUlrM2c6MQ• 機密が漏れない範囲でご協力を！

URL

国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

14

まとめ• テスト結果と丌具合管理票を積極活用した事例を紹介した。
– Salesforceの事例
品質保証エンジニアの役割はテスト結果から品質を読み取ったり、よりよいテストが実施されるよう仕向けること– twitterの事例
品質保証エンジニアの役割はテスト結果や実行エラーログから、リリースする機能を選んだり非公開としたりして積極的な品質管理をすること– 国内商用開発での事例
丌具合管理表から修正工数の傾向を分析し、体制やプロセスの改善に使う。
– オープンソースでの事例
丌具合報告者、開発者の間で役に立つ/意味がない丌具合票の項目を調査→ 継続的改善が必要– バグ票ワーストプラクティス収集プロジェクト問題のある丌具合票から改善の糸口を発見しようとしている。

• そのままでは使えませんが、どう活かしますか？
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

情報ご希望の方はメールアドレスをお知らせください• 丌定期（月1回程度）のメールマガジンを配信する予定です。
• ご希望の方は電子メールにて以下をお送りください。
– From: 情報をお送りするメールアドレス– To: ismoris@ipc.shizuoka.ac.jp– Subject: 研究グループからのお知らせ配信希望
– 本文
ご氏名:
ご所属:

• いただいた情報を本来の目的以外で使用することはありません。

30
国立大学法人奈良先端科学技術大学院大学© 2011 Copyright Nara Institute of Science and Technology and Shuji Morisaki, All Rights Reserved.

15