Bug Report Writing Best Practices
sign in to trackA bug report is a communication document used to clearly describe a software defect. Its main purpose is to help developers and other team members understand, reproduce, investigate, and fix the issue efficiently.
A good bug report should be clear, specific, reproducible, and evidence-based. It should describe what actually happened without assumptions or unnecessary information.
Essential Elements of a Bug Report
Bug ID
A unique identifier for tracking the issue.
Example:
BUG-1024
Bug Title
Clearly summarize the problem in one sentence.
Avoid vague titles such as “Login is broken.”
Better: “Login button remains disabled after entering valid credentials.”
Environment
Include relevant environment information such as:Application/build version
Browser and version
Operating system
Device
Test environment
Relevant configuration
Preconditions
Describe anything that must be true before reproducing the issue.Example:
User has a registered account.
User is logged out.
Product is available in stock.
Steps to Reproduce
Provide clear, numbered steps that another person can follow.Example:
Open the login page.
Enter a valid email address.
Enter a valid password.
Click Login.
Test Data
Include the relevant input data when necessary.Example:
Email:
test@example.comProduct:
Product AQuantity:
2
Never include real passwords, payment credentials, or other sensitive information.
Expected Result
Clearly describe what should happen according to the requirement or expected behavior.Actual Result
Clearly describe what actually happened during testing.Severity & Priority
Indicate the impact and urgency of the defect when your team's process requires them.Evidence
Add supporting evidence when useful:
Screenshots
Screen recordings
Logs
API request/response
Console errors
Network information
Relevant test data
Example Bug Report
Title: Login button remains disabled after entering valid credentials
Environment:
Chrome 154, macOS, QA Environment
Precondition:
A valid registered user account exists.
Steps to Reproduce:
Open the login page.
Enter a valid email address.
Enter a valid password.
Observe the Login button.
Expected Result:
The Login button should become enabled and allow the user to submit the login form.
Actual Result:
The Login button remains disabled after valid credentials are entered.
Severity: High
Priority: High
Evidence:
Screenshot/screen recording attached.
Best Practices
Be specific: Describe exactly what happened.
Be reproducible: Provide enough information for another person to reproduce the issue.
Use numbered steps: Keep reproduction steps easy to follow.
Separate expected and actual results: Never combine them into one statement.
Use factual language: Report what you observed rather than assuming the technical cause.
Avoid blame: Focus on the behavior, not the person or team responsible.
Include evidence: Attach useful screenshots, videos, logs, or API details.
Mention frequency: If relevant, state whether the issue occurs always, sometimes, or under specific conditions.
Mention dependencies: Include required accounts, configurations, data, or environment conditions.
Avoid duplicates: Search existing defects before creating a new report.
Keep the title searchable: Include the affected feature and actual problem.
Protect sensitive information: Never include real passwords, tokens, payment details, or unnecessary personal data.
Common Mistakes
Avoid reports such as:
“Checkout is not working.”
This does not tell the developer what failed or how to reproduce it.
Instead, describe the exact behavior:
“Checkout displays a blank page after clicking ‘Continue to Payment’ when the cart contains a discounted product.”
The second report gives the developer a clear starting point for investigation.
◈Key Points
- Title: specific and action-oriented. Not 'Login broken' but 'Login fails with valid credentials when email contains a + character'.
- Steps to reproduce: numbered, minimal, and complete — anyone should be able to follow them.
- Expected vs Actual: clearly stated, not 'it doesn't work' but observable, specific descriptions.
- Environment: OS, browser, version, device, test data used — without this, reproduction is guesswork.
- Evidence: always attach screenshots, screen recordings, network logs, or console errors.
Before submitting a bug, reproduce it at least twice. If you can't reproduce it reliably, investigate further before filing — intermittent reports are the least trusted in any bug tracker.