良いバグレポートを書く方法: 推奨事項

あなたが開発者で、テスターが回帰テスト中に見つかったバグを持ち込んできたと想像してください。このバグを修正したいので、チケットの作成を依頼します。あなたはすでに、そのバグをどのようにピックアップし、プル リクエストをリンクし、製品マネージャーに質問が出ないように見積もりを追加するかを想像しています。

しばらく時間が経ち、新しいチケットが届きましたが、中には数行とスクリーンショットしかありません。ため息をつきながら、この情報を使ってバグを再現しようとしましたが、エラーは出ません。何度か試しましたが、結局、バグを再現できないことをテスターに伝え、新たな説明のラウンドが始まります。

新しいタスクに取り組んだり、他のバグを修正したり、アニメを見たり、コードをリファクタリングしたりするために使用できたはずの時間を費やしています。

私の名前はEvgeny Domninです。私はQAです。良いバグレポートとは何かという私の見解をお伝えしたいと思います。前置きが長くて申し訳ありませんが、早速始めましょう。

タイトル

チケットのタイトルにある 3 つの質問に答えてみてください。

1. それはどこで起こりますか?
2. 何が起こるのですか？
3. どのような状況ですか?

経験豊富な開発者であれば、タイトルをざっと見るだけで問題が理解できます。例:

ログインページ: 間違ったパスワードを入力するとフィールドがハイライト表示されません

環境

テスターが、問題が発生した環境をチケットに明記し忘れるのをよく目にします。これは、Web サイトのアドレスやネットワーク リクエストが表示されない UI 関連のチケットでは特に重要です。必ず明記してください。チケットに別のフィールドがある場合は、そこに記入してください。ない場合は、再現手順でそのことを記載します。例:

管理者アカウントでステージング環境にログインします。

ステップといえば...

再生手順

最も重要なセクションの 1 つは、バグの再現手順です。ここでは、手順のフォーマット (ビジュアル) とコンテンツ (内部のデータ) の 2 つの部分に焦点を当てます。

ビジュアル部分

構造を維持する

バグレポートにはさまざまなバリエーションがありますが、一般的には次のセクションが含まれます。

1. 手順
2. 期待される結果
3. 実際の結果

この構造を使用し、常にそれに従ってください。これは、問題を説明するときに統一性が考えを整理するのに役立つケースの 1 つです。

番号付きリストを使用する

番号付きリストを使用して手順を分割します。テスターが詳細な説明を、連続したテキスト ブロックとして記述することがあります。これは行わないでください。手順を分割すると、誰にとっても読みやすくなります。

可能な限り、文法的な誤りのない書き方をしてください。

それでは、これらの手順の内容に移りましょう。

説明における常識

バグを再現するために重要でない場合は、すべてのアクションを個別のステップに分割する必要はありません。これは、読みにくく、実際に使用しにくいためです。1 つのステップに複数のアクションを含めることを恐れないでください。どういう意味でしょうか?

悪い：

1. test.com/loginにアクセスしてください

2. ログインフィールドをクリックします

3. ログインを入力してください

4. パスワードフィールドをクリックします

5. パスワードを入力してください

   
   

良い：

1. test.com/loginにアクセスし、任意のアカウントでログインします。

開発者が標準的なフローに従いながら自然に行うようなステップに細分化しているわけではありません。私が始めた頃は、すべてのアクションに独自のステップが必要だと考えていましたが、それは必要ありません。

曖昧さを避ける

各ステップで確認する具体的な要求を常にステップに追加し、押す具体的なボタンを記述します (特に同じ名前のボタンがある場合)。

テストデータを含める

エラーがアカウントに関連している場合はログイン データを提供し、バグの再現に役立つテスト ペイロードを躊躇せずに含めてください。

もう一度手順を確認してください

バグが発生した直後に手順を記述しても、完全に理解するために必要な手順が抜けていたり、後でバグを再現できなかったりすることもあります。その場合は、より正確な手順を見つける必要があるかもしれません。

期待される結果

期待される結果に関する別のセクションがあり、ここでは (当然ですが) 手順を実行したときに期待される結果について説明します。このセクションは必ず存在する必要があるということ以外に、特別な推奨事項はあまりありません。開発者は、機能がどのような動作につながるかを理解する必要があります。「すべて正常に動作するはずです」などのフレーズでは不十分です。具体的な動作を記述してください。

実際の結果

ここでは、手順を実行したときに実際に何が起こったかを書きます。ここでも、具体性は重要です。「すべてが壊れた」とだけ書かないでください (おそらく実際に起こったことですが)。すべてが壊れたことを示す指標を説明します。例:

GET /accountsリクエストで 500 エラーが返され、UI がブロックされます。ユーザーはページを終了したり、要素をクリックしたりできません。

ページを更新するとリクエストが再度トリガーされ、同じエラーが発生します。

つまり、実際の効果とそれがユーザーのフローにどのような影響を与えるかを説明します。

追加ファイル

これは言及する価値のある別のセクションです。バグを説明する追加情報を添付する場所です。再現手順を読むのが好きではなく、実際の結果とそれを説明する追加資料に直接進む開発者もいます。

エラーのスクリーンショット

100 回聞くよりも、一度見たほうが良いでしょう。これは、何がどこで起こっているかを視覚的に示す優れた方法です。必ずスクリーンショットを添付してください。

リクエスト

エラーが発生したリクエストがある場合は、必ずチケットに含める必要があります。ただし、リクエストにはさまざまなパラメータが含まれます。含める必要がある重要なパラメータとして、次の点を強調します。

• エラー URL – テストが行われているブラウザのネットワーク セクションから取得できるリクエスト自体。

• メソッド– GET 、 POST 、 TRACE 、 OPTIONなど。同じ URL でもメソッドが異なるリクエストがあるように、メソッドも多数あります。チケットで指定することを忘れないでください。

• エラー コード– もう一つの重要なポイントです。おそらく忘れることはないでしょうが、サーバーから返されたコードを忘れずにメモしておいてください。

• ペイロード– これは、サーバーへのリクエストで送信したデータです。これはすべてのリクエストに存在するわけではありません (たとえば、HEAD または GET には存在しません) が、エラーの原因である可能性があります。

• レスポンス– サーバーのレスポンス。エラー全体、発生した場所も含まれる場合もありますが、その種類のエラー用にバックエンドで設定されたデフォルトのプレースホルダーのみの場合もあります。必ずこれを含めてください。開発者の時間を大幅に節約できます。

コンソールログ

コンソールにエラーが見つかることもありますが、そのエラーはチケットに追加できます。すでに実行しているかもしれませんが、大きなテキスト ブロックはいつでも.logファイルとして保存し、チケットに追加できることをここで述べておきます。これにより、ログとチケット自体の両方の読みやすさが向上します。

それはそれでいいのですが...

これはすべて結構ですが、すべてをこのように見栄えよくする時間はどこで見つけるのでしょうか? 締め切りが迫っている、マネージャーは怒っている、制作に障害がある、そして私は座ってすべてを書き出すように言われている? 開発者に直接メッセージを送るだけです。それだけです。

これは、起こり得る論理的な議論です。私は、テストに十分な時間が割り当てられ、すべてがプロセスに従って進み、徹底した高品質のドキュメントが維持される、テスターの完璧な世界について幻想を抱いていません。理解しています。多くの場合、それは時間に追われ、目が疲れ、すべてを時間内に終わらせるための競争です。

小さなエラーは積み重なり、コンテキストの切り替えに時間がかかり、悪い習慣につながる傾向があります。徐々に改善を実施し、その効果を監視していくと、すべての参加者にとってより安定し、標準化され、予測可能なプロセスを作成できるようになります。

プロジェクト マネージャーは、全員を呼び出して最新情報を入手しなくても製品で何が起こっているかを把握でき、開発者はテスターに再現条件の説明を求めたり、テスターをテストから引き離したりする必要がなくなり、関係者は製品の進捗状況を明確に把握できるようになります。

この記事は、テストを始めたばかりの初心者や、すでにテストを始めている初心者を対象としています。小さなステップが大きな結果につながると信じており、この記事の推奨事項に従うことで、より質の高いバグレポートが作成されます。

ご質問、ご提案、ご意見、ご不満などございましたら、お気軽にコメント欄にご記入ください。皆様のご意見をお待ちしています。