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