Learning Objectives
By the end of this lesson you will be able to:
- Identify the most critical pieces of log evidence to include in a bug report
- Write a reproducible bug report when you have log evidence but no manual reproduction steps
- Select the log fields that help a developer reproduce the exact failure scenario
- Make a log-based bug report actionable for the development team
When You Only Have Logs
Most QA bugs are discovered during manual or automated testing, where you have exact steps to reproduce. But a significant category of bugs is discovered through log analysis — from log alerts, production monitoring, or periodic log reviews. In these cases you may have:
- A log excerpt showing an ERROR
- A timestamp and possibly a correlation ID
- No direct steps to reproduce because the bug occurred in production, triggered by a real user
Writing a useful bug report in this situation requires a different approach from the standard "Steps to Reproduce" format.
The Most Important Piece of Log Evidence
The single most valuable item to extract from a log and include in a bug report is the log excerpt surrounding the error — typically 5–10 lines before and after the ERROR line. This context shows:
- What was happening immediately before the failure (the request type, the input value)
- The exact exception class and message
- Any WARN entries that may indicate a degraded state leading up to the failure
A bare exception message without context ("DateTimeParseException") is much less useful than a 10-line excerpt that shows the date value that triggered it and the service that was calling the parser.
What Replaces "Steps to Reproduce"
When you have no manual steps, the "Steps to Reproduce" section is replaced by:
"Reproduced via: Production log — not manually confirmed"
followed by the log evidence itself:
Reproduced via: Production log — 2024-11-14 14:32:11 UTC — not manually confirmed
Log excerpt (app.log, line 4847–4856):
2024-11-14T14:32:10.001Z INFO [req-abc123] POST /api/bookings — body: {"start_date":"31-13-2024"}
2024-11-14T14:32:10.012Z DEBUG [req-abc123] BookingService.create() called
2024-11-14T14:32:10.039Z ERROR [req-abc123] DateTimeParseException: Text '31-13-2024' could not be parsed
2024-11-14T14:32:10.041Z ERROR [req-abc123] Unhandled exception — returning HTTP 500
This tells the developer exactly what input triggered the failure and which component failed, without you having to know who the user was or how to reproduce their exact session.
The Log Fields That Enable Reproduction
Different log fields serve different purposes for the developer trying to reproduce the bug:
| Field | Why it helps reproduction |
|---|---|
| Correlation ID | Lets the developer pull the full request from the log system, including the complete request body |
| Timestamp | Lets the developer find adjacent log entries and check what else was happening at that moment |
| Exception message | Reveals the exact input value that triggered the failure |
| Logger class | Tells the developer which code file to look at |
| Environment | Confirms whether the bug exists only in production or also in staging |
Always include all five in a log-based bug report.
Making the Report Actionable
A log-based bug report is actionable when a developer can:
- Find the full request — by using the correlation ID in the log system
- Identify the input that caused the failure — from the log excerpt
- Know which component failed — from the logger class name
- Attempt reproduction — by replaying the same input in staging
To ensure these four outcomes, structure your bug report like this:
Title: POST /api/bookings — 500 on date "31-13-2024" — DateTimeParseException
Severity: High
Discovered in: Production logs — 2024-11-14 14:32:11 UTC
Correlation ID: req-abc123
Environment: Production
Log Excerpt:
[paste 5–10 lines here]
Likely Input:
start_date = "31-13-2024" (day.month.year format — European locale)
Expected Behavior:
API should return 400 Bad Request with a date format validation message.
Actual Behavior:
HTTP 500 Internal Server Error — unhandled DateTimeParseException.
Reproduction (manual):
Not confirmed. Developer can use correlation ID req-abc123 to retrieve the full request from the log system and attempt to replay it in staging.
Suggested Fix Area:
BookingService.create() — date parsing — add format validation before parsing.
Summary
A log-based bug report is not weaker than a manually reproduced one — it is a different artifact. Its strength is in the evidence it provides: real inputs from real production traffic, not synthetic test data. When written correctly — with a log excerpt, correlation ID, timestamp, and a clear description of expected versus actual behavior — a log-based report gives developers everything they need to trace, reproduce, and fix the bug.