5 exercises on presenting evidence clearly — error messages, stack traces, screenshots, redacting secrets, and linking logs to the failure.
Key patterns
Paste logs as text in a code block — searchable beats a screenshot of text.
Redact secrets and PII; mark them <REDACTED>, keep the signal.
Screenshots for visual bugs — annotate and caption them.
Quote the relevant lines inline; attach the full log for reference.
Narrate: tie the log to a timestamp, error, location, and trigger.
0 / 5 completed
1 / 5
You want to include an error in your report. Which is the most useful way to present it?
Logs are evidence — paste them as text, in a code block, and point to what matters. Option B preserves the exact message and stack trace, keeps it copy-pasteable and searchable, and guides the reader to the relevant frames and time.
Use fenced/<pre> code blocks so formatting and indentation survive.
Highlight the top stack frames — that is usually where the fault is.
Keep timestamps so the log can be correlated with server-side records.
A phone photo of a screen (Option C) is not searchable and is hard to read; "the usual one" (D) and "something about null" (A) make the reader guess. Pasted text beats a screenshot for anything textual.
2 / 5
A log line contains: Authorization: Bearer eyJhbGciOi...<token> and a user email. What should you do before attaching it?
Redact secrets and personal data, but keep the diagnostic signal. Option B removes the bearer token and PII while preserving the error and request path so the bug is still reproducible.
Always redact: tokens, API keys, passwords, session cookies, full PII.
Use an obvious placeholder like <REDACTED> so readers know data was removed, not lost.
Posting raw secrets (A) is a security incident — anyone with repo access could reuse the token. Deleting the whole log (C) throws away the evidence. Emailing a live token (D) just leaks it through another channel. Redaction is the professional middle path.
3 / 5
When is a screenshot the right evidence, and how should you present it?
Screenshots are for what you can see; text is for what you can copy. Option C uses a screenshot where it genuinely helps — a layout, rendering, or visual-state bug — and makes it scannable with an annotation and a caption.
Annotate: draw an arrow or box around the affected region.
Add a caption so the reader knows what to notice.
For console errors and logs, paste text (searchable), not a screenshot of text (Option D is the anti-pattern).
"Always" (A) and "never" (B) are both wrong: choose the medium that matches the evidence. A short screen recording is the equivalent for interaction or timing bugs.
4 / 5
Your report references a 600-line log. How do you present it clearly?
Show the signal inline; attach the full log for completeness. Option B quotes the handful of lines that matter (plus a few lines of context) and links the rest, so the reader sees the cause immediately but can still dig deeper.
Trim to the relevant window — error + a few lines before/after.
Keep the full log attached or linked; never destroy primary evidence.
Add a note like "full log attached; key lines below".
Dumping 600 lines inline (A) buries the point; paraphrasing with no real lines (C) loses the exact wording engineers search for; "see logs" (D) makes the reader do your triage. Quote-plus-attach is the standard pattern.
5 / 5
Which sentence best connects your evidence to the failure for the reader?
Narrate the evidence: tie the log to a specific time, error, location, and trigger. Option C does the interpretive work for the reader — it names the timestamp (14:32:07 UTC), the exception (NullPointerException), the precise location (OrderService.total() line 88), and the preceding action (after the discount is applied).
Point to the exact line/frame rather than "the logs".
State the correlation you noticed ("immediately after …") — it often is the root cause.
Good framing verbs: the log shows / indicates / confirms.
Options A, B, and D hand over raw evidence without interpretation, forcing the developer to rediscover what you already found. Evidence plus a clear pointer is what makes a report fast to fix.