この記事の想定読者
テストに関連する仕事をしているけど、
バグを報告するプロセスを脳内で整理できていない...
と悩む人
この記事のゴール
・バグを発見~バグの修正までのプロセスを把握する
・バグを開発者に伝える時の情報の選択肢を知る
前提
ここでの単語の定義をします。
故障 = システムの実際の挙動が期待する挙動と異なる
欠陥あるいはバグ = 故障の根本原因。
欠陥レポート = 故障の情報をまとめた資料
JSTQB = Japan Software Testing Qualifications Board
日本のテスト技術者認定資格を発行している組織。
組織のサイト：https://jstqb.jp/
プロセス
テストで故障が発見されてから修正されるまでのプロセスは以下の遷移図にあります。
このプロセスをJSTQBでは欠陥ライフサイクルと呼びます。
状態ごとに担当者がアサインされます。各担当者はアクションを行います。
その後、次の担当者に割り当てます。
こうして各人が状態遷移を進め、欠陥ライフサイクルが回転していきます。
いくつか補足説明をします。
解決or延期
故障を修正するか、修正せずにリリースするかの判断をすること
(リリースまでの残り時間が少ない場合などに重要となる)
再現不能?情報不足？
欠陥を修正する際には、一般的に故障を再現します。
その再現ができない時、再現のための情報不足の時に
修正を拒否します。追加情報を要求することもありえます。
修正を確認
開発者が修正した後、テスト担当者は障害が再現されないことを確認します。
ここで直っていなければ修正待ちの状態に戻すこともあるでしょう。
解決済み
この状態に遷移すれば、それ以降はレポートを追いかける必要がなくなります。
欠陥レポートの書き方
欠陥レポートの例
引用元：https://knowledge.sakura.ad.jp/26627/
欠陥レポートのゴール
- 欠陥ライフサイクルを回すため
- プロジェクトの進捗を把握するため
- プロセスが効率的かを評価するため
- プロダクト/システムの品質を把握するため
- テストの終了基準を満たしているか確認するため
これらのゴールのために含める要素
| ゴール | 情報 |
|---|---|
| 1. 欠陥ライフサイクルを回すため | 欠陥発見者 |
| 問題の概要 | |
| 問題の詳細 | |
| 故障の再現手順 | |
| 実際の結果 | |
| 期待の結果 | |
| スクリーンショット | |
| 故障を解決する優先度 | |
| テスト環境 | |
| 欠陥レポートの現在のステータス | |
| 欠陥レポートの現在の担当者 | |
| 問題を解決するためのアクションの実行・不実行の提案と決定内容と承認 | |
| 欠陥ライフサイクルの遷移の発生日、過去の所有者、アクション | |
| 何を修正したかに関する情報、推奨されるテスト方法 |
| ゴール | 情報 |
|---|---|
| 2. プロジェクトの進捗を把握するため | テストケース |
| ゴール | 情報 |
|---|---|
| 3. プロセスが効率的かを評価するため | 欠陥を発見したテストタイプ |
| 欠陥が存在するサブシステムorコンポーネント | |
| 問題を発見した方法 |
| ゴール | 情報 |
|---|---|
| 4. プロダクト/システムの品質を把握するため | システムのステークホルダへのインパクトの大きさ |
| プロジェクトステークホルダーの利害へのインパクト | |
| ビジネスへのインパクト | |
| 欠陥の種類 |
欠陥レポートの情報にとって重要な性質
- 完全(不足がない)
- 簡潔
- 正確
- 客観的
- 適切
(必要な情報を選択していることだと解釈しています) - タイムリー
参考資料
JSTQB テストマネージャ(ALTM) シラバス
https://jstqb.jp/syllabus.html#syllabus_advanced_altm