Más contenido relacionado Similar a 公開資料 バグレポートの改善に向けた問題事例の調査とアンチパターンの作成 Rev10 (20) 公開資料 バグレポートの改善に向けた問題事例の調査とアンチパターンの作成 Rev102. 謝辞
• ご協力、情報提供およびコメントをいただいたみなさまに御礼申し上げます。
• SQiPシンポジウム2012,2013,2014のSIG・発表でコメント等いただいたみなさま
• JaSST’14東京にて有益なコメントを頂いたみなさま
• JaSST’12, 13東海ポスターセッションで有益なコメントを頂いたみなさま
• WACATE分科会でアンケートや議論にご協力いただいたみなさま
• 第8回SQuBOKユーザ会勉強会にて議論させていただいたみなさま
• Webやアンケート用紙にて、ご回答をいただいたみなさま
• その他、活動のご支援やコメント等ご協力いただいたすべてのみなさま
3. 目次
• 本研究の狙い・目的
• 背景と解決したい問題
• バグレポート
• ワーストプラクティス
• いままでやってきたこと
• 先行研究の調査
• アンケート実施概要とその結果
• 現在やっていること
• パターンの作成方針
• パターン作成例
• 今後の課題
6. バグレポートがうまく使われていない例
• 「バグピンポン」
• テストエンジニアと開発者の間で発見したバグに同意がとれず、
バグを指摘したメールやバグレポートがいったりきたりすること
6
バグだ
バグピンポンの正式な原典は明らかではないが、たとえばDZoneのインタビュー等で言及されている
http://agile.dzone.com/videos/end-bug-ping-pong
開発者テスト担当
バグではない
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改善
テンプレ改善
パターン共有
ワークの実施
等、普及調査
効果測定
監査で確認
ツール化
プロセスで組織と組織運営効率を改善
運用ルール変更
組織変更検討
効果測定
変更の実行
いまここ
きっかけ
問題記述(仮) 問題確認
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. アンケート結果からわかったこと
どのような方が、どのようにバグレポートを利用して
いるか認識されていない
いつ、どのようなときに起票するか共有されていない
バグレポートの項目に、どのように使われるか分から
ない項目がある。または起票者だけで判断できない場
合がある
バグレポートの問題は、経験の蓄積だけでは解決しに
くい問題である
バグレポートに起こりがちな問題をアンチパターンを
示しながら学習・教育を行なうことが有効。
26. アンチパターン作成
• 「Pattern Writing Sheet」を利用してアンチパターンを試みた
• アンチパターンはパターンとほぼ同じ構成と考えられる
• 視覚的にわかりやすい
http://creativeshift.jp/sheet/ より引用
27. 1. アンケート結果より問題を分類
2. 「Pattern Writing Sheet」のフォーマットでパターンを抽出
a. 「Pattern Writing Sheet」の記入順序をシートガイドから変更。
Problem からForces・Context 等を検討したのち、
Solution やAction・Consequence を記載した。
36. 評価および改善
• アンチパターンの拡充
• 分類に従い、アンチパターンを作成していく。
• 評価および改善
• ワークショップ形式で評価と改善を行なう。
・「プレパタ」など人間の活動に関する
試験の形式化や評価の方法が使えそう
※http://presentpatterns.sfc.keio.ac.jp/
・慶応大学井庭氏の方法論が参考
38. 今後の課題
• アンチパターン集の拡充
• アンチパターンの評価および変更・修正
• アンチパターンが使えるか/共有できたかをパターン・ランゲージ
を評価している方法で調査する
• フィードバックより、変更等を行なう
• BTSなどへのパターンの実装
Notas del editor 楕円:アクション、四角(オレンジ):ステータス、四角(緑):終端ステータス、→(実線):主フロー、→(破線):代替えフロー