SQiP2014招待講演の資料です。

1. バグレポートの改善に向けた
問題事例の調査とアンチパターン作成
バグ票ワーストプラクティス検討プロジェクト
鈴木昭吾/ 近美克行/ 近江久美子/ 渡辺由希子
https://sites.google.com/site/swworstpracticesite/
sw.WorstPractice@gmail.com
SQiP2014 招待講演

2. 謝辞
• ご協力、情報提供およびコメントをいただいたみなさまに御礼申し上げます。
• SQiPシンポジウム2012,2013,2014のSIG・発表でコメント等いただいたみなさま
• JaSST’14東京にて有益なコメントを頂いたみなさま
• JaSST’12, 13東海ポスターセッションで有益なコメントを頂いたみなさま
• WACATE分科会でアンケートや議論にご協力いただいたみなさま
• 第8回SQuBOKユーザ会勉強会にて議論させていただいたみなさま
• Webやアンケート用紙にて、ご回答をいただいたみなさま
• その他、活動のご支援やコメント等ご協力いただいたすべてのみなさま

3. 目次
• 本研究の狙い・目的
• 背景と解決したい問題
• バグレポート
• ワーストプラクティス
• いままでやってきたこと
• 先行研究の調査
• アンケート実施概要とその結果
• 現在やっていること
• パターンの作成方針
• パターン作成例
• 今後の課題

4. はじめに
背景や意義

5. 背景
バグレポートは、今日ソフトウェア開発の多くの組織で
使われている。
経営者ｻﾎﾟｰﾄ
ﾃｽﾀｰ
設計者
ﾌﾟﾛｸﾞﾗﾏ
QA
ユーザﾏﾈｰｼﾞｬ
バグ
レポート
開発現場では、バグレポートは有効に利用されていないのでは？
（※バグレポート＝ISTQB用語集のインシデントレポート）

6. バグレポートがうまく使われていない例
• 「バグピンポン」
• テストエンジニアと開発者の間で発見したバグに同意がとれず、
バグを指摘したメールやバグレポートがいったりきたりすること
6
バグだ
バグピンポンの正式な原典は明らかではないが、たとえばDZoneのインタビュー等で言及されている
http://agile.dzone.com/videos/end-bug-ping-pong
開発者テスト担当
バグではない

7. バグレポートがうまくつかわれるとは
• 良いバグレポートはバグレポートのライフサイクルが、問題なく遷移していくこと
バグ報告組織バグ分析・対策組織
発行Open 開始判断
解析開始
承認済み
担当者
割当て
解析担当
割当済み
解析実行
修正待ち
次Verへ延期
修正実行
再テスト待ち
確認テスト
実行
テスト結果
再テスト済み
判定
解決済み
調査
却下再調査依頼
（テストミス・仕様通り）
重複
※JSTQBシラバス、IEEE829をから例示されたステータスを抽出し、状態遷移を作成

8. バグピンポンの例
終端に進まず
再調査依頼とOpenを
循環してしまう
バグ報告組織バグ分析・対策組織
発行Open 開始判断
解析開始
承認済み
担当者
割当て
解析担当
割当済み
解析実行
修正待ち
次Verへ延期
修正実行
再テスト待ち
確認テスト
実行
テスト結果
再テスト済み
判定
解決済み
調査
却下再調査依頼
（テストミス・仕様通り）
重複
組織の分断や責
任分担が適切で
ないと発生

9. 意義
1. バグレポートが活用できないために多くの弊害が発生している。
• 内容確認等のコミュニケーションのために無駄な工数が発生。
• ソフトウェアテストに対する弊害
• 正確な品質状況がつかめない
• プロセス改善に対する弊害
• Project Fabre(プロジェクトファーブル）※などで提唱している
欠陥のパターン（バグマスター）が作成できない。
• 組織のプロセスなどの弱点や問題点が見出しにくい。
• 組織のマネジメント力や個人の能力向上ができない。
2. バグレポートの書き方を解説している書籍などは多い。
（例：「ソフトウェアテスト293の鉄則」など）
しかし、悪いバグレポートがどのようなものかは議論があまりない。
悪いバグレポートがどのようなものかを共有し改善することで、
ソフトウェア開発組織の問題解決や改善ができる可能性がある
※Project Fabre(プロジェクトファーブル)： http://aster.or.jp/business.html#fabre

10. ワーストプラクティス
• 「ベストプラクティス」はいろいろなメディアで紹介されている
→SQiP等イベントで紹介される事例、Webサイト等々
知っていても実行できない事が多い
• 「コンテキスト」が合わないことがある
• 「ベスト」な環境は整えるのが大変
• ベストの条件＝いろいろな条件が
ちょうどバランスがとれた状態
（実は特殊状況である）
「ワーストプラクティス」を回避するということでも
効果が見込めるのではないか？
• 教科書的な行儀のよい状況下だけで学んでもだめ！
• 状況とセットで、失敗を学習・共有することに意味がある。

11. 先行研究の調査
• 海外の事例（文献）
• Modeling bug report quality
• "Not my bug!" and other reasons for software bug
report reassignments
• What Makes a Good Bug Report?
• 「Making Software ―エビデンスが変えるソフトウェア開発」
「第25章バグレポートの技芸」に邦訳あり
• 海外での研究事例はあるが、
国内ではあまり議論されていない
• CiNiiでの検索すると、「バグレポート」で9件、
「バグ票」で1件
バグレポートの改善に関する文献はほとんどない
→バグレポートに関する調査を自分たちでやってしまおう！

12. 研究活動の全体像
• 研究はコミュニティーベースで活動（現在アクティブメンバーは3名）
• バグレポートが活用されていないのではないか？それはなぜなのか？
どうすればもっと活用できるのか？が関心事
• アプローチは以下のとおり
問題定義・確認フェーズ対策立案・実行フェーズ
対策実行・検証
対策検討
バグ票が活用さ
れていない？
実態調査のための
アンケート設計
アンケートで
実態調査
アンケート
分析
現場で
良くある
問題
ﾊﾟﾀｰﾝ（知見共有）で人間の判断を改善
ｱﾝﾁﾊﾟﾀｰﾝ
作成と共有
ツールで効率と正確性を改善
BTS改善
テンプレ改善
パターン共有
ワークの実施
等、普及調査
効果測定
監査で確認
ツール化
プロセスで組織と組織運営効率を改善
運用ルール変更
組織変更検討
効果測定
変更の実行
いまここ
きっかけ
問題記述（仮） 問題確認

13. 実態調査のための
アンケート設計
いままでやってきたこと
アンケートで
実態調査
アンケート
分析
現場でよく
ある問題
アンケートの内容や結果

14. アンケート実施
• 2つの方法で調査実施(2011年１月から開始)
1. PC/スマートフォン2. アンケート用紙
http://goo.gl/w3qty
ソフトウェア品質やソフトウェアテストに興味がある方を対象に
インターネットや各種イベントでアンケート呼掛けと調査を実施
• SQiP等ソフトウェア品質系イベント

15. アンケート内容
1. どんな問題のあるバグレポートか
2. どうあるべきだったか
3. 起票された工程
4. 起票者の立場/ 経験
5. 対象ソフトウェアの規模
6. 開発のタイプ／形態
7. 印象的なバグレポート
8. その他バグレポートへの思い
特に回答頂きたい上記、1、2 を必須として
他の項目は任意回答とした
15

16. アンケート設問
• 自由記述と選択肢項目で構成
自由記述
どんな問題のあるバグレポートか
どうあるべきだったか
印象的なバグレポート
その他バグレポートへの思い
• 約60件のデータを元に調査
選択肢項目
起票された工程
• コンポーネントテスト
• 統合テスト
• システムテスト
• 受入テスト
• 稼働後
起票者の立場/ 経験(期間)
• 開発部署/ 第三者等
• プロダクトに従事した期間を
8段階で選択
対象ソフトウェアの規模
• SLOCで5段階
開発のタイプ／形態
• 派生開発or 新規開発

17. アンケート結果
現場にあるダメなバグレポート
• 大きく4つに分類
o バグレポートに書かれている内容が伝わらない39％
o バグを記載された手順で再現できない25%
o 目的が共有されていない19％
o フォーマットが適切でない14％
バグ修正のための報
告書として、伝える目
的を達成していない
多くのプロセスモデルの「問題解決管理」エリア
が要求する、優先付や傾向分析等の機能を果
たさない
※詳細については、SQiPシンポジウム2014での発表資料を参照

18. アンケート結果: 回答者
回答者の立場は以下のとおり
開発者・テスト担当者：それぞれ約30％
出荷テスト担当者：24％
分析担当等：17％
18
29%
30%
24%
17%
開発者、テスト担当者、第三者テスト
担当者などバランスよく意見を回収
バグを報告する立場（チー
ム内）[開発部署内のテスト
チームなど]
バグを修正する立場（チー
ム内）[開発者など]
バグを報告する立場（第三
者）[出荷検査実施者など]
上記以外の立場(バグ票を分
析する立場等)

19. アンケート結果: 起票者
バグレポート起票者の立場は以下のとおり
開発内テスト担当者：46％
開発者：20％
開発チーム外のテスト担当者、データ分析者：34 ％
19
46%
20%
25%
9%
開発内テスト担当者による問題となる
バグ票事例が多く収集された
バグを報告する立場（チー
ム内）[開発部署内のテスト
チームなど]
バグを修正する立場（チー
ム内）[開発者など]
バグを報告する立場（第三
者）[出荷検査実施者など]
上記以外の立場(情報を分析
する立場等)

20. アンケート結果: テスト工程
問題のバグレポートのテスト工程は以下のとおり
コンポーネントテスト：14％
統合テスト：44％
システムテスト：34％
受け入れテスト：8％
20
14%
44%
34%
統合テスト（複数の開発チームが関係）や
システムテスト（より多くの関係者が参加）に
問題発生
8% CT(コンポーネントテスト/
単体テスト)
IT(統合テスト/組み合わせテ
スト)
ST(システムテスト)
顧客受け入れテスト

21. アンケート結果: 起票者の経験
経験がある方でも問題となるバグレポートを起票している
2年以上従事している方：52％
1年以上従事している方：76％
どんな方が書いているかわからないケースがある
不明という回答：14％
21
52%
7%
17%
3%
3%
2%
14%
2% 24ヶ月以上
18ヶ月以上24ヶ月未満
12ヶ月以上18ヶ月未満
6ヶ月以上12ヶ月未満
3ヶ月以上6ヶ月未満
3ヶ月未満
ベテランでも問題バグ票を書い
ている
慣れも影響？またはスキルに
関係ない状況が原因？

22. アンケート結果からわかったこと
 どのような方が、どのようにバグレポートを利用して
いるか認識されていない
 いつ、どのようなときに起票するか共有されていない
 バグレポートの項目に、どのように使われるか分から
ない項目がある。または起票者だけで判断できない場
合がある
 バグレポートの問題は、経験の蓄積だけでは解決しに
くい問題である
バグレポートに起こりがちな問題をアンチパターンを
示しながら学習・教育を行なうことが有効。

23. 現在のチャレンジ
アンチパターンの作成

24. アンケート結果の分類
• 頂いた回答をいくつかに
分類して傾向をみてラベ
リング
• 分類については、メンバ
ー各自の立場で検討した
• QA/開発/マネジャー

25. アンチパターン作成
• 少し進めてみて、
SQiP2013から
内容を変更
• 以前のテンプレートでは
まとめにくい
• 情報がもう少し欲しい
SQiP2013での資料

26. アンチパターン作成
• 「Pattern Writing Sheet」を利用してアンチパターンを試みた
• アンチパターンはパターンとほぼ同じ構成と考えられる
• 視覚的にわかりやすい
http://creativeshift.jp/sheet/ より引用

27. 1. アンケート結果より問題を分類
2. 「Pattern Writing Sheet」のフォーマットでパターンを抽出
a. 「Pattern Writing Sheet」の記入順序をシートガイドから変更。
Problem からForces・Context 等を検討したのち、
Solution やAction・Consequence を記載した。

28. 作成したアンチパターン
テストチームと開発チームのやりとりが
止まらない
⇒バグ処理ステータスを進める判断が合意されな
い。ぐるぐる回り先に進まない

29. バグレポートに関する記載が不十分
⇒情報不足
⇒バグ処理ステータスを適切に進められない

30. アンチパターンを作成してみて
ボトムアップアプローチでの構造化に限界
•（当初）集めたアンケードからボトムアップでパターン構築
•そもそも全体が不明なので研究
→途中で構造化に息づまる。
全体を俯瞰しながら再調整しないと矛盾がでる
（体系が崩れて使いにくいパターン集になってしまう）
バグレポートのステータス遷移モデルを活用
•（対策）バグレポートのステータス遷移モデルを活用し、バグレ
ポートの「アンチパターン」の全体をまず理解。
•その後に収集された個々のワーストプラクティスをマッピング
というアプローチを併用
（このアプローチは今後の課題）

31. アンチパターンを作成してみて
バグレポートアンチパターンの全体モデル
•バグレポートの問題の定義：バグレポートのライフサイクル上で
処理ステータスの遷移に不都合がでること
•遷移に不都合がでるのは大きく3種類
①
②
③
①ぐるぐる
やりとりが延々続き
処理が先に進まない
②ストップ
情報不足・判断権限
がなく処理不可
③適当進捗
強引にClose
Close判断理由なし

32. バグレポートアンチパターンの全体モデル
•バグレポート処理の成功ケース：
①②③も発生せずに無事Close
•バグレポート処理の失敗ケース：
①②③がいずれかが発生“適切”にCloseできず。
①
②
③
①ぐるぐる
やりとりが延々続き
処理が先に進まない
②ストップ
情報不足・判断権限
がなく処理不可
③適当進捗
強引にClose
Close判断理由なし
アンチパターンは②を避けようとして①になるなど、
失敗ケースを避けて別の失敗ケースに遷移すること

33. バグピンポンの考察
•バグ／バグでないの判断をするだけの情報や合意基準がない
⇒判断できないので②ストップや③適当進捗が発生
•組織に、適切にバグ処理を進めるというプレッシャー
•②や③を避けて、早く処理をしたいくなる
•今度は①ぐるぐるが発生
①
②
③
①ぐるぐる
やりとりが延々続き
処理が先に進まない
②ストップ
情報不足・判断権限
がなく処理不可
③適当進捗
強引にClose
Close判断理由なし
ピンポン発生の背景には、組織が分断している、
バグ/バグでないの判断権限や合意基準不足がある。

34. →①②③を同時に消す方法が
求めるもの（パターン）
→そのために、①から②、①から③
・・・などの間違った対策例を分析
（アンチパターン）

35. これからやっていきたいこと
アンチパターンの拡充と評価

36. 評価および改善
• アンチパターンの拡充
• 分類に従い、アンチパターンを作成していく。
• 評価および改善
• ワークショップ形式で評価と改善を行なう。
・「プレパタ」など人間の活動に関する
試験の形式化や評価の方法が使えそう
※http://presentpatterns.sfc.keio.ac.jp/
・慶応大学井庭氏の方法論が参考

37. まとめ

38. 今後の課題
• アンチパターン集の拡充
• アンチパターンの評価および変更・修正
• アンチパターンが使えるか/共有できたかをパターン・ランゲージ
を評価している方法で調査する
• フィードバックより、変更等を行なう
• BTSなどへのパターンの実装

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