DebuggingIntermediate4-6 min reference
Logs for QA
Logs turn "it crashed" into "it threw a NullPointerException in OrderService at 14:32 with order id 8821." Knowing how to read and search them makes your bug reports irrefutable and your triage fast. This sheet is the practical guide; for the wider picture see Monitoring & Observability, and for CLI grepping see Linux & CLI for Testers (linked below).
Log levels
| Level | Means | QA interest |
|---|---|---|
ERROR | Something failed | Start here on a bug |
WARN | Recoverable / suspicious | Often the early signal |
INFO | Normal events | Trace the flow |
DEBUG / TRACE | Verbose detail | Deep dives only |
FATAL | Process-ending | Crashes/outages |
What to search for
- The correlation/request/trace id — follow one request across services.
- A timestamp window around your repro (note the timezone — prefer UTC).
- Exception class + stack trace (top frame = where it blew up).
- The error message text and any ids (order, user, session).
- Status transitions: request received → processing → response/error.
Pulling evidence
- Grep the local log (
grep -i error app.log) or query the aggregator (Kibana/Splunk/Loki/CloudWatch). - Filter by service + level + time window, then by correlation id.
- Capture the surrounding lines, not just the error line — context matters.
- Attach the snippet (sanitised) to the bug with the timestamp + trace id.
Common mistakes
- Reporting a failure with no log evidence or timestamp.
- Ignoring
WARNs that preceded theERROR. - Timezone confusion when matching logs to the repro time.
- Pasting logs containing tokens/PII — sanitise first.
- Quoting the error line without the stack trace or correlation id.
// Related resources