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

鈴木 昭吾 / 近美 克行 / 近江 久美子 / 渡辺 由希子

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 report 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％

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

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

たさない

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

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

18

29%

30%

24%

17%

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

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

チームなど]

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

ム内）[開発者など]

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

者）[出荷検査実施者など]

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

析する立場 等)

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

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

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

19

46%

20%

25%

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

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

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

内）[開発者など]

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

者）[出荷検査実施者など]

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

する立場 等)

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

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

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

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

20

14%

44%

34%

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

単体テスト)

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

スト)

ST(システムテスト)

顧客受け入れテスト

統合テスト（複数の開発チームが関係）や

システムテスト（より多くの関係者が参加）に

問題発生

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

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

どんな方が書いているかわからないケースがある 不明という回答：14％

21

52%

7%

17%

2% 3% 3%

14%

2% 24ヶ月以上

18ヶ月以上24ヶ月未満

12ヶ月以上18ヶ月未満

6ヶ月以上12ヶ月未満

3ヶ月以上6ヶ月未満

3ヶ月未満

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

ことがない等) 上記以外

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

慣れも影響？またはスキルに

関係ない状況が原因？

アンケート結果からわかったこと

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

いつ、どのようなときに起票するか共有されていない

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

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

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

アンチパターンの作成

現在のチャレンジ

アンケート結果の分類

•頂いた回答をいくつかに分類して傾向をみてラベリング

•分類については、メンバー各自の立場で検討した •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などへのパターンの実装

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