Fehlerbelege aufnehmen

Bug Intake & Evidence Analysis

When to Use

Use at the start of any bug reproduction, triage, or investigation task when translating user reports, support tickets, screenshots, stack traces, or logs into a structured reproduction plan.

Strict Separation of Epistemic Tiers

Never blur what was reported with what you observed or inferred. Maintain three distinct categories throughout the investigation:

1. Original Report (Reported Claim): Exact words, screenshots, timestamps, and steps supplied by the reporter—preserved verbatim even if parts later prove inaccurate.
2. Direct Observation (Measured Evidence): Exact HTTP status codes, stack traces, DOM state, database rows, log entries, or console errors captured during controlled attempts.
3. Working Hypothesis (Unverified Inference): Candidate conditions that might trigger the failure, paired with the test experiment designed to confirm or falsify them.

Extracting the Failure Signature

Before attempting to reproduce, define the exact Failure Signature so you never mistake an unrelated setup error or a different bug for the original issue:

• Expected Behavior: What the specification, contract, or user workflow requires at the failure point.
• Actual Observed Behavior: The specific exception class/message, wrong calculation, missing UI transition, HTTP 4xx/5xx body, corrupted state, or hang.
• Distinguishing Marker: The exact stack frame, error code, log line, or invariant violation that proves a reproduction attempt hit the same underlying failure mode.

Mining Existing Evidence Before Asking Questions

Exhaust every local and repository artifact before asking the reporter for more details:

1. Codebase Search: Locate the exact error string, toast key (i18n message ID), API route, or component referenced in the report or screenshot.
2. Log & Trace Correlation: Match timestamps, request IDs (x-request-id / traceparent), user/tenant roles, and input validation boundaries around the failure path.
3. Redaction & Privacy Discipline: Strip API keys, bearer tokens, session cookies, passwords, and unnecessary PII from screenshots, HAR files, and payload dumps before storing them in test fixtures or reports.

Formulating High-Leverage Clarifying Questions

Only ask a question when its answer directly prunes the reproduction search space:

• Ask about state transitions ("Did this happen immediately after login or after switching workspaces?"), data shape ("Did the item have attachments or special characters?"), or frequency ("Does refreshing the page recover the state, or does it fail on every retry?").
• Never blame the user or dismiss an intermittent report as "works on my machine."