バグ追跡データベース -虫の生態を究める

バグ追跡データベース
-虫の生態を究める- (前編)
goyoki
@「基本から学ぶテストプロセス管理」読書会#2
目次
•
•
•
•
はじめに
バグ追跡システムの概要
バグ追跡システムの設計
バグ管理の運用
はじめに
はじめに:
テスト技術者の仕事
• テスト設計を行い、テスト計画を作成
• 後はそれを実行する
• 事前準備が肝
• だけではない
はじめに:
テスト技術者の仕事
• テストの実施で、膨大なバグ管理情報が出力
される。そのコントロールが必要
– バグ情報の管理
– 根本原因を分析し、開発工程・プロセスにフィード
バック
• 怠るとバグはテスト工程をすり抜け、チーム
は同じ間違いを繰り返す
バグ追跡システムの概要
概要:
バグ追跡システムとは
• バグを管理するもの
– 障害レポートによる情報共有
– 管理支援
– 分析支援
• バグのライフサイクルを管理
概要:
バグ追跡システムのメリット
• バグの情報共有がスムーズになる
• 管理を自動化でき、分析や情報共有が効率化さ
れる
• 複数の視点・客観的な視点を導入できる
• バグのライフサイクル全体を管理でき、責任者
間のハンドオフのミスなどを防止する
• 部外者でも最新のバグ情報を知ることができる
• テスト技術者の成果/開発者のための戒めの明
示手段にできる
バグ追跡システムの設計
設計:
バグ追跡システムに求められるもの
• テキストとしての報告機能
• 分析の容易性
• 簡易データベース機能
• Rex Blackは例としてMicrosoft Accessで構築
設計:
バグ追跡システムで留意すべきこと
• 処理の自動化を進めること
– メールによる情報共有の自動化
– 分析の支援・自動化
– チェックの効率化
• 自由入力形式は利便性に劣る
自動化や分析処理と親和性が低いため
設計:
障害レポート
• バグ報告を行うためのもの
• とても重要
– 最も分かりやすいテストの成果
– 品質向上を促す強い理由づけとなる
• Rex Black 「長年この業界にいるために、これ
まで重大な問題を含む何百という障害レポー
トを読んできた。」
設計:障害レポート:
基本構成
• 要約
1、2文でまとめる
• 再現手順
バグの再現方法。再現頻度の情報も書く。これ
はテストケースを何回も動かして明らかにする
• 分離
バグ出現に関係する因子を限定するための情
報。テスト手段・環境などを書く。
設計:障害レポート:
作る上で守るべきこと
• 正確・完全・簡潔
誤り・欠落・曖昧さ・冗長さは担当者の引き継ぎを阻害する
後々テスト技術者の手を煩わせることになる
• 適切なタイミング
バグ情報はスケジュールに大きな影響を与える
「一定量蓄積して一度に報告する」スタイルはスケジュー
ルを阻害する
• レビューのプロセスを取り入れること
何事にも反復は重要。マネージャ等にレビューしてもらい
ブラッシュアップした障害レポートを実現すること
設計:障害レポート:
障害レポートの質≒テストの質
• その場しのぎのテスト、いい加減なテスト
→皮相的で適当な障害レポートに
• きちんと手順を守り、探索的テストの技法を
活用し、細かく記録し、自分の責務を考慮し
たテスト
→簡潔で分かりやすく、フィードバックも大き
い障害レポートに
設計:障害レポート:
作成プロセス10カ条
•
•
•
•
•
•
•
•
•
•
体系化
再現
分離
一般化
比較
要約
凝縮
明確化
中立化
レビュー
• ガイドライン兼チェックリストとして用いる
設計:
バグ追跡データベース
• バグ情報を管理するもの
– バグ情報
– バグのライフサイクル情報
– 対応している担当者
– 分析情報
– Etc..
設計:バグ追跡データベース:
バグのライフサイクル管理
• バグのライフサイクルのステップ
– レビュー
– 却下
– オープン
– 割り当て
– テスト
– 再オープン
– クローズ
– 据え置き
設計:バグ追跡データベース:
ライフサイクルの管理
• どのステップにいるのか明示すること
– バグがどの段階にいるのか明記
– 責任者を明確にするために必要
• ハンドオフをミスなく円滑に
– 履歴を残す
– 担当者を明記
• うまく管理すると、分業と役割の専業化を促進で
き、デバッグ作業が効率化される
設計:バグ追跡データベース:
バグの重要度管理
• 重要なバグは尐数。重要でない多数からそ
れを分離・強調するためにレベル分けを行う
• ここでは「重要度」と「優先度」を使用する
– ただし1つの値で扱えるようにする
– 例)RPN(優先度指数):重要度と優先度を乗算
設計:バグ追跡データベース:
バグの重要度管理
• 重要度
–
–
–
–
FMEAの尺度を使う。5段階
システムに対するバグの影響度の大きさ。
大:ハードウェアの損傷
小:機能が部分的に使えない
• 優先度
– FMEAの尺度を使う。5段階
– 「重要度」で補足できない要素をここで補う
– システムの価値、クライアントの不都合度など
設計:バグ追跡データベース:
カテゴリでの分類
• 管理の効率化のため、バグをカテゴリ分けする
– カテゴリ例)サブシステム:CPU、マザーボード、メモリ..
• 留意すべきこと
– 例外を許容すること(「その他」「不明」「N/A」)
– 分業状態を反映させること(サブシステム単位で担当
者を分けている場合は、サブシステムでのカテゴリ分
けをすべき)
バグ管理の運用
運用:
プロジェクトレベルでのバグ管理
• プロジェクトレベルで判定するバグがある。
(不明確、修正に多大なコスト、確認に手間がか
かる…)
• マネジメント・仕様策定レベルで対処する
– バグ判定委員会(バグレビュー委員会)
マネージャ級、上級技術者などが参加しバグをレ
ビュー。対処方針を決定する
– 変更管理会議
上級管理職や営業、マーケも参加。製品仕様の検討
を行う
運用:
プロジェクトレベルでのバグ管理
• 運営上の注意
– レビューの掟に従う(レビュー対象は事前に読み
込ませる、観点を絞る...)
– 形骸化させないこと
– 効率的に進めること
– アナリシスパラリシスに陥らないこと
• 失敗するとコストばかりかかる非効率なもの
となる
運用:
根本的原因分析
• 単純に「バグの症状登録→症状の対処」を繰り返す
↑これは「咳が出たので咳止め」「熱が出たので解熱
剤」の対処をする一方で、風邪の根本原因であるウイ
ルス退治を全く行っていないのと同じ
• バグ追跡を行う上では以下の視点が必要
– 症状の原因(欠陥、発生工程等)を洗い出す
– 集積しているデータを分析し、バグを埋め込んだ根本的
原因・発生背景を見つけ出す
– その対策を特定工程や開発方法にフィードバックする
運用:
根本的原因分析
• 実施のコツ
– バグ追跡データベースを分析に適した形にする(自
由入力形式禁止など)
– システムとしてバグを分析し・体系化するようにする
• 留意すべきこと
– 開発者や管理者の協力がいる
– エラーと欠陥と障害(症状と根本的原因)はペアの関
係にない。相互作用的な障害もある
運用:
小さなバグの扱い
• 一見簡単でも複雑な背景を持つバグがある
• 発見時にテスト担当者とプログラマがその場
で治してしまうような対処は避けるべき
• どんなに簡単そうに見えるバグでもきちんとし
た手順を踏んで確実につぶす
(以上本文に対する訳注)
運用:
責務を意識する
• プロジェクトチームの視点でバグの重要度評
価を行う
– チームがより重要なことに焦点をあてるために
– チームがよりリスクの高い箇所に集中するために
– マネジメントレベルで分析・比較するのに足る指
標を得るために
運用:
責務を意識する
• 相手に対する役割を意識する
• 例)テスト技術者から開発者へのハンドオフ
– テスト技術者:
•
•
•
•
原因を分析する
テストにバグがないか確認する
どういうテストをパスすればよいか明確にする
環境の違いを明示する