Before reading this article, make sure you are familiar with and follow the standard Bug Report Requirements.
This article contains advanced bug reporting tips and best practices for experienced testers.
The recommendations below are not mandatory Bug Reporting requirements. They are optional techniques that can help you create more efficient and professional bug reports while maintaining clarity, reproducibility, and overall report quality.
Include Relevant Conditions in the Title
If a bug can only be reproduced under specific conditions, consider including the most relevant condition directly in the title.
Adding important conditions can make the bug easier to understand and help distinguish it from similar bug reports without opening the report itself.
Examples of useful conditions include:
Logged-in or logged-out user state
Specific user actions
Browser-specific behavior
Device orientation
Account settings or feature flags
Particular data inputs or selections
Example: Less informative | Example: More informative |
Login button is unresponsive on the Login page | Login button is unresponsive on the Login page after entering an incorrect password |
Error message is displayed when submitting the checkout form | Error message is displayed when submitting the checkout form with an expired coupon code |
App crashes on the Profile page | App crashes on the Profile page when opening it from a push notification |
Use a More Direct Starting Point When Appropriate
The standard approach is to start the reproduction steps from the URL or app entry point provided in the Test Cycle.
However, experienced testers may choose a more direct starting point when it helps reduce unnecessary steps and still allows the bug to be reproduced reliably.
For example, instead of starting from the application's landing page and navigating through multiple screens, you may start from:
A specific page URL
A particular section of the mobile app
Any other location that consistently leads to the bug
Example: Web Application
Standard approach: | More direct approach: |
|
|
Example: Mobile Application
Standard approach: | More direct approach: |
|
|
Using a more direct starting point can make bug reports easier to read and maintain by eliminating unnecessary navigation steps. However, make sure that anyone following the steps from your chosen starting point can successfully reproduce the bug.
Show Your Interactions in Screencasts
When possible, consider enabling visual indicators for your clicks or taps in screencasts.
Showing your interactions can make it easier for reviewers to understand exactly which actions were performed and when they occurred. This reduces ambiguity and leaves less room for interpretation, especially when multiple interactive elements are displayed on the screen.
Clear visual indicators can also help prevent additional information requests, as reviewers can more easily follow the reproduction steps and verify the reported behavior.
Examples include:
Showing mouse clicks in desktop recordings
Enabling touch indicators on Android devices through the Developer Options menu
Using any available recording feature that makes interactions easier to identify
Verify Your Language Settings Before Recording Evidence
Before collecting evidence, consider checking that your device, browser, and application language settings match the language required by the Test Cycle.
This can help ensure that relevant information is displayed in the expected language and make the bug easier to understand and review.
Example: If the Test Cycle language is English, screenshots and screencasts should ideally show relevant information in English, including error messages, system messages, browser messages, device settings, and system information.
Taking a few moments to verify your language settings before collecting evidence can help avoid confusion and reduce the need for additional clarification during bug review.