欠陥レポートの 作成前に知っておきたいこと 2022年3月 Kumiko Iseri 1

この資料でお伝えすること テスト設計、テスト実装を終えて、いよいよテスト実行 怪しい動作を検出したら、何をしますか？ 2

この資料でお伝えすること テスト設計、テスト実装を終えて、いよいよテスト実行 怪しい動作を検出したら、何をしますか？ 多くの現場では、欠陥を管理しているシステムにレポートを登録します （状況や組織により、口頭での報告を併用するなどバリエーションはあります） そのレポートを使って、修正や優先度の判断などが行われます そんなレポートを書くときに知っておきたいことを、お伝えします 3

● 欠陥を記録するレポート。 「欠陥の発生、特性、およびステータスを報告するドキュメント。」 ○ 「」内の引用元：ISTQB Glossary　欠陥レポート ○ 再現手順、優先度や重要度、ステータス（修正待ち、解決済みなど）が書かれることが多い ● 本書の対象は、動的テストで見つかった欠陥のレポートとする ● 呼び方は組織による ○ バグレポート ○ バグ票 ○ 不具合票 ○ 問題レポート ○ 障害レポート 欠陥レポートとは 4

欠陥レポートとは ● 欠陥レポートに書かれる内容の例 ○ 報告者 ○ 事象 ■ 画面キャプチャやスタックトレースなどが添付されることもある ○ 再現手順 ○ 再現環境 ■ モバイルアプリの場合は、アプリのバージョンも ○ もともと期待していた結果 ○ 再現率 ○ 関連するテストケースの情報 ○ 欠陥レポートのステータス ○ 調査結果 ○ 対応内容 5

欠陥レポートは作成後いつ使われるか？ ● 欠陥の修正中 ○ 欠陥の再現手順や条件を確認するため ● 欠陥を修正後 ○ 再度、テストができるようになったことを知らせるため ○ 修正後のテストが終わり、欠陥が解消されたことを知らせるため ● プロセスの完了判断 ○ 欠陥の出方を分析するため。増減、多く出ている欠陥の傾向など ○ 残存している欠陥を確認し、プロセスの終了や次のプロセスの開始ができるか確認するため ● ふりかえり ○ 欠陥の予防や早期検出ができないか検討するため 6

欠陥レポートの管理 ● BTS(Bug Tracking System)やITS(Issue Tracking System)と呼ばれるシステム を使うことが多い ○ ステータス管理や検索などが容易にできる ○ gitなどと連携するシステムもある 7

欠陥レポートにまつわるトラブルの例 『バグピンポンとは、テストエンジニアと開発者の間で発見したバグに同意がと れず、バグを指摘したメールや指摘票がいったりきたりすることを表し、卓球の ボールがいったりきたりする様で比喩している。』 枠内と『』内の引用元：オルタナティブ・ブログ > 森崎修司の「どうやってはかるの？」 > バグピンポン 8 テ「この使い勝手の悪さは明らかにバグだ」 開「それをバグだと言うなら全部バグになる」 テ「たしかに類似のものはあるがここまでひどいのはない」 ・・・（同様のやりとりが続く）

● 複雑な仕様や事象が関係していることがある ○ テストを行うときには必要なデータや条件が、すべて欠陥に関与しているとは限らない ● 欠陥の話は、プロジェクトのスケジュールを遅らせたり、ステークホルダー の立場を危うくさせるものとしてネガティブに捉えられることがある ○ 『バグの報告が、設計者や実装者に対する⾮難と捉えられる』 ○ 『プロジェクトの進⾏の邪魔と捉えられる』 ○ 『バグレポートが争いの場になったり、役に⽴たないと⾔われ続けると、他に誰も気づいて いない⼩さな違和感や、重⼤だが確証が得られない問題をフィードバックしにくくなる』 『』内の引用元：WACATE2020冬　良いテストは良いフィードバック　75ページ 難しさ 9

ではどうするか？ 次のページから、以下について詳細を述べる ● 事実を伝える ○ 欠陥についての事実に焦点をあてる ○ ⽬的を⾒失わない ○ 問題点は明確に、でも丁寧に伝える ● 必要な情報を分かりやすく伝える ○ 簡潔で認識齟齬が起こりにくい文章にする ○ 一件一葉 ○ 過不足なく書く ● 役割が異なる複数の人が欠陥レポートに関与することを意識する 10

事実を伝える ● 欠陥についての事実に焦点をあてる ○ できるだけ推測は書かない、書く場合は事実と分ける ■ ただし、事象再現の確認をするときは事実に基づいた仮定を使うと効果的なことがある ● ⽬的を⾒失わない ○ ステークホルダーに対して思うところを書くドキュメントではない ■ 欠陥レポートが不要な対立やモチベーション低下を招いては、元も子もない ■ ステークホルダーに価値を届けるために、早く適切に欠陥に対応してもらうことが大事 ○ 『「バグ対我々」という構図をイメージする』 ■ 『』内の引⽤元：プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？　 ● 問題点は明確に、でも丁寧に伝える ○ 読むのも人間 ○ 『はっきりと問題を指摘しながらも、相手への配慮を込めた丁寧な表現を用いる。』 ■ 『』内の引⽤元：JaSSTʻ20 Kyushu　サーバントリーダーシップを⾝に付けましょう︕　34ページ 11

必要な情報を分かりやすく伝える ● 簡潔で認識齟齬が起こりにくい文章にする ○ 欠陥レポートは、レポートの一種であり、コミュニケーションツールの一種 ○ できるだけ、長文を避ける ■ 画面キャプチャや動画も活用する ● 赤枠やマウスの動作で、見て欲しいポイントを示すと更に分かりやすい ○ できるだけ、定量的に書く ■ 例　再現したのは5回中2回だった 12

● 簡潔で認識齟齬が起こりにくい文章にする ○ 人によって捉え方が違う言葉に注意 ■ 例　“やばい” ● 『危険や不都合な状況が予測されるさま。あぶない。』 ● 『[補説]若者の間では、「最高である」「すごくいい」の意にも使われ る。』 ○ 上記2つの『』内の引用元：コトバンク　デジタル大辞泉「やばい」の解説 ■ 例　“やばい”の認識齟齬 ● 『アイコンがほんの少しズレている(仕様通りでない)』 ● 『担当した機能が仕様書通りに動作していない？』 ● 『リリースを再検討するレベルの重大バグ？』 ○ 上記3つの『』内の引用元：ソフトウェアテストシンポジウム(JaSST) 2017 東海　バグ票カウン セリング　～ バグ票の悩み、話してみよう！解決しよう！ ～　51ページ 必要な情報を分かりやすく伝える 13

必要な情報を分かりやすく伝える ● 一件一葉 ○ 1件の欠陥レポートには、1つの欠陥についてのみ書く ○ 1つの欠陥レポートに複数件の欠陥A、B、Cが書かれていると… ■ どこからどこまでが修正範囲や修正後の確認テスト範囲なのか、分かりにくい ■ A、Bが完了しても、Cは将来対応とになると、レポートのステータスで表現できない ● レポートをクローズできない ■ 欠陥の数や重要度・優先度をリリース判断等に用いる際、 正確な件数が把握しにくく、集計が不正確になる恐れがある ○ 但し、欠陥の原因が特定されるまでは、どこまで1件とするか難しい場合がある ■ 周囲に相談する ■ 後から複数件に分けたり1件に統合したりすることもある 14

必要な情報を分かりやすく伝える ● 過不足なく書く ○ 特に再現手順 ■ 例　新規登録画面を開き、氏名欄を入力する。氏名欄の下にある電話番号欄を未入力に して保存ボタンを押しても、必須入力のエラーメッセージが出ない ● 電話番号欄が氏名欄の下にある記述は要らないのでは？ ■ 例　ポップアップ右上の×ボタンを押す ● Escキーでは？　ポップアップの外をクリックした場合は？ ● 調査に時間がかかる場合は、先に欠陥レポートを起票した方がよいこともある ○ 手順以外の条件や特徴も忘れずに。 ■ モバイルアプリでは特定のOSバージョンのみ起こる問題もある ■ 再現性はあるか？ ○ フォーマットに従うことである程度は過不足なく書けることもある 15

必要な情報を分かりやすく伝える オープンソース製品の開発者とバグ報告者の調査結果より 「では、良いバグレポートとはどのようなものでしょうか？（略）開発者たちか ら得られた反応から、スタックトレース、バグの再現手順、期待された振る舞 い、観察された振る舞いが、バグ解決時に重要であることが分かりました。報告 者たちはバグの解決を手助けするものに役立つものとして同様の項目群をあげま したが、ただし興味深いことに、報告者たちはそれらの情報を提供しないことが よくある、という結果も得ました。つまり、開発者が期待する情報と、報告者が 提供するものとの間には、ミスマッチがあるのです。」 「」内の引用元（太字は本書作成者による）：Making Software ―エビデンスが変えるソフトウェア開発、Andy Oram (編集), Greg Wilson (編集), 久野 禎子 (翻訳), 久野 靖 (翻訳)、オライリージャパン、2011年　424ページ 16

必要な情報を分かりやすく伝える ● 過不足なく書く（続き） ○ 特に修正の要否や時期の判断が分かれそうな欠陥の場合で、 もしエンドユーザやステークホルダーへの影響が想定できるならば、あわせて書いておく ■ なぜ欠陥と判断したのか、分かるように書く ■ 誰に、どんなことが、起こるか？　遭遇するユーザーは多そうか？（発生頻度） ■ 起こりうる最悪のことを書く 17

必要な情報を分かりやすく伝える 架空の欠陥レポートの一部 太字部分を、どのように理解すればよいか？ 事象詳細の内容の引用元、太字は本書作成者による：WACATE2020冬　良いテストは良いフィードバック　68ページ 18 事象詳細 データ削除の権限を持たないユーザーでログインして、 管理画⾯を表⽰させると[データ全削除] ボタンが表⽰される

必要な情報を分かりやすく伝える 影響の度合いや範囲、優先度が不明確 ● [データ全削除] ボタンをクリックするとデータが全削除される データ不整合の恐れあり、急いで対応 ● [データ全削除] ボタンをクリックしても、データ削除は起こらない ○ 「権限がありません」とメッセージが表⽰される ○ ボタンに⾒えるが、クリックしても何も起こらない 紛らわしいが、他に緊急性の高い問題があるならば優先度は下がる 箇条書き部分の引用元：WACATE2020冬　良いテストは良いフィードバック　68ページ 19

役割が異なる複数の人が欠陥レポートに関与することを意識する ワーク フロー 例→ 図とその下の文章の引用元：WACATE 2014冬　バグ票をもっとうまく使うために　7ページ 20

役割が異なる複数の人が欠陥レポートに関与することを意識する ● 人により目的が異なる ○ テスト担当者　…欠陥を修正してもらいたい ○ プロダクトオーナーやマネージャ（判断する人）　…欠陥の検出傾向や重要度・優先度を知 りたい ○ 修正担当者　…欠陥を修正したい ○ 再テスト担当者　…欠陥修正後の確認テストを行いたい ○ など ● 人により前提知識が異なる ○ テスト担当者が実施中のテスト内容の詳細を知らないかもしれない 自分と異なる目的や前提知識を持つ人が欠陥レポートを読む可能性を意識する 必要な情報を届けるためにはどこまで書けばよいか、検討する 欠陥レポートに自分が使わない項目があっても、他の人が使うことがあるので注意 21

欠陥レポートを書くときに注意したいこと 次のページから、以下について詳細を述べる ● 重大なバグや複雑なバグほど、鮮度が重要 ● 起票前に、欠陥かどうか検討する ● 起票前に、再現する条件や環境をできる限り特定する ● 重複したレポートがある場合は、 起票しない、あるいは、追記やリンクを検討する 22

欠陥レポートを書くときに注意したいこと ● 重大なバグや複雑なバグほど、鮮度が重要 ○ 記憶が新しいうちに、前提条件と手順を書く ○ 多数のテストケースをブロックする欠陥の場合はスケジュール遅延や他のチーム への影響が発生することがあるので、早めに知りたい ○ レポートの話ではないが、重大なバグが見つかりそうなテストを先に行う場合も ある ● 起票前に、欠陥かどうか検討する ○ 間違えた環境を使っていた ○ テストケースの期待結果がおかしい ○ 欠陥と改善提案を別で管理している場合もある 23

● 起票前に、再現する条件や環境をできる限り特定する ○ どのような条件や環境ならば再現するか、しないか、仮説を立てる ■ 例　アカウントの種類に関係しているのではないか？ ■ 例　ブラウザの種類に関係しているのではないか？ ○ 仮説に沿って、様々な条件や環境で再現手順を実行してみる ■ 例　異なるデータでも再現するか？ ● 別の入力値でも再現するか？ ● 別のデータ状態の場合に再現するか？ ● 別のアカウントでも再現するか？ ■ 例　OSやブラウザを変えても再現するか？ ■ 例　キャッシュを消しても再現するか？ ■ 例　PCアプリやモバイルアプリなら別のバージョンでも再現するか？ 欠陥レポートを書くときに注意したいこと 24

欠陥レポートを書くときに注意したいこと ● 重複したレポートがある場合は、 起票しない、あるいは、追記やリンクを検討する ○ 起票前に、過去のレポートを検索して類似の問題が起きていないか確認する ■ 同じプログラム修正に対して複数人でテストしている場合、テストケースに レポートの概要を記載するなどして、お互いに分かるようにしておく ○ 修正後に再発した場合や、環境やプログラムが変わった後で再度検出された場合 は、報告は必要であるので、過去のレポートへの追記やリンクを検討する ○ 情報をたどれることが大事 25

欠陥レポートをうまくつくるための工夫 ● チーム内でレビューをする ● 声に出して読んでみる ● 自分が読む立場だったらどう思うか考える ● 他の人のレポートで分かりやすいと思った書き方は真似をする ○ 文章の書き方 ○ どのような情報を書いているか、書く順序はどうか ● 欠陥レポートのフォーマットを工夫する ○ チームの合意を得てから 26

おわりに 欠陥（と思われるもの）を見つけただけでは、価値に繋がらない 修正されるか、修正の要否や時期が判断されるかして、 やっと顧客に価値を届けることに繋がる 欠陥レポートを上手に書いて、よりよいものづくりに繋げましょう 27

引用文献、参考文献（1/2） いずれも、最終閲覧は本書執筆時点である ● ISTQB Glossary　欠陥レポート ○ https://glossary.istqb.org/jp/search/%E6%AC%A0%E9%99%A5%E3%83%AC%E3%83% 9D%E3%83%BC%E3%83%88 ● 連載 : 究極のバグレポート ○ プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？ ■ https://thinkit.co.jp/story/2012/07/11/3614 ■ https://thinkit.co.jp/story/2012/07/11/3614?page=0%2C2 ○ 「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは ■ https://thinkit.co.jp/story/2012/07/18/3619?page=0%2C1 ● オルタナティブ・ブログ > 森崎修司の「どうやってはかるの？」 > バグピンポン ○ https://blogs.itmedia.co.jp/morisaki/2010/08/post-2cf3.html ● WACATE2020冬　良いテストは良いフィードバック ○ https://speakerdeck.com/omn/wacate2020w 28

引用文献、参考文献（2/2） いずれも、最終閲覧は本書執筆時点である ● Making Software ―エビデンスが変えるソフトウェア開発、Andy Oram (編集), Greg Wilson (編 集), 久野 禎子 (翻訳), 久野 靖 (翻訳)、オライリージャパン、2011年 ● JaSSTʻ20 Kyushu　サーバントリーダーシップを⾝に付けましょう︕ ○ http://www.jasst.jp/symposium/jasst20kyushu/pdf/S3.pdf ● コトバンク　デジタル大辞泉「やばい」の解説 ○ https://kotobank.jp/word/%E3%82%84%E3%81%B0%E3%81%84-400880 ● ソフトウェアテストシンポジウム(JaSST) 2017 東海　バグ票カウンセリング　～ バグ票の悩み、 話してみよう！解決しよう！ ～ ○ http://www.jasst.jp/symposium/jasst17tokai/pdf/S5-3.pdf ● WACATE 2014冬　バグ票をもっとうまく使うために ○ https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxzd3dvc nN0cHJhY3RpY2VzaXRlfGd4OjE5N2MwZmI2MDU5YTUwODY 29