バグ票ワーストプラクティス検討プロジェクト鈴木 昭吾 / 近美 克行 / 近江 久美子 / 渡辺 由希子

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

sw.WorstPractice@gmail.com

バグレポートの改善に向けた問題事例の調査とアンチパターン作成

SQiP2014 招待講演

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

• SQiP シンポジウム 2012,2013,2014 の SIG ・発表でコメント等いただいたみなさま

• JaSST’14 東京 にて有益なコメントを頂いたみなさま• JaSST’12, 13 東海ポスターセッションで有益なコメントを頂いたみなさま• WACATE 分科会でアンケートや議論にご協力いただいたみなさま• 第 8 回 SQuBOK ユーザ会勉強会にて議論させていただいたみなさま• Web やアンケート用紙にて、ご回答をいただいたみなさま• その他、活動のご支援やコメント等ご協力いただいたすべてのみなさま

目次• 本研究の狙い・目的• 背景と解決したい問題• バグレポート• ワーストプラクティス

• いままでやってきたこと• 先行研究の調査• アンケート実施概要とその結果

• 現在やっていること• パターンの作成方針• パターン作成例

• 今後の課題

背景や意義はじめに

背景

ﾃｽﾀｰﾌﾟﾛｸﾞﾗﾏ

設計者QA

ｻﾎﾟｰﾄ経営者

ﾏﾈｰｼﾞｬユーザ

バグレポート

開発現場では、バグレポートは有効に利用されていないのでは？（※バグレポート＝ ISTQB 用語集のインシデントレポート）

バグレポートは、今日ソフトウェア開発の多くの組織で使われている。

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

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

6

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

テスト担当開発者バグだ

バグではない

バグレポートがうまくつかわれるとは

• 良いバグレポートはバグレポートのライフサイクルが、問題なく遷移していくこと

バグ報告組織 バグ分析・対策組織

Open発行 開始判断 解析開始承認済み

担当者割当て

解析担当割当済み

解析実行

修正待ち

次 Verへ延期

修正実行

再テスト待ち確認テスト

実行

再テスト済み

解決済み

テスト結果判定

調査

再調査依頼却下（テストミス・仕様通り）

重複

※JSTQB シラバス、 IEEE829をから例示されたステータスを抽出し、状態遷移を作成

バグピンポンの例バグ報告組織 バグ分析・対策組織

Open発行 開始判断 解析開始承認済み

担当者割当て

解析担当割当済み

解析実行

修正待ち

次 Verへ延期

修正実行

再テスト待ち確認テスト

実行

再テスト済み

解決済み

テスト結果判定

調査

再調査依頼却下（テストミス・仕様通り）

重複

終端に進まず再調査依頼と Openを循環してしまう

組織の分断や責任分担が適切でないと発生

意義

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

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

1. バグレポートが活用できないために多くの弊害が発生している。• 内容確認等のコミュニケーションのために無駄な工数が発生。• ソフトウェアテストに対する弊害

• 正確な品質状況がつかめない• プロセス改善に対する弊害

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

• 組織のプロセスなどの弱点や問題点が見出しにくい。• 組織のマネジメント力や個人の能力向上ができない。

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

ワーストプラクティス• 「ベストプラクティス」はいろいろなメディアで紹介されて

いる→ SQiP 等イベントで紹介される事例、 Webサイト等々　知っていても実行できない事が多い• 「コンテキスト」が合わないことがある• 「ベスト」な環境は整えるのが大変• ベストの条件＝いろいろな条件がちょうどバランスがとれた状態（実は特殊状況である）

「ワーストプラクティス」を回避するということでも効果が見込めるのではないか？

• 教科書的な行儀のよい状況下だけで学んでもだめ！• 状況とセットで、失敗を学習・共有することに意味がある。

先行研究の調査• 海外の事例（文献）• Modeling bug report quality• "Not my bug!" and other reasons for software bug re

port reassignments• What Makes a Good Bug Report?

• 「Making Software ―エビデンスが変えるソフトウェア開発」

「第 25 章　バグレポートの技芸」に邦訳あり

• 海外での研究事例はあるが、国内ではあまり議論されていない• CiNii での検索すると、「バグレポート」で 9 件、

「バグ票」で 1件バグレポートの改善に関する文献はほとんどない

　→バグレポートに関する調査を自分たちでやってしまおう！

研究活動の全体像• 研究はコミュニティーベースで活動（現在アクティブメンバーは 3名）• バグレポートが活用されていないのではないか？それはなぜなのか？どうすればもっと活用できるのか？が関心事

• アプローチは以下のとおり

対策実行・検証

対策立案・実行フェーズ問題定義・確認フェーズ

対策検討

バグ票が活用されていない？

実態調査のためのアンケート設計

アンケートで実態調査

現場で良くある問題

アンケート分析

ｱﾝﾁﾊﾟﾀｰﾝ作成と共有

BTS 改善テンプレ改善

効果測定監査で確認ツール化

パターン共有ワークの実施等、普及調査

運用ルール変更組織変更検討

効果測定変更の実行

（知見共有）で人間の判断を改ﾊﾟﾀｰﾝ善

ツールで効率と正確性を改善

プロセスで組織と組織運営効率を改善

いまここきっかけ

問題確認問題記述（仮）

アンケートの内容や結果いままでやってきたこと

実態調査のためのアンケート設計

アンケートで実態調査

アンケート分析

現場でよくある問題

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

アンケート実施

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

http://goo.gl/w3qty

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

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

アンケート内容

1. どんな問題のあるバグレポートか2. どうあるべきだったか3. 起票された工程4. 起票者の立場 / 経験5. 対象ソフトウェアの規模6. 開発のタイプ／形態7. 印象的なバグレポート8. その他バグレポートへの思い

15

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

アンケート設問• 自由記述と選択肢項目で構成

• 約 60件のデータを元に調査

自由記述

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

どうあるべきだったか

印象的なバグレポート

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

選択肢項目

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

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

8段階で選択

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

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

アンケート結果現場にあるダメなバグレポート • 大きく 4つに分類

o バグレポートに書かれている内容が伝わらない　 39 ％o バグを記載された手順で再現できない 25%o 目的が共有されていない 19 ％o フォーマットが適切でない 14％

バグ修正のための報告書として、伝える目的を達成し

ていない

多くのプロセスモデルの「問題解決管理」エリアが要求する、優先付や傾向分析等の

機能を果たさない

※詳細については、 SQiP シンポジウム 2014 での発表資料を参照

アンケート結果 : 回答者回答者の立場は以下のとおり

開発者・テスト担当者：それぞれ約 30％出荷テスト担当者： 24％分析担当等： 17％

18

開発者、テスト担当者、第三者テスト担当者などバランスよく意見

を回収

アンケート結果 : 起票者バグレポート起票者の立場は以下のとおり

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

19

開発内テスト担当者による問題となる

バグ票事例が多く収集された

アンケート結果 : テスト工程問題のバグレポートのテスト工程は以下のとおり

コンポーネントテスト： 14％統合テスト： 44％システムテスト： 34％受け入れテスト： 8％

20

統合テスト（複数の開発チームが関係）やシステムテスト（より多くの関係者が参

加）に問題発生

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

2年以上従事している方： 52％1年以上従事している方： 76％どんな方が書いているかわからないケースがある不明という回答： 14％

21

ベテランでも問題バグ票を書いている

慣れも影響？またはスキルに関係ない状況が原因？

アンケート結果からわかったこと どのような方が、どのようにバグレポートを利用しているか認識されていない

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

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

バグレポートに起こりがちな問題をアンチパターンを示しながら学習・教育を行なうことが有効。

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

アンケート結果の分類• 頂いた回答をいくつかに

分類して傾向をみてラベリング

• 分類については、メンバー各自の立場で検討した

• QA/ 開発 /マネジャー

アンチパターン作成

• 少し進めてみて、 SQiP2013から内容を変更• 以前のテンプレートで

はまとめにくい• 情報がもう少し欲しい

SQiP2013 での資料

アンチパターン作成• 「 Pattern Writing Sheet 」を利用してアンチパターンを試みた

• アンチパターンはパターンとほぼ同じ構成と考えられる• 視覚的にわかりやすい

http://creativeshift.jp/sheet/ より引用

1. アンケート結果より問題を分類2. 「 Pattern Writing Sheet 」のフォーマットでパターンを抽出

a. 「 Pattern Writing Sheet 」の記入順序をシートガイドから変更。Problem から Forces ・ Context 等を検討したのち、Solution や Action・ Consequence を記載した。

作成したアンチパターン

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

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

アンチパターンを作成してみて

ボトムアップアプローチでの構造化に限界•（当初）集めたアンケードからボトムアップでパターン構築•そもそも全体が不明なので研究→途中で構造化に息づまる。全体を俯瞰しながら再調整しないと矛盾がでる（体系が崩れて使いにくいパターン集になってしまう）

バグレポートのステータス遷移モデルを活用•（対策）バグレポートのステータス遷移モデルを活用し、バグレポートの「アンチパターン」の全体をまず理解。•その後に収集された個々のワーストプラクティスをマッピング

というアプローチを併用（このアプローチは今後の課題）

アンチパターンを作成してみて

バグレポートアンチパターンの全体モデル•バグレポートの問題の定義：バグレポートのライフサイクル上で処理ステータスの遷移に不都合がでること•遷移に不都合がでるのは大きく 3種類

①

②③

①ぐるぐる　やりとりが延々続き　処理が先に進まない

②ストップ　情報不足・判断権限　がなく処理不可

③適当進捗　強引に Close Close判断理由なし　

バグレポートアンチパターンの全体モデル•バグレポート処理の成功ケース：　①②③も発生せずに無事 Close•バグレポート処理の失敗ケース：　①②③がいずれかが発生“適切”に Close できず。　

①

②③

①ぐるぐる　やりとりが延々続き　処理が先に進まない

②ストップ　情報不足・判断権限　がなく処理不可

③適当進捗　強引に Close Close判断理由なし　

アンチパターンは②を避けようとして①になるなど、失敗ケースを避けて別の失敗ケースに遷移すること

バグピンポンの考察•バグ／バグでないの判断をするだけの情報や合意基準がない　　⇒判断できないので②ストップや③適当進捗が発生•組織に、適切にバグ処理を進めるというプレッシャー•②や③を避けて、早く処理をしたいくなる•今度は①ぐるぐるが発生

　

①

②③

①ぐるぐる　やりとりが延々続き　処理が先に進まない

②ストップ　情報不足・判断権限　がなく処理不可

③適当進捗　強引に Close Close判断理由なし　

ピンポン発生の背景には、組織が分断している、バグ /バグでないの判断権限や合意基準不足がある。

→①②③を同時に消す方法が　　求めるもの（パターン）

→そのために、①から②、①から③・・・などの間違った対策例を分析（アンチパターン）

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

評価および改善• アンチパターンの拡充

• 分類に従い、アンチパターンを作成していく。• 評価および改善

• ワークショップ形式で評価と改善を行なう。　　　・「プレパタ」など人間の活動に関する　　　　　試験の形式化や評価の方法が使えそう

※http://presentpatterns.sfc.keio.ac.jp/　　　　 ・慶応大学井庭氏の方法論が参考

まとめ

今後の課題• アンチパターン集の拡充• アンチパターンの評価および変更・修正

• アンチパターンが使えるか /共有できたかをパターン・ランゲージを評価している方法で調査する

• フィードバックより、変更等を行なう

• BTS などへのパターンの実装

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