Bug Report Phrases
28 phrases and templates for writing clear, professional bug reports — from the title to severity and workaround documentation.
- What is broken? (title / summary)
- How do I reproduce it? (steps)
- What should happen vs. what does happen? (expected / actual)
- Where (environment, version) and who is affected?
- How bad is it? (severity / impact)
Bug Report Title & Summary
- [Component]: [Short description of what's broken] — [environment/version]Standard title format: component · description · context
- [Feature] does not work as expected when [condition]Behaviour gap — avoids blaming
- [Feature] throws [ErrorType] when [action]For exceptions and crashes
- Regression: [Feature] broken since [version/date]Use "Regression" for things that used to work
- Intermittent: [Feature] occasionally [problem]Explicitly flag non-reproducible bugs
Steps to Reproduce
- Steps to reproduce:Use this as a header — reviewers scan for it
- 1. Go to / Open / Navigate to…Start with the entry point
- 2. Click / Select / Enter…One action per step
- 3. Observe that…Where the bug appears
- Reproducibility: Always / Sometimes (~50%) / RarelyAlways state how consistently it occurs
- Preconditions: [what setup is needed before Step 1]Any state or data required to trigger the bug
Expected vs. Actual Behaviour
- Expected behaviour: [what should happen]Describe the correct outcome
- Actual behaviour: [what happens instead]Describe the incorrect outcome precisely
- The system should [verb]…, but instead it [verb]…Single sentence combining both
- Error message: "[exact text]"Always quote error messages exactly — include the full stack trace if available
- No error is shown, but the data is incorrect / missing.Silent failures are common — be explicit
Environment & Context
- Environment: production / staging / localSpecify where the bug was found
- Version: [app version] / Commit: [SHA]Pin to a specific version or commit
- Browser: Chrome 122 / Safari 17 / Firefox 123For frontend bugs — include version
- OS: macOS 14 / Ubuntu 22.04 / Windows 11For desktop or CLI bugs
- Account type / role: [admin / free / trial]If behaviour differs by user role
- Attached: screenshot / screen recording / logsAlways mention what evidence you've attached
Communicating Impact & Severity
- Severity: Critical — production data loss / service down.SEV-1 language
- Severity: High — core feature broken, no workaround.SEV-2 language
- Severity: Medium — core feature affected, workaround exists.Note the workaround if there is one
- Severity: Low — cosmetic issue / minor inconvenience.Cosmetic bugs still deserve tickets
- Impact: approximately X users affected / seen X times per day.Quantify when you have data
- Workaround: [steps]. This resolves the issue temporarily.Document workarounds to reduce support load
Frequently Asked Questions
What does 'workaround' mean in a bug report, and how is it different from 'fix'?
'Workaround' describes a temporary solution that allows users to continue using the system despite the bug. It's typically a manual or alternative process that bypasses the faulty code. A 'fix' represents a permanent change to the underlying code addressing the root cause of the issue, while a workaround only mitigates its immediate impact.
I saw 'regression' used in a bug report – what does it specifically refer to?
'Regression' indicates that a previously working feature or functionality has suddenly stopped functioning correctly after a code change. This often points to unintended consequences introduced during development, requiring investigation into the recently deployed updates.
Can you explain 'severity' and 'priority' when reporting bugs? Are they always the same?
'Severity' describes the impact of a bug on the system – how much damage it can cause (e.g., data loss, service outage). 'Priority' determines the urgency with which the bug needs to be addressed, based on business impact and resources available. While related, they're distinct; a high-severity bug might have low priority if a workaround exists.
What is 'stack trace' and why is it important in a bug report?
A 'stack trace' is a detailed record of the function calls that led to an error, providing context about where the problem occurred within the code. It's crucial for developers to understand the sequence of events leading to the crash or unexpected behavior and pinpoint the exact location of the bug.
I've encountered 'null pointer exception'. What does this mean in a bug report?
'Null pointer exception' occurs when your code attempts to access a variable that has not been assigned a value, or is unexpectedly null. This typically indicates a logic error where the system expects data but doesn't receive it, leading to an unhandled attempt to use that data.
What's 'cold start' and how does it relate to bug reports?
'Cold start' refers to the initial state of a system or application after it has been idle. Bugs related to cold starts often involve issues with initialization processes, data loading, or resource allocation that are problematic when the system is first started.
Explain 'memory leak' and why would I report this as a bug?
'Memory leaks' occur when an application allocates memory but fails to release it properly after use. Over time, this can lead to performance degradation and eventually system crashes, making it a significant bug to report due to its cumulative impact.
What's the difference between 'reported bug' and 'duplicate bug'? How do I describe them?
'Reported bugs' are unique issues identified by a user or tester. 'Duplicate bugs' represent identical problems already documented, preventing redundant investigation. Clearly state whether you're reporting a new issue or identifying a duplicate to avoid confusion.
I saw 'timeout' mentioned in a bug report – what does this signify?
'Timeout' indicates that a process or operation failed to complete within a defined time limit. This usually points to performance bottlenecks, network issues, or problems with external services the application relies on during execution.
What is 'race condition' and why is it often difficult to debug?
'Race conditions' occur when multiple threads or processes access and modify shared resources concurrently, leading to unpredictable results. They are notoriously hard to debug because the outcome depends on the timing of events, making reproduction challenging.