バグ票ってなんなんだ
この記事はネタ動画の下書きにすぎないです。
琴葉姉妹のよくわからないIT用語講座～バグ票 https://t.co/ACyo3uD4Sx #sm37083629 #ニコニコ動画
— mima_ita (@mima_ita) June 24, 2020
テストなどを実施した際、期待する結果とことなった挙動をシステムがした場合に記録するための文章をバグ票といいます。
他にも次のような言い回しがあります。
バグレポート、インシデントレポート、欠陥レポート、チケット、Issue、不具合表、障害票、問起票、課題票、問題票などです。
「バグ～」と呼称する場合もがありますが、期待と挙動がことなったからといってそれがすなわち、バグ＝欠陥が存在するという意味ではありません。
あくまで、調査が必要な事象になります。
、
バグ票の目的
バグは次の目的のために記録される場合が多いです。
・インシデントに関する情報提供
・テスト対象のシステムの品質と進捗に関する情報提供
・次プロジェクトのための情報提供
インシデントに関する情報提供
テストが期待通りの結果にならなかった場合や、サービスが期待どおりに動作しなかった場合、その原因を調べる必要があります。
自分だけではその原因を調べて、解決するのは困難な場合があります。
その場合は、情報を提供して問題解決の助けを得る必要があります。
プロジェクトの計画のための情報提供
バグの発生状況はプロジェクトの計画や進捗管理に有効な情報を与えてくれます。
たとえば大量にバグが発生していて解決する見込みのない場合、プロジェクトを中止する判断が必要になるかもしれません。
そこまで大きな判断でなくても特定のバグが解決するまでは、関連するテストを全て中断するという計画変更が必要になるかもしれません。
また、特定の機能で大量のバグが発生している時は、その機能に対してテストを中断して、設計、実装工程から見直す必要があります。逆に特定の機能でまったくバグが発生しない場合、その機能のテストが正しいか確認する必要があります。
次プロジェクトのための情報提供
バグの件数を記録しておくと次以降の指標になります。
たとえば、同じ規模のシステムで、バグ件数がいつもより多いプロジェクトは何かの問題が含まれている可能性はあります。
また、バグの発生原因を詳しく見て分類することで、開発工程上の問題を見つけることが可能になります。
バグ票の項目
次のような項目が記録されているケースが多いです。
- 識別番号
- 概要/タイトル
- 発生日
- 報告者
- 担当者
- 優先度/重大度
- 発生手順/期待する動作/実際の動き
- 発生環境
- 原因/対策
- 発生バージョン
- 修正バージョン
- 修正箇所
- 添付資料
バグ項目の解説
識別番号
バグ票を一意に識別できる番号を割り当てる必要があります。
テスト結果とバグ票をバグ票の識別番号で関連付ける場合が多いです。
概要/タイトル
バグを一覧形式で表示する場合に、表示されるタイトルになります。
一覧で出した時に、タイトルを見ただけでどのような内容かを予測できる必要があります。
たとえば「XXがおかしい」とか「typoがある」いったようなフワッとしたタイトルではなく、「注文画面における消費税計算の結果が期待と異なる」とか「注文画面が画面設計書と異なる」といった一目でわかるようにします。
発生日
いつ事象が発生したかを記録します。
いつの処理によって発生したかが重要な場合もありますし、システムによっては、発生日から当時のログを調べて原因を探る場合があります。
報告者
報告した人間・またはチームや組織を記載します。
追加情報を求める時に必要だったり、修正の確認をする際に必要です。
担当者
現在のバグ票の調査または修正を行う人間・またはチームや組織を記載します。
バグ票を登録する際に記載する必要はなく、多くの場合、管理者が判断して記載します。
重大度/優先度
重大度はバグ票で発生した事象による影響の大きさを記載します。
誤字等ならば影響は少ないですし、システムダウンやデータの破壊ならば影響は大きいです。
優先度はバグ票の調査を優先する目安です。
例えば、この事象を解決しなければ多くの機能が動作しないものならば優先度は高くなりますす。逆にシステムダウンをもたらす重大な事象でも、発生リスクが低ければ優先度は低くなる場合があります。
バグ票を登録する際に記載するか、どうかは議論がわかれます。
すくなくともプロジェクトの状況にたいして正しい判断を下せる人間でなければ記載できないでしょう。
発生手順/期待する動作/実際の動き
どのようにして事象が発生するかの手順と、期待する動作、そして実際にどうなってしまったかを記載します。
発生手順はどのようにしたら再現できるかを簡潔に記載した方が望ましいでしょう。
発生環境
事象が発生した環境を記載します。
OS名やブラウザ名、CPUやメモリなどのハードウェアの情報を記載します。
実行環境が固定されている場合は記載の必要がない場合はありますが、複数の環境をサポートしている場合は、この情報が必要になります。たとえばChromeでは再現しないが、IE11では再現するケースなどがあるからです。
原因/対策
どのような原因でその事象が発生したのかと、もし修正があるとしたらどのような対策を行ったかを記載します。
発生バージョン
どのバージョンで発生したかを記録します。
配布するアプリケーションの場合や、複数のバージョンをテストしている場合、発生バージョンは重要になります。
最新バージョンでは解決されているかもしれませんし、特定のバージョンから発生するようになった事象かもしれません。
修正バージョン
修正が発生した場合、どのバージョンから修正された機能が適用されるかを記載します。
修正箇所
修正した資材を記載します。ソースコードだったり、ドキュメントだったりします。
また、修正箇所から影響範囲を調査する必要があります。必要に応じては新しいバグ票を登録する必要があるかもしれません。
添付資料
実際の画面を記録ししたスクリーンショットや、スタックトレース、ログなどの関連情報を添付します。
IEEE829ではどうなっているか？
Standard for Software Test Document(IEE Std 829-1998)にはバグ票の構成について記載されています。
IEEE Standard for Software Test Documentation
https://twiki.cern.ch/twiki/pub/EMI/EmiSa2CertTestGuidelines/741968.pdf
なお、この文章ではバグ票を「Test incident report」と表現しています。
バグ票は、次の構造を持たなければならないです。
a) Test incident report identifier;(識別子)
b) Summary;(概要）
c) Incident description;(説明）
d) Impact.(影響）
これは指定された順序で並べなければいけません。最後に追加のセクションを含めてもよいです。
「説明」には以下の項目が含まれます。
a) Inputs;（入力）
b) Expected results;（期待する結果）
c) Actual results;（実際の結果）
d) Anomalies;（異常現象）
e) Date and time;（日付）
f) Procedure step;（手順）
g) Environment;(環境）
h) Attempts to repeat;（再現手順）
i) Testers;（テスト担当者）
j) Observers（オブザーバー）
どの項目が問題解決に有効か
下記の記事では、各バグ票の項目が開発者にとってどの程度役に立つかという調査を行っています。
『What Makes a Good Bug Report?』 N-Bettenburg - 2008
http://thomas-zimmermann.com/publications/files/bettenburg-fse-2008.pdf
この記事ではAPACH, Eclipse,MOZILLAの各プロジェクトでバグ報告者と開発者にアンケートを取りました。
以下のバグ票の項目で開発者と報告者に対して「開発者が実際に使用した項目」、「開発者にとってもっとも役に立った項目」、「報告者が提供した項目」、「報告者が最も役にたったと期待される項目」を比較しています。
- product
- hardware
- observed behavior
- screenshots
- component
- operating system
- expected behavior
- code examples
- version
- summary
- steps to reproduce
- error reports
- severity
- build information
- stack traces
- test cases
その結果は以下のようになります。
開発者にとって最も役にたった項目は「steps to reproduce」の再現手順になります。
「stack traces」と「test cases」、「code examples」は開発者、報告者共に役立つと思われていますが、実際に提供されている割合は少ないです。
例外発生時などの「stack traces」はログなどに埋め込まれているケースが多く、これが提供されずらい原因になっていると思います。この辺りは例外発生時の報告の仕組みを組み込んでおけば解決しやすいと思われます。
「screenshots」は開発者の助けになってはいますが、報告者は役に立つとは思っていないようです。
バグ票のワークフロー
バグ票は登録だけでなく、その後のワークフローを考える必要があります。
よくあるワークフローは以下のようなものです。
バグ票が登録されるとバグ票の状態は「オープン」となります。
登録されたバグ票を分析します。
場合によっては、その事象が勘違いだったり、テストミスだったりする場合があります。
あるいは故障ではあるが、工数の関係であえて修正しないという判断を下す場合もあります。
この場合、「却下」という状態として終了となります。
もし、何らかの故障で修正が必要な場合は、担当者に割当をして原因の調査と修正を依頼します。
バグを修正したあとは、修正の確認をします。
修正が適切になされていると判断された場合は、バグ票はクローズとなります。
もし、修正が不適切だった場合、再度、「分析・割当」を行います。
バグ票の品質
よいバグ票は問題の優先度と重大度を適切に判断することができ、また問題解決をスムーズに行う手助けになります。逆に悪いバグ票は優先度と重大度の判断や問題解決を困難にします。
しかし、よいバグ票を書くのは実は難しいものです。少なくとも訓練していない人がよいバグ票を書くことは無理でしょう。
自プロジェクトにあった適切なガイドライン作成と訓練を行うことをお勧めします。
ガイドラインの例
インターネットを調べると様々なバグ票の作成ガイドラインを見つけることができます。
Ruby バグレポートガイドライン
https://bugs.ruby-lang.org/projects/ruby/wiki/HowToReportJa
PostgreSQLのガイドライン
https://www.postgresql.jp/document/7.3/tutorial/bug-reporting.html
Mozillaでのガイドライン
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines
Web kitでのガイドライン
https://webkit.org/bug-report-guidelines/
良いバグ票を書くためのRIMGEN
RIMGENはよいバグ票を書くためのニーモニックです。
What is RIMGEN?
https://bbst.courses/rimgen/
How to Write a Good Bug Report, use RIMGEN
https://www.kenst.com/2018/02/how-to-write-a-good-bug-report-use-rimgen/
RIMGENは以下の頭文字をとったものです。
R – Replicate(再現性)
I – Isolate（独立性）
M – Maximize(最大化)
G – Generalize(一般化)
E – Externalize(外部化)
N – Neutral Tone(中立的なトーン)
R – Replicate(再現性)
別のマシンで問題を再現するために必要な手順や条件など、バグを修正するのに十分な情報を含める必要があります。
I – Isolate（独立性）
問題を再現するために必要な最短手順を記述します。
また、1つのバグ票ごとに1つの問題のみを記述します。これは一部の問題のせいで、他の解決された問題がクローズできないということを防ぎます。
M – Maximize(最大化)
問題を最大化するということは、最初に報告しようとした事象より深刻な問題をみつけるためのフォローアップテストを行うことを意味します。
例：
CSVのファイルがアップロードできない。
これを詳しくみるとPowerPointのファイルをアップロードするとバッググラウンドのプロセスが異常終了していた。これにより再起動するまでファイルのアップロードができなくなる。
G – Generalize(一般化)
バグを一般化するとは、問題が当初考えていたよりも多くの方法でより多くの人に影響を与えるか確認することです。
例：
Windows 7で動作させた場合ファイルアップロードができなかった。
Windows 10でファイルのアップロードができるか確認する。
E – Externalize(外部化)
バグ票の焦点を失敗したプログラムから影響を受けるステークホルダーに切り替え、それが彼らにどのように影響するかを示します。
たとえば以下のような情報をテスト結果に加えて追記します。
- 競合他社との比較
- 報道による予測された批判
- ユーザビリティの弱点
- 予測されるサポートコスト
- 販売、サポート、法務などに対するその他の影響
N – Neutral Tone(中立的なトーン)
バグ票は読みやすく、理解しやすくそして、中立のトーンで書かれていることを目指します。
たとえば、思い込みでバグ票を書いたり、バグ票を読んだ人を怒らせたりしないようにしましょう。
ダメな記載例：
驚愕のド素人開発だったことが判明。権限ないとき用の画面すら用意されていなかった。
バグ票ワーストプラクティス
よくないバグ票を研究することでいいバグ票とはなんなのかを探る研究もあります。
バグ票ワーストプラクティス検討プロジェクト
https://sites.google.com/site/swworstpracticesite/home/introduction
以下の資料にそのいくつかが記載されています。
はじめてのバグ票システム ～導入実践ガイド 1.1版
https://naite.swquality.jp/?page_id=40
| アンチパターン名 | 概要 |
|---|---|
| バグピンポン | テスト担当者と開発者の間で，「バグである」「バグではない(または，仕様である等)」というやり取りが収束しない状態 |
| バベルの塔 | バグ票に記載する用語や記載ルールが不統一であることから、優先度の判定や品質分析などのバグ管理に支障をきたす現象。 |
| 「このぐらいわかってくれよ」症候群 | バグを丁寧に記載する余裕がなくなり、入力項目を省略したり、再現手順などが一部省略されたりします。 |
| 書き手理解不足 | 読み手がどのような情報がほしいか把握していないままバグ票を起票してしまうこと |
バグ票の品質を計測する
不特定多数から大量のバグ票が登録される状況の場合、バグ票の対応が負担になる場合があります。この際、バグ票の品質を計測することができればバグ対応の効率を上げることができるでしょう。
CUEZILLA
バグ票の品質測定のプロトタイプとして作成されたツール「CUEZILLA」について以下の記事で言及されています。
『What Makes a Good Bug Report?』 N-Bettenburg - 2008
http://thomas-zimmermann.com/publications/files/bettenburg-fse-2008.pdf
CUEZILLAはバグ票中のキーワードに基づいてスコアを計算します。さらにバグ票を登録したのちに添付された資料もその対象としています。たとえば、ScreenshotsやStack Tracesなどが含まれていればバグ票のスコアが高くなります。
また、Flesh、Kincaid、Automated Readability Index（ARI）、Coleman-Liau、Fog、Lix、SMOG Gradeなどの指標を利用して可読性の計測も行います。
TERQAF
モバイルアプリケーションなどでクラウドワーカーが登録するバグ票の評価について、そのバグ票を自動的に品質評価するフレームワークです。
以下の記事で提案されています。
A systemic framework for crowdsourced test report quality assessment
https://link.springer.com/article/10.1007/s10664-019-09793-8
バグの分析
信頼度成長曲線
縦軸に累計のバグ件数、横軸に時間またはテストの進捗率をとったグラフを書くことで、現在の状況から今後の予想を立て、進捗管理や残バグ数の予測に利用することです。
この際、使用するモデルの例を以下から抜粋します。
ソフトウェア信頼度成長モデルに基づく最適リリース問題
http://www.kurims.kyoto-u.ac.jp/~kyodo/kokyuroku/contents/pdf/0680-06.pdf
指数形ソフトウェア信頼度成長モデル
指数形ソフトウェア信頼度成長モデルは, 単位時間当りに発見されるエラー数はその時刻において残存する
エラー数に比例するものと仮定して以下のような式を立てます。
a:テスト開始前にソフトウェア内に潜在する総期待エラー数
b:任意のテスト時刻において残存するエラー 1 個当りのエラー発見率
aを30, bを0.8とした場合以下のような曲線となります。
習熟S字形ソフトウェア信頼度成長モデル
テストチームのソフトウェアに対する習熟度を考慮し、最初は進捗がテストの消化が思わしくないとして以下のような式を立てています。
a:テスト開始前にソフトウェア内に潜在する総期待エラー数
b:任意のテスト時刻において残存するエラー 1 個当りのエラー発見率
c:習熟係数
aを30, bを0.8,cを30とした場合以下のような曲線となります。
Excelで信頼度曲線を作成する。
Excelのソルバーアドインを使用してバグの信頼曲線を求める例は以下で紹介されています。
バグの信頼度曲線（成長曲線）書いて、予測しておいて…といわれ、途方にくれたあなたへ
https://blog.goo.ne.jp/xmldtp/e/24a8b55c9ef9271b3a055216c8bc02c0
なお外部のツールを使用していいなら、SRATS2017アドインを利用した方が楽です。
https://swreliab.github.io/SRATS2017/index.html
SRATS2017はアドイン形式で、C#のクリックワンスを使用して実装されています。
日数と、その日数で検出したバグ数から信頼度曲線を描画できます。
いくつかのモデルを選択後、「Predictive Residual Faults」といった予測残バグ数などを算出できます。
バグが偏っている箇所の洗い出し
バグ票に修正箇所が記録されているならば、バグが発生しやすい箇所を見つけることができます。これにより、バグが発生しやすい箇所にたいして、レビューを行う等の品質改善の手段がとれます。
同じような考えとして構成管理システムのコミットログからバグの発生率を予測するものがあります。これは一定時間でバグ対策用のコミットが多い資材は、今後もバグが発生しやすいものとするという考えです。
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
https://www.publickey1.jp/blog/11/post_193.html
根本原因の分析
バグの原因を分類して，根本的な原因を探る活動です。
IPAから以下のような資料がでています。
障害分析手法
https://www.ipa.go.jp/files/000058278.pdf
「なぜなぜ分析」とかはよく使われており、ファシリテーションが下手糞な人がやると部下の心をへし折ります。
ぼくのかんがえたさいきょーのばぐかんり
ここからポエムなので注意しましょう。
どのバグ管理システムを使用するか
Excelを初めてとして専用のバグ管理ツールなど、様々ありますが、どのバグ管理ツールを採用するのが望ましいか考えてみます。
作業者が使えるツールであること
時間もないのに新しいバグ管理システムを使用すると現場が回らなくなるので注意しましょう。逆にいうと教育する期間をちゃんと用意するということです。
期間が短くてメンバーが少数の場合、バグ管理ツールをつかわずにポストイットなどで紙ベースで管理する方法もあります。
複数人がバグ票を同時に閲覧、登録できること。
プロジェクトの規模にもよりますが、同時にバグ票を登録できなかったりすると作業効率が劣ることになります。
編集履歴が残ること
編集履歴はのこるツールの方が望ましいです。
Excelとかをファイル共有でやっていると別の人が間違って消したりすることが稀によくあります。
添付資料とリンクがとれること
スクリーンショットやログなどはバグ解析において重要な情報です。
それらの添付資料を保存し、適切にリンクできる機能が必要です。
検索が行えること
バグ票は後に分析で使用するため，データーベースに蓄えて検索できた方が望ましいです。
バグ票の各項目において、AND検索、OR検索、部分一致などの基本的な検索方法がサポートされていることが望ましいです。
他のバグとの関連付け
他のバグとの関連付けが行えるものが望ましいです。
また、親子関係などを現わせるバグ管理システムの場合、一つのバグを分割して管理することが可能になります。
バグ票の項目がカスタマイズできること
バグ票の項目がプロジェクトごとにカスタマイズできることが望ましいです。
おそらく、プロジェクトごとに必要な入力項目は異なる可能性があります。
項目は自由入力だけでなく選択が行える
表記のブレなどを防ぐため、バグ票の項目がリストやドロップダウンのように選択できるようになると望ましいでしょう。
通知機能
バグ票が変更された場合の通知機能が、そなわっているものが望ましいです。
バグ報告者や担当者、リーダーだけでなく、そのバグによって作業が影響する人間にも通知できる機能があるといいでしょう。
よいバグ票との付き合い方
問題対私達の図式にする
きつい現場だと本来味方であるはずの同僚や管理職に対して不信感や敵愾心を持ってしまうものです。
たとえば「開発担当者はド素人でも埋め込まないようなバグを埋め込みやがって」とか「デスクに座っている偉い連中はなにもわかってねぇ」とか「仕様も理解せずにテストすんなや、カスが」とか言い出します。
これでは人対人の構図になってしまいます。
そうではなくて問題対私達の構図にする必要があります。
そのためには敬意をもったコミュニケーションやプロジェクトファシリテーションのテクニックが必要になります。
必要な情報を書こう
その問題解決に必要な情報を書くようにしましょう。
たとえば、再現手順などはどのプロジェクトでも重要ですし、自身がどう動くべきかという期待する振る舞いも重要です。
またプロジェクトによってはログやスクリーンキャプチャの提供が重要でしょう。
もし、重要な情報にもかかわらず、それらの情報が提供されない場合は、以下の点を見直してみましょう。
- 報告者に教育がなされていて、バグ対応にどのような情報が必要か共有されているか？
- その情報を報告する上での障害がないか？
- たとえばログを添付する必要があるが、ログが分かりにくい場所にあるとか、機械的に取得できないとかの問題はないか
簡潔にしよう
余分な語句や、その事象と関係ないことは書かないようにしましょう。
別の事象は別のバグ票として報告すべきで、なるべくシンプルに記載しましょう。
もしかしたら最初は同じような事象だったが、詳しくみると別の事象が絡んでいるときもあります。
そういうときは別のバグ票として新しくバグ票を作成するべきです。
また可能であれば、文章チェッカーなどの導入を検討してもいいでしょう。
類似事項や影響範囲をしっかり見極めよう
その事象だけ修正して再テストを依頼するってのはやめましょう。
同様なバグが他にないか、あるいは修正によりどのような影響があるかしっかり見極めましょう。
場合によっては別のバグ票を作成する必要もありますし、回帰テストを依頼する必要があるかもしれません。
バグ票は終わらせよう
放置はやめましょう。
時間がなくて修正できない場合も、今回は見送りをするという判断をして、ちゃんとバグ票を終わらせましょう。
また、単一の事象に原因が含まれておりバグ票がなかなか完了しない場合があります。
その場合は、細かくバグ票を分割して終わったものと終わらないものを明確にしときましょう。
バグ登録の前に確認しよう
バグを登録する前に類似のバグがないか検索してから登録しよう。
もしかしたら回避策が書いてあるかもしれないし、次のバージョンでは修正されているかもしれません。
重複したバグを登録すると、バグを裁く人に負担が増加してくるので注意しよう。
関係者に通知する仕組みを考えよう
報告者、担当者、リーダーはもちろんのこと、そのバグによって影響をうける人に通知する仕組みを考えましょう。
たとえば、同じ機能をテストしている人間にも通知するようにしよう。
※これでバグの重複を少しは減らせると思います。
バグの件数にこだわるのはやめよう
バグ分析をやっているとバグの数が気になりますが、件数にこだわるのはやめましょう。
これにこだわると、名目上のバグの件数を減らすためにバグ票を分割するのをしぶったり、ステップ数に対するバグが出てないからといってバグを捏造しだします。
モデルや統計は便利な道具ですが、あくまで道具にすぎず、それによって右往左往するのは本末転倒です。
あくまで重要なのはテスト完了時にバグがどのくらい除去できたかということと、バグが発生した根本的な原因です。そこを軽視して見た目の数値やグラフにこだわるのはやめましょう。
参考文献
プロジェクトを成功に導くための 実践バグ管理
https://www.amazon.co.jp/dp/4883376354
JSTQB Foundation<<第三版>>
https://www.amazon.co.jp/dp/B00G9QIU2E
※第4版でたので古いので注意