Jasst14tokyo 公開資料_バグレポートの問題事例の調査と改善のためのアンチパターン集の作成
0 likes4,767 views
JaSST14Tokyoでの発表資料です。 http://jasst.jp/symposium/jasst14tokyo/details.html#C2-2
![アンケート結果1: 回答者
? 回答者の立場は以下のとおり
o 開発者?テスト担当者：それぞれ約30％
o 出荷テスト担当者：24％
o 分析担当等：17％
17%
29%
バグを報告する立場（チーム
内）[開発部署内のテストチー
ムなど]
バグを修正する立場（チーム
内）[開発者など]
バグを報告する立場（第三者）
[出荷検査実施者など]
24%
30%
上記以外の立場(バグ票を分
析する立場 等)
16](https://image.slidesharecdn.com/jasst14tokyorev7-140307174918-phpapp02/85/Jasst14tokyo-_-16-320.jpg)
![アンケート結果2: 起票者
? バグレポート起票者の立場は以下のとおり
o 開発内テスト担当者：46％
o 開発者：20％
o 開発チーム外のテスト担当者、データ分析者：34 ％
9%
25%
46%
バグを報告する立場（チーム
内）[開発部署内のテストチーム
など]
バグを修正する立場（チーム
内）[開発者など]
バグを報告する立場（第三者）
[出荷検査実施者など]
20%
上記以外の立場(情報を分析す
る立場 等)
17](https://image.slidesharecdn.com/jasst14tokyorev7-140307174918-phpapp02/85/Jasst14tokyo-_-17-320.jpg)
Jasst14tokyo 公開資料_バグレポートの問題事例の調査と改善のためのアンチパターン集の作成
- 1. JaSST’14 Tokyo 経験発表 バグレポートの問題事例の調査と 改善のためのアンチパターン集の作成 バグ票ワーストプラクティス検討プロジェクト 鈴木 昭吾, 近美 克行, 近江 久美子, 渡辺 由希子, 森崎 修司 e-mail：sw.WorstPractice@gmail.com Web: https://sites.google.com/site/swworstpracticesite/
- 3. ? ご協力、情報提供およびコメントをいただいたみなさまに御礼申し上げます。 o JaSST’12, 13東海ポスターセッションで有益なコメントを頂いたみなさま o SQiPシンポジウム2012, 2013 のSIGでご協力いただいたみなさま o WACATE分科会でアンケートやディスカッションにご協力いただいたみなさま、 有益なコメントをいただいたみなさま o 第8回SQuBOKユーザ会勉強会にて議論させていただいたみなさま o Webやアンケート用紙にて、ご回答をいただいたみなさま o その他、活動のご支援やコメント等ご協力いただいたすべてのみなさま ありがとうございました。 3
- 4. 目次 1. はじめに 1. 2. 3. 4. 背景 バグレポートがうまく使われていない例 意義 ワーストプラクティス 2. アンケート調査?結果 1. 2. 3. 4. アンケート実施方法 アンケート内容 アンケート結果 考察および改善案 3. アンチパターン集作成 1. 2. アンチパターンテンプレート 試作例 4. 今後の展開 5. まとめ 4
- 7. バグレポートがうまく使われていない例1 ? 「バグピンポン」 o テストエンジニアと開発者の間で発見したバグに同意がとれず、 バグを指摘したメールやバグレポートがいったりきたりすること バグだ テスト担当 開発者 バグでは ない ? バグピンポンの正式な原典は明らかではないが、たとえばDZoneのインタビュー等で言及されている http://agile.dzone.com/videos/end-bug-ping-pong 7
- 9. バグレポートがうまく使われていない例3 ? 「なにかがおかしい」 ? バグ修正するために必要な情報が書かれていない。 例：「エラーになりました。」 等 ? リツィートが約700、 リプライは16あり 大きな反響があった ? 多くの方が同じような 状況で困っている様 子が伺える https://twitter.com/yukihiro_matz/status/312534609495736320 より引用 9
- 10. 意義 1. バグレポートが活用できないために多くの弊害が発生している。 o 内容確認等のコミュニケーションのために無駄な工数が発生。 o ソフトウェアテストに対する弊害 ? 重複したバグレポートがあり正確な品質状況がつかめない o プロセス改善に対する弊害 ? Project Fabre(プロジェクトファーブル）などで提唱している 欠陥のパターン（バグマスター）が作成できない etc. ? 組織のプロセスなどの弱点や問題点が見出しにくい 2. バグレポートの書き方を解説している書籍などは多い。 （例：「ソフトウェアテスト293の鉄則」など） しかし、悪いバグレポートがどのようなものかは議論があまりない。 (例：「Making Software エビデンスが変えるソフトウェア開発」) 悪いバグレポートがどのようなものかを共有し改善することで、 ソフトウェア開発組織の問題解決や改善ができる可能性がある ※Project Fabre(プロジェクトファーブル)： http://aster.or.jp/business.html#fabre 10
- 11. ワーストプラクティス ? 「ベストプラクティス」はいろいろなメディアで紹介されている →JaSST等イベントで紹介される事例、Webサイト等々 ? 知っていても実行できない事が多い o 「コンテキスト」が合わないことがある o 「ベスト」な環境は整えるのが大変 o ベストの条件＝いろいろな条件が ちょうどバランスがとれた状態 （実は特殊状況である） ? 「ワーストプラクティス」を回避するということでも 効果が見込めるのではないか？ ? 教科書的な行儀のよい状況下だけで学んでもだめ！ ? 状況とセットで、失敗を学習?共有することに意味がある。 11
- 13. アンケート実施 ? 2つの方法で調査実施(2011年１月から開始) 1. PC/スマートフォン 2. アンケート用紙 http://goo.gl/w3qty ソフトウェア品質やソフトウェアテストに興味がある方を対象に インターネットや各種イベントでアンケート呼掛けと調査を実施 ? JaSST等ソフトウェア品質系イベント 13
- 14. アンケート内容 1. 2. 3. 4. 5. 6. 7. 8. どんな問題のあるバグレポートか どうあるべきだったか 起票された工程 起票者の立場 / 経験 対象ソフトウェアの規模 開発のタイプ／形態 印象的なバグレポート その他バグレポートへの思い 特に回答頂きたい上記、1、2 を必須として 他の項目は任意回答とした 14
- 15. アンケート概要 ? 自由記述と選択肢項目で構成 自由記述 選択肢項目 どんな問題のあるバグレポートか どうあるべきだったか 起票された工程 ? コンポーネントテスト ? 統合テスト ? システムテスト ? 受入テスト ? 稼働後 印象的なバグレポート 起票者の立場 / 経験(期間) ? 開発部署 / 第三者等 ? プロダクトに従事した期間を 8段階で選択 その他バグレポートへの思い 対象ソフトウェアの規模 ? LOCで5段階 ? 約60件の回答があった。 開発のタイプ／形態 ? 派生開発 or 新規開発 15
- 16. アンケート結果1: 回答者 ? 回答者の立場は以下のとおり o 開発者?テスト担当者：それぞれ約30％ o 出荷テスト担当者：24％ o 分析担当等：17％ 17% 29% バグを報告する立場（チーム 内）[開発部署内のテストチー ムなど] バグを修正する立場（チーム 内）[開発者など] バグを報告する立場（第三者） [出荷検査実施者など] 24% 30% 上記以外の立場(バグ票を分 析する立場 等) 16
- 17. アンケート結果2: 起票者 ? バグレポート起票者の立場は以下のとおり o 開発内テスト担当者：46％ o 開発者：20％ o 開発チーム外のテスト担当者、データ分析者：34 ％ 9% 25% 46% バグを報告する立場（チーム 内）[開発部署内のテストチーム など] バグを修正する立場（チーム 内）[開発者など] バグを報告する立場（第三者） [出荷検査実施者など] 20% 上記以外の立場(情報を分析す る立場 等) 17
- 18. アンケート結果3: テスト工程 ? 問題のバグレポートのテスト工程は以下のとおり o コンポーネントテスト：14％ o 統合テスト：44％ o システムテスト：34％ o 受け入れテスト：8％ 8% CT(コンポーネントテスト/単体 テスト) 14% IT(統合テスト/組み合わせテ スト) 34% ST(システムテスト) 44% 顧客受け入れテスト 18
- 19. アンケート結果4: 起票者の経験 ? 経験がある方でも問題となるバグレポートを起票している o 2年以上従事している方：52％ o 1年以上従事している方：76％ ? どんな方が書いているかわからないケースがある o 不明という回答：14％ 2% 3% 3% 2% 24ヶ月以上 18ヶ月以上24ヶ月未満 14% 12ヶ月以上18ヶ月未満 6ヶ月以上12ヶ月未満 52% 17% 3ヶ月以上6ヶ月未満 3ヶ月未満 7% 不明(会ったことがない、聞いたこと がない等) 19
- 20. アンケート結果5: 現場にあるダメなバグレポート ? 大きく4つに分類 o バグレポートに書かれている内容が伝わらない 39％ o バグを記載された手順で再現できない 25% o 目的が共有されていない 19％ o フォーマットが適切でない 14％ 20
- 21. 考察および改善案 ? 統合テスト、総合テストでは多くのメンバが関わるため問題が顕在化している ? どのような方が、どのようにバグレポートを利用しているか認識されていない ことがある ? バグレポートの項目に、どのように使われるか分からない項目がある。または 起票者だけで判断できない場合がある ? バグレポートの問題は、経験の蓄積だけでは解決しにくい問題である ? 関係者間で「バグレポート」の目的や利用意図を共有する ? 起票のプロセスや書式を見直す ? バグレポートに起こりがちな問題を示しながら教育を行なう 21
- 28. 今後の展開 28
- 29. 今後の展開 ? アンチパターン集の拡充 o アンケート分析の見直しや精査 o ヒアリングや調査の継続 ? BTSオンラインヘルプなどへの組込み o バグレポート起票時などの支援 ? アンチパターン検出や示唆（サジェスト）機能の検討 o 起票時のチェック o バグレポート内容分析時のチェック 29
- 30. まとめ 30
- 31. まとめ(1/2) ? バグレポートが有効に使われていない開発現場が存在する ? 悪いバグレポートとしてどのようなものがあるかは知られていない ? アンケート調査により、悪いバグレポートの調査結果から 4つの分類が見られた。 o 内容が伝わらない o 再現手順を再現できない o 目的が共有されていない o フォーマットが適切で無い ? 改善案として以下のようなことが考えられる。 o 関係者間で「バグレポート」の目的?利用意図や認識を共有する o バグレポートの起票のプロセスを見直す o バグレポートに起こりがちな問題を示しながら教育を行なう 31
- 32. まとめ(2/2) ? アンチパターンテンプレートと適用例 o バグピンポン o バベルの塔 o 「これくらいわかってくれよ」症候群 o ダブリ/マルチ ? 今後の展望 o アンチパターン集の拡充 o BTSオンラインヘルプなどへの組込み o アンチパターン検出と示唆（サジェスト）機能の検討 続きはコミュニティブースで！ 32
- 33. コミュニティブース出展しています！ ご意見、ご感想をお聞かせください！！ ? コミュニティ紹介 o パネル展示 ? 活動内容および成果物の展示 o パネル展示 o 成果物紹介 ? ご意見募集 o 投票箱 o 付箋紙/色ペン等で自由に書き込んでください エレベータ このあたり 33
- 34. アンケートにご協力ください o 腹がたったバグレポートの事例収集にご協力を！ 1. PC/スマートフォン 2. アンケート用紙記入 http://goo.gl/w3qty コミュニティブースで配布中 e-mail：sw.WorstPractice@gmail.com https://sites.google.com/site/swworstpracticesite 34