バグレポートの技術: 開発者が数秒で理解できるバグレポートの書き方

1. バグレポートはQAの名刺です

2. 完璧なバグレポートテンプレート

• タイトル

  [Mod] 問題を簡単に説明します

• 重大度

  P0/P1/P2/P3

• 環境

  OS/ブラウザ/アプリバージョン/テスト環境

• 前提条件

  再現するにはどのような状態が必要ですか?

• 再現手順

  1-2-3 のステップは明確で再現可能です

• 予想される結果と実際の結果

  起こるべきことと実際に起こったこと

• 付録

  スクリーンショット/ビデオ/ログ

• 述べる

  発生頻度、関連チケットなど

3. 重症度評価スケール

• P0 ブロッカー

  システムの利用不能、データ損失、セキュリティ侵害。例: ログイン機能が完全に無効になり、間違った金額が支払いから差し引かれます。

• P1-クリティカル

  メイン機能の異常、回避策なし。例: 間違った検索結果、コアプロセスを完了できない

• P2-メジャー

  この機能にはバグがありますが、回避策はあります。例: エクスポート機能は失敗しましたが、データは他の方法で取得できます

• P3 - マイナー

  機能に影響を及ぼさない軽微な問題。例: テキストのタイプミス、配置の微調整、コア以外のページ スタイル

4. 良いバグレポートと悪いバグレポート

5. バグレポートのためのコミュニケーションスキル

• 客観的な説明

  「誰が何か間違ったことをしたのか」ではなく「何が起こったのか」を説明する

• コンテキストを提供する

  このバグは何人のユーザーに影響を及ぼしますか?回避策はありますか?

• アクティブトラッキング

  修復後は、問題が解決されたことを事前に確認してください。

• バグと機能を特定する

  バグなのか仕様なのかわからないですか？まず質問して後で報告する

6. バグ追跡ツールの推奨事項

• ジラ

  業界標準、強力だが習得に時間がかかる

• リニア

  最新のインターフェイス、高速、中小規模のチームに適しています

• GitHubの問題

  コードベースと統合し、オープンソースプロジェクトに適しています

• バグジラ

  安定性と信頼性の高い老舗ツール

• 概念

  柔軟なデータベース、小規模チームがすぐに始めるのに適しています

7. QAと開発の関係