つぶやく【ACADEMY】何が良いバグレポートを作るのか？
 |
バグレポートは品質保証の通貨だ。バグレポートは，我々の労働の成果物であり，我々の存在を証明するものであると言えるだろう。一般的に，バグレポートはテスターとデベロッパの間で情報を伝達する唯一の手段である。
このような理由から，バグを正しく修正することは非常に重要だ。悪いバグレポートは資産というよりもむしろ邪魔であり，あらゆる種類の混乱を引き起こす可能性がある。
- デベロッパの方向性を誤らせ，時間を無駄にする
- デベロッパをイライラさせ，品質保証に対する信頼を損なう
- ビルドの全体的な状態について，誤った印象を与えてしまう
- 完成日を決定するために設計されたモデリングツールを混乱させる
- バグを修正しなければならない残りのQAチームを妨げる
バグレポートを書くことは芸術（人文科学）ではなく，自然科学だ。何が良いバグレポートを作るのかというと，答えるのは簡単な質問のように思えるかもしれないが，デベロッパの視点からアプローチした場合の答えは，たいてい次のようなものになる。「良いレポートとは，我々が発見していなかったもので，修正が簡単なものだ」
テスターには異なる視点がある。我々は，報告書に記載されているバグではなく，報告書に含まれているデータそのものの品質を評価する。これが今議論している「良いバグレポート」のタイプだ。
 |
瞬間的な理解力
理想的なのは，デベロッパがバグレポートを開いてナノ秒でスキャンし，それが記述している問題をすぐに正確に理解することだ。
デベロッパが眉をひそめながらバグレポートを何度も読まなければならないなら，それは失敗だ。追加情報を要求するために QA に戻さなければならない場合は大惨事になる。
統一性は匿名性を育む
通常，各バグレポートの中にはバグを提出したテスターの名前を表示するデータフィールドがある。これがテスターを識別する唯一の方法であるべきだ。
バグは共通の標準に従った統一されたスタイルで書かなければならない。
もしデベロッパがバグレポートが書かれたスタイルでテスターを特定できたら， そのテスターが何か間違ったことをしているか，他のテスターが全員そうなのかのどちらかだろう!
プログラミング言語は厳格な書式規則に従っている。そうでなければ，コードは動作しない。バグレポートはそれほど柔軟性に欠けるものではないが，言語の個性や芸術的なセンスを表現する場ではない。我々は，関連する情報を可能な限り簡潔に伝える必要がある。
バグレポートを読む人は誰でも，組織の中での役割に関係なく，簡単に内容を理解できるようにする必要がある。ほとんどの場合，QA が提出していないバグのサブセットを目にしたときには，イライラするだろう。それらは制作側ではトリアージできず，品質保証側では翻訳，再配置，巻き戻し，クローズできないものだ。なぜなら，それらは暗号化された2行のメッセージに相当するもので，書いた人だけが理解できるように書かれているからだ。このようなメモにも意味はあるのかもしれないが， ここはバグデータベースではない。
バグレポートは，個性や芸術的な言語のセンスを表現する場所ではない
闇の中の象
盲目の3人組が触覚だけでゾウの姿を想像しようとした例え話はよく知られているかもしれない。それぞれの人が動物の異なる部分を感じている。彼らの説明は，彼らのユニークな経験によって制限されており，自分自身以外の人にはほとんど意味がない。これは，とくにテスター以外の人（エンドユーザ，デベロッパ，職場経験者など）が書いた場合によく見られる欠陥だ。
バグを見つけることはQAの仕事の50％だ。残りの半分はコミュニケーションだ。バグをデベロッパに適切に伝えることができなければ，解決策の助けとなるどころか，新たな問題を生み出してしまうだろう。
バグレポートには，新聞の見出しのように，レクリエーションのステップとは別の簡潔で説明的な要約が必要だ：「これは象である」
説明文には，余計なデータを含まずにバグを強制的に顕在化させるために必要なすべての手順を記載する必要がある。
1枚の写真は稚拙な1000のバグ説明より価値がある
バグの顕在化が目に見えるものであれば，スクリーンショットや動画，あるいはその両方が必要だ。グラフ，チャート，音声ファイル，結果一覧などで表現できるものは何でも同じだ。
バグを再現しているときには，バグを直視しているので，不具合が目立ってしまうことが多く，目に見えているからこそ，動画でのキャプチャをスキップしたいという誘惑に駆られてしまうだろう？
デベロッパが自分でソフトウェアを起動してバグを再現する必要はない
間違いだ。デベロッパが自分でソフトウェアを起動してバグを再現する必要はない。このような行為を要求するきっかけとなるのは，多くの場合，バグ報告に添付される適切なイメージが不足していることに起因している。誰かが何かを説明しようとしたとき，あなたの反応が理解できないような顔をしたとき，次の反応はほとんどいつものことだ。「見せてくれ」という反応になる。これはバグ報告ほど真実味を帯びていない。添付ファイルをアップロードしよう!
バグはソフトウェアの傷だ
「軽度」の傷を負ったからといって優先度が低いとは限らないし，「重大な」傷であっても緊急性が高くないこともある。
病院ではこのようにして患者を評価しているが，我々も同じ方法でバグをトリアージする必要がある。この方法で，テスターが提出したすべての情報に基づいて，それぞれの新しいバグに優先度を割り当てることができる。
重大度はバグの技術的な分類だ。優先度は常に変化するビジネス上の決定だ。
 |
重大度はテスターによって割り当てられた値であり，最良の方法は英数字のスケールを使用することだ……。解釈の自由度が高すぎる説明的な形容詞の使用は避けてほしい。一連の値を考え出して定義してほしい。たとえば，すべてのクラッシュは "クラスA "であり，すべてのタイプミスは "クラスC "であるかもしれない。重要なのは，一度範囲を決めたら値を変えないということだ。
優先度とは，バグに対処することがビジネスにとってどれだけ緊急性があるかに応じてデベロッパが割り当てる値だ。テスターは，そのバグがあなたにとってどれだけ重要なのかを知らないので，優先度の評価を選ぶことができない。テスターの役割は，すべての新しいバグのデフォルトの担当者が迅速にトリアージし，優先順位を割り当て，最も適切なデベロッパにバグを割り当てることができるように，十分な情報を含めることだ。
適切なバグ管理ソフトウェアを使用する
メールはメールのためのもの。DMはイチャイチャするためのもの。Twitter は窓から大声で叫ぶためのものだ。これらはどれもバグ報告には適切なツールではない。
バグのトレーサビリティと所有権は，バグのライフサイクルの中で最も重要な側面の1つと言っても過言ではない。優れたバグ管理ソフトウェアには事欠かないものがあり，安価なものや無料のものが多い。あなたの既存のソフトウェアツールの1つをバグ報告のために適応させるために利用可能なプラグインがあることを見つけるかもしれない。
バグのトレーサビリティと所有権は，バグのライフサイクルの中で最も重要な側面の1つだ
あなたの職業はソフトウェアを作ることだ。これは，その仕事を可能な限り最善の方法で行うために必要なツールだ。専用のバグデータベースを避けて成功したソフトウェアのリリースは存在するが，そのうちの1000件は失敗したか，あるいは容易に回避可能な苦闘を経て，成功への道中で多くの不必要な追加作業に費やしてしまったものだ。「しかし，それは管理したりログインしたりしなければならない別のものです」という議論は，データベースを利用しないことのデメリットによって，すぐに無効化されてしまうだろう。
バグキャノンの準備をして，発射の準備をしよう!
最悪のバグレポートは，一度も書かれなかったものだ。これはバグが発見されなかったために起こることもあるが，その原因は，テストケースの書き方が悪かったり，テストが不十分だったり，十分なテストができていなかったり，標準以下のテスターやトレーニングを受けていないテスター（デベロッパはこのカテゴリに真っ向から入る！）が原因であることもある。
このシナリオよりも悪いのは，実際に知られていたバグが報告されなかった場合だ。
テスターが言うには，「ああ，これはデベロッパがすでに取り組んでいると言っていたので，私は書いていなかった」これは受け入れられない……。 関係なくバグを修正してほしい。トレーサビリティが最も重要だ。
テスターが言うには「すでにバグ報告されていると思っていました」彼らは，バグを報告しないように呼びかける前に，バグデータベースを検索して疑念を確認すべきだった。
テスターが言うには，「バグなのか設計上のものなのか分かりませんでした」というものがある。いいだろうが，とにかくバグを報告してほしい。バグが報告されないことによるビジネス上のリスクは，デベロッパがバグをトリアージして「設計通り」に放棄するという些細な不便さを引き起こすリスクに比べて， まったくもって勝る。
疑わしい場合は，バグを報告してほしい!
バグレポートで「私は思う」という言葉を読むと，私は身震いする。誰もあなたが何を考えているかなんて気にしない
事実に基づいたものであること
曖昧さはバグ証券取引所では価値のない商品であり，買うべきではない: バグはもっぱら事実に基づいた記述で構成されなければならない。
私はバグ報告のレクリエーションのステップで「私は思う」という言葉を読むと戦慄する。誰もあなたが何を考えているかなんて気にしていない。知っているか，知らないかのどちらかだ。それは測定可能で証明可能なものなのか。
妥当性とは，測定と繰り返しを使って実証可能なものであることを意味する。
「それは数秒の間だけ起こる」または「私はそれを短時間見た」または「それはときどき現れます」のような表現は受け入れられない。それを測定してほしい。何秒？「ほんの少しだけ 」の定義 それがどのくらいの頻度で現れるかのパーセンテージを記録してほしい。
テスターの認識はバグ報告につながるものだが，逆説的にバグレポートには何の役にも立たない。事実，数字，統計，データ。曖昧な抽象的なものは何も要素にしてはいけない。
なぜ欠陥と判断されたのかを明示しないような欠陥を特定するような記述も禁止されなければならない。「このアセットは色が違う」「解像度が違う」「メニューが動かない」などは，単独では価値がなく，反論の余地がある。設計要件を引用するか，ソフトウェアの他の場所にある同一の機能との矛盾する比較を強調する必要がある。
6歳のときに数学を教えてくれた先生の言葉を引用しよう: 「あなたのやったことを見せなさい!」
GamesINdustry.biz ACADEMY関連翻訳記事一覧
※本記事はGamesIndustry.bizとのライセンス契約のもとで翻訳されています（元記事はこちら）
