IVEC テスタークラス シラバス読解 Part8

はじめに

今回は不具合報告に関するシラバス読解を進めていく。

不具合報告

不具合報告書の作成手順

学習の目的

不具合報告書作成の手順を理解する

① 事象の発見：期待値と異なる振る舞いを判定する
期待動作と異なる振る舞いを特定する。
② 障害の特定：事象が不具合かどうかを判定する
テスト仕様書の誤り、オペレーションミスがないこと、既に報告済の不具合ではないことを確認しテ
スト実行管理者に報告する
③ 発生条件の特定：不具合の発生条件の特定する
不具合事象が発生する環境、設定、データなどの条件を特定する。
④ 再現の手順化：不具合の再現手順を明確化する
他のテスト実行担当者や開発担当者など、第三者が再現できるよう手順を明確化する。なお、不具合
を再現するための最短手順を特定するため、再現手順として不要なテスト手順は排除する。
⑤ 不具合の評価：重要度、優先度や影響度などの不具合を評価する
ブロックバグや、テスト対象に大きなダメージを与えるなどの影響度を考慮し、不具合の重要度や優
先度を評価する
⑥ 不具合報告書の作成：不具合報告書を作成する
①から⑤の情報を基に不具合報告書を作成する。客観的で適切な用語や文章表現を行い、第三者へ的
確に伝わる内容であることを意識して作成する。

不具合を見つけた際は、不具合報告書に記載するための情報を集め、集めた内容を基に不具合報告書を作成する。
不具合報告書の内容について、事象の要約、詳細、再現手順、再現率、発生環境、不具合のエビデンス、不具合の評価（重要度等のランク設定）等が記載すべき情報であり、後はプロジェクトによって必要な事項を追加していく。

不具合報告書の作成

不具合報告書のフォーマットはプロジェクトによって違いがあるが、概要またはサマリーとよばれる
不具合件名、不具合の再現手順、不具合内容の詳細など、開発者へ伝える必要がある基本的な情報は
どのプロジェクトでも共通である。開発者が不具合の内容を容易に理解できるよう、端的で正確な用
語や表現を用いて報告する。不具合件名を見て第三者が容易に不具合の概要を理解できるか、テスト
手順は正確に記載しているか、期待結果との違いが明確であるかなど、客観的な観点で作成する。
① 不具合報告書１件に複数の不具合を記入しない
開発者が複数の不具合が記載されていることに気づかず、不具合の修正漏れが発生する可能性があ
る。
② 重複した不具合を報告しない
既に自分以外の誰かがその不具合を報告済の可能性がある。不具合報告書の重複発行は、作業の煩雑
化や遅れにつながるため、不具合報告書を作成する前に既に同一の不具合が報告されていないかを確
認する。
③ 不具合報告書の不具合件名の書き方に注意する
不具合件名は、報告者以外が重複した不具合を探しやすいように、キーワードを含んだ件名とするこ
と。機能、条件、振る舞いなどをキーワードとして盛り込むとよい。
④ 不具合報告書を作成する際は不具合の原因を特定しない
不具合原因は開発者が特定する作業である。テスト実行担当者が憶測で原因を記載することで、開発
者の誤った判断につながる可能性がある。不具合の発生条件、再現手順などの事実に基づく内容を報
告する。
⑤ 各不具合報告書の項目と記入の仕方を理解する
不具合報告書には、不具合番号、重要度、優先度、発生条件、再現手順、期待動作および付帯情報を
記入する。プロジェクトによって報告時のルールが異なるため、プロジェクトのルールに従って報告
する。自分だけでは判断できない部分は、テスト実行管理者に確認のうえで作成する。期待値や前提
条件、テスト手順は単にテストケースに記載されているものを転記するだけでは不足している場合が
ある。テスト仕様書にはない条件や手順がある場合は、もれなく記載する必要がある。
⑥ テストエビデンスの添付に関する注意事項を理解する
不具合の内容を詳細に記載しても、文章表現だけでは開発者に正確な内容が伝わりづらいことがあ
る。その際はスクリーンショット、再現手順の動画、ログなどを添付する。それにより開発者が容易
に正確な情報を把握することができる。

不具合報告書を作成する前に予めフォーマットの合意を得る必要がある。
テスト開始前にステークホルダーに不具合報告用のフォーマットがないか確認し、それがなければテストチーム側で用意したフォーマットか運用してよいかの合意を得ることがスタートになる。

不具合報告書の作成ポイントについて、シラバスであれこれ書いてあるが集約すると、誰が見ても理解できるような内容を心がけることがポイントかもしれない。
仮にそれが出来ているかが不安であれば、テスト実行管理者のチェックを挟むなど、誰かの協力を得ることで良質な成果物を作り上げていく仕組みづくりが大切である。

また、不具合報告書の記載で開発チームへ協力を仰ぐこともある。
例えば、不具合要因の特定や影響範囲の特定、改修内容については、開発側でしか記載できない内容である。
実運用に入る前に、関係者を集めて不具合報告作成の記載ルールの周知を行うことで、テスト期間中に間違ったルールで運用されないよう事前に手を回しておくとよい。

不具合報告書の管理

学習の目的

不具合対応への動機付け

開発者による不具合の修正が遅れると、テスト実行にも遅れが生じる。特にスケジュールに影響があ
るテストブロックとなる不具合は早急に修正してもらう必要がある。テストの影響度、緊急度、利用
者への影響などを説明し、早急に対応してもらえるような動機付けを行う。

シラバスにある通り、不具合修正が遅れることでテスト実行に悪影響を及ぼす場合、早急な対応を取ってもらえるよう、テストチームが主体となり動いていく必要が出てくる。
その際、不具合報告書や不具合管理表の優先度やステータス変更だけ行うと気づかない人も想定されるため、ステークホルダー全体が認識できるよう、各種コミュニケーションツールや会議体での報告もセットで共有する。

プロジェクト固有の不具合報告書の管理ルールを確認する

不具合報告書のフォーマットやツールはプロジェクトによって異なり、プロジェクト固有のルールに
あわせた管理を行う。不具合報告書の記載内容、不具合の報告手順、修正時の連絡手順など、プロジ
ェクト固有のルールについて、テスト実行管理者とテスト実行担当者は共通の認識を持っておく必要
がある。

テストチーム内で不具合報告書の管理ルールについて、テスト実行開始前に認識合わせを行うこと。
特にプロジェクト特有の不具合報告書に関する記載ルールがある場合、ルールの把握を目的としたデモ運用をテスト開始前に行い、認識相違がないことをチェックするのも有効な手立てと考えている。

不具合報告書作成時の注意事項を理解する

不具合報告時には、重複チェック、曖昧な記述の排除、不具合件名の妥当性などの基本的な注意事項
がある。
・不具合件名は端的でわかりやすく記載されていること
・再現条件は特定されていること
・再現手順は正確に記載されていること
・重要度、優先度は適切に選択されていること
テスト実行管理者は、不具合報告書を作成する際の注意事項について、チーム内で認識合わせをする。
経験の浅いテスト実行担当者がいる場合は、経験のあるテスト実行担当者がサポート、またはテスト
実行管理者が事前にチェックする仕組みを検討する。

不具合報告はステークホルダーが注目する重要なテスト成果物であるため、誤字脱字は勿論、誰が見ても理解できる内容が記載されているかという点に重きをおくこと。
シラバスにもあるように、不具合報告書の作成は基本的にテスト実行者であるが、ノーチェックで提出したことで後からミスを指摘されないよう、テスト実行管理者のチェックを挟むべきである。

不具合報告書のステータス状況を管理する

報告した不具合は解決するまで状況をトレースする必要がある。優先度、重要度、検出した時期など、
テスト実行への影響度を考慮し不具合報告書のステータス状況を管理する。
①不具合報告書のステータス状況から進捗状況を（発行状況、修正状況、修正確認状況）確認する
②不具合が修正対応されるリリース情報（修正内容、リリースバージョン、リリース日）を確認する
③テスト実行に影響を与える優先度を管理する
④不具合の傾向分析をするためのステータス分類を管理する
テスト実行の序盤に見つけた不具合は時間的な余裕があるため、優先度・重要度ともに低めにつける
場合がある。ただし、それがテストブロックだとわかった場合、終盤になっても修正されない場合、
もしくは対応されない不具合については優先度・重要度を変更する。なお変更を行う場合は、テスト
実行担当者は独断で判断せず、テスト実行管理者の指示を仰いで変更する。

不具合一覧をステータス管理し、不具合が解消されたらクローズするのがよくある流れである。
テスト実行に影響のある不具合の場合、ステータスを変更も重要だが、具体的にテストケース何件分の影響があるかを数値で可視化すると、早期対応が必要だと直感的に理解できる内容になる。

おわりに

次回はテスト実行報告について、シラバス読解の続きを進めていきます。