もちろん、欠陥はバグ追跡システムに保存され、その制限と要件を課します。もちろん、エラーレポートを作成するための内部ルールがいくつかありますが、それでもすべての設計ルールを満たすバグがあります。仲間のテスターにとってもまったく理解できない。 説明が不十分なバグは、「解像度を再現できません」を取得し、誤って顧客に表示されるまで忘れられる可能性があります。
この記事では、大規模なプロジェクトの作業中に遭遇したエラー報告の主な問題と、それらを改善する方法について説明します。
1.非常に一般的なヘッダーのバグ
このようなバグの例 ：アカウントを作成できません。
システムは完全に機能していないようです。 問題のより詳細な調査で何が起こるか：
- このようなアカウントは既に存在します（または、アカウント名に無効な文字が入力されました）。問題は、エラーメッセージが表示されないことです（特定のバージョンのブラウザでのみ可能）。
- アカウントは作成されましたが、確認がメールで受信されていません。
- その他のオプション。
ちなみに、再生手順のこれらすべての詳細（ブラウザのバージョン、ローカライズ）は示されていない場合があります。
2.非常に詳細な事前手順、非常に短い説明。
例 ：壁に釘を打ちました。 それから彼はボルト、ナット、板金で働きました。 問題：宇宙船は飛行しません。
欠陥は叙事詩として記述され始めます：朝に取られるすべてのアクション、および最大の詳細。 いくつかの段落の後、これはわずらわしく、非常に簡単に追加されます。 はい、問題の説明があります、それは非常に大きいですが、それを修正するプログラマーとテストされるテスターの両方にとって完全に役に立ちません。
3.エラーが発生するたびに、個別のバグレポートを作成します
はい、これが実際に同じ問題であることは明らかではありません。 しかし、場合によっては、同じ欠陥の異なる症状が異なる開発者に降りかかって混乱が始まります。
4.多数の添付ファイルとリンク
このようなバグには通常、ヘッダーのみがあります。 再生手順はテストケースへのリンクです（ちなみに、おそらくプログラマーはそのようなリソースへのアクセス権を持っていません）、期待される結果は50ページのドキュメントのリンク（または添付ファイル）です。 解説には、再生手順が欠陥番号NNNで詳細に説明されているという注記がある場合があります。 補足として-ログ。 すべて。 2週間すべてのテスト。 すべて50メガバイト。 まあ、各ステップのスクリーンショットはボーナスです。
5.エラーの正確な内容は示されていません。
はい、起こります。 まれに（これはリストの最初ではありません）、しかし起こります
例：
タイトル：ページのJavascriptエラー。 次はこのページ自体にアクセスする手順ですが、エラーメッセージ自体はどこにも示されておらず、スクリーンショットすらありません。
6.特定の略語および略語の使用
システムの特定の部分に固有のエンティティの略称は、プロジェクトに長い間取り組んでいる人々にとってさえ明確でない場合があります。 また、本文に多数の略語があると理解しにくくなります。 このような欠陥の分析にかかる時間は、エラーレポートの作成時に節約された時間を大幅に上回ります。 一般的な略語と頭字語を使用できますが、乱用しないでください。
7.すべてについて、何についても
57DeDからのコメント：最も一般的な（少なくとも私が扱ったもの）悲嘆バグレポートはリストに入れませんでした：「プログラムの読み込みが遅く、アイコンの色が正しくありません。テキストの入力時にエラーが発生し、メニュー項目から-すなわち-動作しません。 天気も悪く、雨が降っています。」 （どうやら、開発者はNot Reproducedを書く必要があります-雨はすでに終わっています）
これらの推奨事項は、バグの説明の品質を改善できるように思えます。
1バグ追跡システムの必須フィールドを正しく構成し、大きなファイルの添付を禁止します（これがエラービデオの再生でない場合）
2.コードレビューとの類推によって：同僚に、新しく生成されたエラーレポートを見るように依頼することがあります。 おそらく、彼らはバグの説明から追加および/または除外するものを教えてくれるでしょう。
3.新しいレポートを作成する前にバグベースを確認します。おそらく、このような「獣」はすでに記録されています。
4.至る所で中間的な基盤が必要です。 重要な手順を逃すことなく、明らかなことを噛まないで書く
5.そして、黄金律を忘れないでください-エラー報告を書いて、それらを読んで楽しんでください