バグレポートの問題事例の調査と

改善のためのアンチパターン集の作成

バグ票ワーストプラクティス検討プロジェクト

鈴木 昭吾, 近美 克行, 近江 久美子,

渡辺 由希子, 森崎 修司

e-mail：sw.WorstPractice@gmail.com

Web: https://sites.google.com/site/swworstpracticesite/

JaSST’14 Tokyo 経験発表

• JaSST12Tokyoでのご協力ありがとうございました。

2

ツィート元：https://twitter.com/Tesutaro_JaSST/status/162369061878116352

謝辞

• ご協力、情報提供およびコメントをいただいたみなさまに御礼申し上げます。

o JaSST’12, 13東海ポスターセッションで有益なコメントを頂いたみなさま

o SQiPシンポジウム2012, 2013 のSIGでご協力いただいたみなさま

o WACATE分科会でアンケートやディスカッションにご協力いただいたみなさま、 有益なコメントをいただいたみなさま

o 第8回SQuBOKユーザ会勉強会にて議論させていただいたみなさま

o Webやアンケート用紙にて、ご回答をいただいたみなさま

o その他、活動のご支援やコメント等ご協力いただいたすべてのみなさま

3

ありがとうございました。

目次 1. はじめに

1. 背景

2. バグレポートがうまく使われていない例

3. 意義

4. ワーストプラクティス

2. アンケート調査・結果 1. アンケート実施方法

2. アンケート内容

3. アンケート結果

4. 考察および改善案

3. アンチパターン集作成 1. アンチパターンテンプレート

2. 試作例

4. 今後の展開

5. まとめ 4

5

はじめに 1. 背景 2. バグレポートがうまく使われていない例 3. 意義 4. ワーストプラクティス

背景

• バグレポートはソフトウェアのエンジニアが最も多く関わる技術文書であり、 ほとんどの開発現場で存在する

6

開発現場では、バグレポートは有効に利用されていないのでは？

ﾃｽﾀｰ ﾌﾟﾛｸﾞﾗﾏ

設計者 QA

ｻﾎﾟｰﾄ 経営者

ﾏﾈｰｼﾞｬ ユーザ

バグ レポート

（※バグレポート＝ISTQB用語集のインシデントレポート）

バグレポートがうまく使われていない例1 • 「バグピンポン」

o テストエンジニアと開発者の間で発見したバグに同意がとれず、 バグを指摘したメールやバグレポートがいったりきたりすること

7

• バグピンポンの正式な原典は明らかではないが、たとえばDZoneのインタビュー等で言及されている http://agile.dzone.com/videos/end-bug-ping-pong

テスト担当 開発者

バグだ

バグではない

8

バグレポートがうまく使われていない例２ • 「バベルの塔」

o 用語やルールが混乱し、バグの問題解決や管理に支障をきたす。

・同件検索効率がおちて、同件バグレポートの登録が防げなかった。 ・同じ用語や書き方でも違う事象を指す場合があり、修正ミスが起きた

プロジェクトの遅れを挽回するために、メンバを追加投入した。

バグレポートは書いたことがあるから導入教育をしなかった。

バグレポート内の言葉(用語)や運用(起票基準等)が バラバラになった。

バグレポートがうまく使われていない例3

9 https://twitter.com/yukihiro_matz/status/312534609495736320 より引用

リツィートが約700、 リプライは16あり 大きな反響があった

多くの方が同じような状況で困っている様子が伺える

「なにかがおかしい」 バグ修正するために必要な情報が書かれていない。

例：「エラーになりました。」 等

意義 1. バグレポートが活用できないために多くの弊害が発生している。

o 内容確認等のコミュニケーションのために無駄な工数が発生。

o ソフトウェアテストに対する弊害

• 重複したバグレポートがあり正確な品質状況がつかめない

o プロセス改善に対する弊害

• Project Fabre(プロジェクトファーブル）などで提唱している 欠陥のパターン（バグマスター）が作成できない etc.

• 組織のプロセスなどの弱点や問題点が見出しにくい

2. バグレポートの書き方を解説している書籍などは多い。 （例：「ソフトウェアテスト293の鉄則」など） しかし、悪いバグレポートがどのようなものかは議論があまりない。 (例：「Making Software エビデンスが変えるソフトウェア開発」)

10

悪いバグレポートがどのようなものかを共有し改善することで、 ソフトウェア開発組織の問題解決や改善ができる可能性がある

※Project Fabre(プロジェクトファーブル)： http://aster.or.jp/business.html#fabre

ワーストプラクティス

• 「ベストプラクティス」はいろいろなメディアで紹介されている →JaSST等イベントで紹介される事例、Webサイト等々

• 知っていても実行できない事が多い

o 「コンテキスト」が合わないことがある

o 「ベスト」な環境は整えるのが大変

o ベストの条件＝いろいろな条件が ちょうどバランスがとれた状態 （実は特殊状況である）

11

• 「ワーストプラクティス」を回避するということでも 効果が見込めるのではないか？ • 教科書的な行儀のよい状況下だけで学んでもだめ！ • 状況とセットで、失敗を学習・共有することに意味がある。

12

アンケート調査・結果 1. アンケート実施方法 2. アンケート内容 3. アンケート結果 4. 考察および改善案

アンケート実施

• 2つの方法で調査実施(2011年１月から開始)

13

1. PC/スマートフォン 2. アンケート用紙

http://goo.gl/w3qty

ソフトウェア品質やソフトウェアテストに興味がある方を対象に インターネットや各種イベントでアンケート呼掛けと調査を実施

• JaSST等ソフトウェア品質系イベント

アンケート内容

1. どんな問題のあるバグレポートか

2. どうあるべきだったか

3. 起票された工程

4. 起票者の立場 / 経験

5. 対象ソフトウェアの規模

6. 開発のタイプ／形態

7. 印象的なバグレポート

8. その他バグレポートへの思い

14

特に回答頂きたい上記、1、2 を必須として 他の項目は任意回答とした

アンケート概要

• 自由記述と選択肢項目で構成

• 約60件の回答があった。

15

自由記述

どんな問題のあるバグレポートか

どうあるべきだったか

印象的なバグレポート

その他バグレポートへの思い

選択肢項目

起票された工程 • コンポーネントテスト • 統合テスト • システムテスト • 受入テスト • 稼働後

起票者の立場 / 経験(期間) • 開発部署 / 第三者等 • プロダクトに従事した期間を

8段階で選択

対象ソフトウェアの規模 • LOCで5段階

開発のタイプ／形態 • 派生開発 or 新規開発

アンケート結果1: 回答者

• 回答者の立場は以下のとおり

o 開発者・テスト担当者：それぞれ約30％

o 出荷テスト担当者：24％

o 分析担当等：17％

16

29%

30%

24%

17%

バグを報告する立場（チーム

内）[開発部署内のテストチー

ムなど]

バグを修正する立場（チーム

内）[開発者など]

バグを報告する立場（第三者）

[出荷検査実施者など]

上記以外の立場(バグ票を分

析する立場 等)

アンケート結果2: 起票者

• バグレポート起票者の立場は以下のとおり

o 開発内テスト担当者：46％

o 開発者：20％

o 開発チーム外のテスト担当者、データ分析者：34 ％

17

46%

20%

25%

9% バグを報告する立場（チーム

内）[開発部署内のテストチーム

など] バグを修正する立場（チーム

内）[開発者など]

バグを報告する立場（第三者）

[出荷検査実施者など]

上記以外の立場(情報を分析す

る立場 等)

アンケート結果3: テスト工程

• 問題のバグレポートのテスト工程は以下のとおり

o コンポーネントテスト：14％

o 統合テスト：44％

o システムテスト：34％

o 受け入れテスト：8％

18

14%

44%

34%

8% CT(コンポーネントテスト/単体

テスト)

IT(統合テスト/組み合わせテ

スト)

ST(システムテスト)

顧客受け入れテスト

アンケート結果4: 起票者の経験 • 経験がある方でも問題となるバグレポートを起票している

o 2年以上従事している方：52％

o 1年以上従事している方：76％

• どんな方が書いているかわからないケースがある

o 不明という回答：14％

19

52%

7%

17%

2% 3%

3% 14%

2% 24ヶ月以上

18ヶ月以上24ヶ月未満

12ヶ月以上18ヶ月未満

6ヶ月以上12ヶ月未満

3ヶ月以上6ヶ月未満

3ヶ月未満

不明(会ったことがない、聞いたこと

がない等)

アンケート結果5:

現場にあるダメなバグレポート

20

• 大きく4つに分類

o バグレポートに書かれている内容が伝わらない 39％

o バグを記載された手順で再現できない 25%

o 目的が共有されていない 19％

o フォーマットが適切でない 14％

考察および改善案

• 関係者間で「バグレポート」の目的や利用意図を共有する

• 起票のプロセスや書式を見直す

• バグレポートに起こりがちな問題を示しながら教育を行なう

21

• 統合テスト、総合テストでは多くのメンバが関わるため問題が顕在化している

• どのような方が、どのようにバグレポートを利用しているか認識されていないことがある

• バグレポートの項目に、どのように使われるか分からない項目がある。または起票者だけで判断できない場合がある

• バグレポートの問題は、経験の蓄積だけでは解決しにくい問題である

22

アンチパターン集作成 1. アンチパターンテンプレート 2. 試作例

アンチパターンテンプレート

• アンケート結果（バグレポートのワーストプラクティス）をテンプレートを利用

してモデル化し、失敗事例共有のためのアンチパターンとしてまとめる。

23

項目 内容

パターンの名前 パターンの呼び名

発生状況 発生する状況

問題の内容 発生した問題の内容

解決方法 解決方法や回避方法

関連パターン 関連パターンや相互の関係

※「アンチパターン－ソフトウェア危篤患者の救出」のパターンテンプレートより ※（観察された場所）は我々のプロジェクトのオリジナル。赤系の色で示したアイコンが 元の「ワープラ」を観察したコンテキスト。

（観察された場所） エンプラ 組込み Web その他

アンチパターン（試作1）

24

項目 内容

パターンの名前 バグピンポン

発生状況 a)起票者と解析者の（物理的・心理的）距離が離れている b)バグレポートの情報が不足している

問題の内容 バグレポートの不足情報を質問しているうちに、質問-応答の手間が増えて、お互いにイライラが募る。 なんで、その程度のことを対応してくれない？と腹が立つ ＜具体例＞ ・バグレポートでの質疑応答の往復が30回を超える ・バグかバグでないかの議論でバグレポートが炎上する

解決方法 ・マネージャが介入して調停する（北町奉行メソッド） ・動画など客観的証拠を提示する

関連パターン ＜分析中＞

（観察された場所） エンプラ 組込み Web その他

バグピンポン: 参考動画 http://agile.dzone.com/videos/end-bug-ping-pong

アンチパターン（試作2）

25

項目 内容

パターンの名前 バベルの塔

発生状況 a)後から要員を追加投入 b)全員バグレポートの作成経験はあったので、導入教育をしなかった

問題の内容 バグレポートの書き方や運用の方法が不統一 ＜具体例＞ ・同件検索効率がおち、同件のレポートが重複して登録される。結果、担当割り当てやバグ分析の効率低下が起こる

解決方法 ・バグレポートでつかう用語の用語集と運用フローをまとめ、簡単にルールを確認できるようにする ・最初の何枚かは、有識者がレビューを行う ・ルールを統一する意義や、不統一になった場合の弊害を伝える

関連パターン 「ダブリ/マルチ」

（観察された場所） エンプラ 組込み Web その他

アンチパターン（試作3）

26

項目 内容

パターンの名前 「このぐらいわかってくれよ」症候群

発生状況 a)納期が切迫して細かいことに気を遣えない b)何らかの要因で要員スキルの不適合を解消できない

問題の内容 バグレポートから必要な情報を読み取ることができない ＜具体例＞ ・問題層別情報（選択式）が設定されない。またはあまり根拠がなく選択される ・このぐらい分かるだろうと、再現条件や手順の一部が省略される ・設計仕様書内で定義のない用語が断りなく使われる ・起票理由、承認理由、修正理由などがあいまい

解決方法 ・記載コストをかける理由（ニーズ）を明確にし、 教育するか、BTSで記載を強制する

関連パターン ＜分析中＞

（観察された場所） エンプラ 組込み Web その他

アンチパターン（試作4）

27

項目 内容

プラクティスの名前 ダブリ/マルチ

発生状況 a)既存のバグレポートが検索しにくい(用語の不統一など) b)検索して確認する時間や習慣がない c)他のメンバがどんなバグレポートを起票しているか興味がない

問題の内容 a)バグに関するメトリクスが不正になる b)バグレポート担当者を割り振る人の負荷が増加する c)同一原因に基づく不具合が複数みえることで判断を誤る ＜具体例＞ ・バグが実態よりも多い件数としてカウントされ、テストの終了判断を誤る ・バグの修正担当者と再テスト担当者で異なるエビデンスがつけられたバグレポートを参照してしまい、話が食い違う

解決方法 ・同件バグがないか確認することを、起票時に盛り込む ・開発の仕組みとして、また開発者マインドとして他のバグ共有するようにする

関連プラクティス ＜分析中＞ （観察された場所） エンプラ 組込み Web その他

28

今後の展開

今後の展開

• アンチパターン集の拡充 o アンケート分析の見直しや精査

o ヒアリングや調査の継続

• BTSオンラインヘルプなどへの組込み o バグレポート起票時などの支援

• アンチパターン検出や示唆（サジェスト）機能の検討 o 起票時のチェック

o バグレポート内容分析時のチェック

29

30

まとめ

まとめ(1/2)

• バグレポートが有効に使われていない開発現場が存在する

• 悪いバグレポートとしてどのようなものがあるかは知られていない

• アンケート調査により、悪いバグレポートの調査結果から 4つの分類が見られた。

o 内容が伝わらない

o 再現手順を再現できない

o 目的が共有されていない

o フォーマットが適切で無い

• 改善案として以下のようなことが考えられる。

o 関係者間で「バグレポート」の目的・利用意図や認識を共有する

o バグレポートの起票のプロセスを見直す

o バグレポートに起こりがちな問題を示しながら教育を行なう

31

まとめ(2/2)

• アンチパターンテンプレートと適用例

o バグピンポン

o バベルの塔

o 「これくらいわかってくれよ」症候群

o ダブリ/マルチ

• 今後の展望

o アンチパターン集の拡充

o BTSオンラインヘルプなどへの組込み

o アンチパターン検出と示唆（サジェスト）機能の検討

32

続きはコミュニティブースで！

コミュニティブース出展しています！

• コミュニティ紹介

o パネル展示

• 活動内容および成果物の展示

o パネル展示

o 成果物紹介

• ご意見募集

o 投票箱

o 付箋紙/色ペン等で自由に書き込んでください

33

ご意見、ご感想をお聞かせください！！

このあたり

エレベータ

アンケートにご協力ください

o腹がたったバグレポートの事例収集にご協力を！

34

1. PC/スマートフォン 2. アンケート用紙記入

http://goo.gl/w3qty

https://sites.google.com/site/swworstpracticesite

e-mail：sw.WorstPractice@gmail.com

コミュニティブースで配布中