Modules
Beginner⏱ 7 min read

Bug Report Writing Best Practices

sign in to track

A bug report is a communication document used to clearly describe a software defect. Its main purpose is to help developers and other team members understand, reproduce, investigate, and fix the issue efficiently.

A good bug report should be clear, specific, reproducible, and evidence-based. It should describe what actually happened without assumptions or unnecessary information.

Essential Elements of a Bug Report

  1. Bug ID

    • A unique identifier for tracking the issue.

    • Example: BUG-1024

  2. Bug Title

    • Clearly summarize the problem in one sentence.

    • Avoid vague titles such as “Login is broken.”

    • Better: “Login button remains disabled after entering valid credentials.”

  3. Environment
    Include relevant environment information such as:

    • Application/build version

    • Browser and version

    • Operating system

    • Device

    • Test environment

    • Relevant configuration

  4. Preconditions
    Describe anything that must be true before reproducing the issue.

    Example:

    • User has a registered account.

    • User is logged out.

    • Product is available in stock.

  5. Steps to Reproduce
    Provide clear, numbered steps that another person can follow.

    Example:

    1. Open the login page.

    2. Enter a valid email address.

    3. Enter a valid password.

    4. Click Login.

  6. Test Data
    Include the relevant input data when necessary.

    Example:

    • Email: test@example.com

    • Product: Product A

    • Quantity: 2

    Never include real passwords, payment credentials, or other sensitive information.

  7. Expected Result
    Clearly describe what should happen according to the requirement or expected behavior.

  8. Actual Result
    Clearly describe what actually happened during testing.

  9. Severity & Priority
    Indicate the impact and urgency of the defect when your team's process requires them.

  10. Evidence
    Add supporting evidence when useful:

  • Screenshots

  • Screen recordings

  • Logs

  • API request/response

  • Console errors

  • Network information

  • Relevant test data

Example Bug Report

Title: Login button remains disabled after entering valid credentials

Environment:
Chrome 154, macOS, QA Environment

Precondition:
A valid registered user account exists.

Steps to Reproduce:

  1. Open the login page.

  2. Enter a valid email address.

  3. Enter a valid password.

  4. Observe the Login button.

Expected Result:
The Login button should become enabled and allow the user to submit the login form.

Actual Result:
The Login button remains disabled after valid credentials are entered.

Severity: High
Priority: High

Evidence:
Screenshot/screen recording attached.

Best Practices

  • Be specific: Describe exactly what happened.

  • Be reproducible: Provide enough information for another person to reproduce the issue.

  • Use numbered steps: Keep reproduction steps easy to follow.

  • Separate expected and actual results: Never combine them into one statement.

  • Use factual language: Report what you observed rather than assuming the technical cause.

  • Avoid blame: Focus on the behavior, not the person or team responsible.

  • Include evidence: Attach useful screenshots, videos, logs, or API details.

  • Mention frequency: If relevant, state whether the issue occurs always, sometimes, or under specific conditions.

  • Mention dependencies: Include required accounts, configurations, data, or environment conditions.

  • Avoid duplicates: Search existing defects before creating a new report.

  • Keep the title searchable: Include the affected feature and actual problem.

  • Protect sensitive information: Never include real passwords, tokens, payment details, or unnecessary personal data.

Common Mistakes

Avoid reports such as:

“Checkout is not working.”

This does not tell the developer what failed or how to reproduce it.

Instead, describe the exact behavior:

“Checkout displays a blank page after clicking ‘Continue to Payment’ when the cart contains a discounted product.”

The second report gives the developer a clear starting point for investigation.

◈Key Points

  • Title: specific and action-oriented. Not 'Login broken' but 'Login fails with valid credentials when email contains a + character'.
  • Steps to reproduce: numbered, minimal, and complete — anyone should be able to follow them.
  • Expected vs Actual: clearly stated, not 'it doesn't work' but observable, specific descriptions.
  • Environment: OS, browser, version, device, test data used — without this, reproduction is guesswork.
  • Evidence: always attach screenshots, screen recordings, network logs, or console errors.
⚡ Expert Pro Tip

Before submitting a bug, reproduce it at least twice. If you can't reproduce it reliably, investigate further before filing — intermittent reports are the least trusted in any bug tracker.