Great work!

XP to next level

BugEater
EN

Environment and Attachments: Localising the Bug

You've written perfect steps. You've described the actual and expected results precisely. And the developer still responds: "Cannot reproduce." This happens — and it usually means the environment section was missing or the attachments were insufficient.

A bug is not just a behavior. It's a behavior in a specific context. The Environment section and attachments are how you capture that context.

Learning Objectives

By the end of this lesson you will be able to:

  • Identify the standard fields that belong in an Environment section
  • Choose the right type of attachment for different bug scenarios
  • Annotate screenshots effectively to direct attention to the defect

The Environment Section

The environment answers: "Under what exact conditions did you observe this?"

Standard Fields

Field Why It Matters
Operating System & Version Browser rendering, font handling, touch events behave differently across OSes
Browser & Version Chrome 120 and Safari 17 handle the same CSS and JavaScript differently
Application Version / Build The bug may be present in build 2.4.1 and fixed in 2.4.2
Device Desktop, tablet, mobile — screen size affects responsive layouts
Test Environment Dev / Staging / UAT / Production — each has different data and configs
Test Data Which user account, which order, which specific record triggered the bug

A Complete Environment Example

OS: macOS 14.2 (Sonoma)
Browser: Google Chrome 120.0.6099.109 (64-bit)
Application: v2.4.1 (build 20240115)
Environment: Staging (staging.example.com)
User Account: test_user_42@example.com

Without this information, "Cannot Reproduce" is a legitimate response. With it, the developer can replicate your exact conditions.

Attachments: The Evidence That Closes Debates

Screenshots

Screenshots are the minimum standard for most UI bugs. But a bare screenshot of an error message — with no context about what the page looked like before — is often less useful than it seems.

Effective screenshot practices:

  • Capture the full browser window (not just the error message) to show page context
  • Capture the console if there are JavaScript errors (DevTools → Console tab)
  • Capture the Network tab if a request is failing (status code, response body)

Annotations

A raw screenshot with no markup forces the reviewer to find the issue themselves. A well-annotated screenshot directs their attention instantly.

Effective annotation:

  • Use a red rectangle or arrow to point to the specific element with the defect
  • Keep annotations minimal and precise — mark the bug, not the entire screen
  • Add a short text label if the defect isn't visually obvious ("Expected: error message here")

Avoid:

  • Drawing over the entire screen with a large red circle
  • Using confusing arrows that point to multiple areas
  • Not annotating at all and hoping the reviewer figures it out

Screen Recordings

For bugs that involve a sequence of interactions — a button that briefly flashes before disappearing, a form that partially submits, a race condition in real time — a screen recording is far more valuable than a screenshot.

Best practices:

  • Start recording from a clean state, before step 1
  • Record at a pace that allows the viewer to follow the steps
  • Include the full browser window, not just the application area
  • Keep recordings short — aim for under 2 minutes

Log Files

For backend errors, database issues, or intermittent failures, logs are essential. Attach:

  • Browser console logs (copy the text, or screenshot the console)
  • Application error logs (if you have access)
  • Network request details (request headers, response body, status code)

When attaching log files, note the timestamp of the relevant entry so the reviewer doesn't have to search through a 10,000-line file.

When "Cannot Reproduce" Meets a Strong Attachment Package

A bug report with:

  1. Complete environment details
  2. An annotated screenshot of the visible error
  3. A 45-second screen recording showing the full reproduction
  4. The browser console log with the error highlighted

...is almost impossible to dismiss as "Cannot Reproduce." The reviewer can see, step by step, exactly what happened and in what context.

Pro Tips

Tools for screen recording: macOS has built-in screen recording (Cmd+Shift+5). Windows has Snipping Tool and Xbox Game Bar. Browser extensions like Loom or Screencastify work on any platform.

Annotate, don't decorate. The purpose of an annotation is to direct attention, not to make the screenshot look dramatic. A single clean rectangle beats a chaos of overlapping arrows.

Summary

  • The Environment section captures OS, browser, application version, device, test environment, and test data.
  • Without environment details, "Cannot Reproduce" is a legitimate developer response.
  • Screenshots should show context (full window, DevTools console/network) and be annotated with precise markers.
  • Screen recordings are the best attachment for sequential or intermittent bugs.
  • Log files close the loop on backend and infrastructure-related failures.

Quiz

Why is the Environment section of a bug report important?

Which type of attachment is MOST helpful when a bug involves a multi-step interaction or sequence?

When annotating a screenshot to highlight a defect, the best practice is to: