A good bug report is one that describes the problem well enough that someone who is familiar with the project can understand and act on that bug report without talking to the person who wrote it. The following procedures and guidelines are the basic steps to create a good bug report.
Best Practice and Guideline for Bug Reporting
Recommended/Mandatory fields
To make a better bug tracking and reporting system, it is highly recommended to have fields that can be helpful to filter the bugs. Therefore, the following fields should be considered while creating a bug:
a. Priority: Priority is used to understand how critical of the failure is. An important field for analyzing the readiness of the release.
b. Affects Version: Affects Version is used to understand the build version where the bug was found.
c. Sprint Version: This field is used to highlight the Sprint version under which the bug will be fixed. By default, QA needs to enter the sprint as ‘JY Bug Backlog’. The ‘JY Bug Backlog’ is just a sprint created on the JIRA board, that doesn’t start and doesn’t get removed. The Engineering Lead reviews the bug daily and assigns the correct Sprint version.
d. Fix Version: This field is used to highlight the build version on which the issue was fixed. This field is only filled up by the developer once the bug is marked as resolved.
e. Epic Link: This field is used to enter the Epic ticket for the functionality related to the bug. This is an optional field.
f. Engineering Lead: This field is used to enter the name of the Engineering Lead who is leading the project.
g. Components: This tag field is used to select the application area which is related to the bug. Example: If the issue is found related to login, the ‘Login’ component or related component should be selected.
h. Labels: This is a custom field where you can add your own label tags. Generally, this field is used for tracking the tickets or highlighting specific issues. Some of the common labels used are NOT_FOr_QA, UI_BUG, PRODUCTION_BUG, etc
Summary
A short and concise summary of the issue (like the Title). It should summarize what is not working instead of what suppose to do or your suggested solutions.
- Prefix issue summary with UX or UI in case it’s a User Experience or User Interface related issue.
Description
need to contain:
- Test Server URL
- Server name and the user you used.
- Describe what type of user or user permission is in order for other people to reproduce this issue.
- Steps to reproduce
- Expected Result: The expected result of the test. Example: A message ‘Please enter a valid quantity between 1 and 10′ should be displayed if the specified quantity is invalid.
- Actual Result: The actual result of the test. Example: No validation message is shown when the user enter more than 10 quantity in the field.
- Different conditions you have tested could help the developer to nail down the issue. Like
- Mozilla Firefox-specific
- Windows 10 specific
- It only happens when the user does not have XYZ Permission.
- It only happens when on the ABC page.
- Exception Log
- Attach any screenshot/gif video that would help to reproduce the bug.
Search Jira to check if the issue is known or duplicate
- If the issue is already reported and has been closed within the current sprint, you should reopen the bug and add the latest screenshot/gif video.
- If the issue is already reported and has been closed in the previous sprint, you should create a new bug by cloning the previous bug and updating the fields as per the current Sprint. Generally, it is recommended to prefix the bug summary with ‘Clone’ for tracking purposes.
Best Practice and Guideline for Bug Verification
- The developer resolves the bug and creates a PR (Pull Request) with the Fix Version.
- Once the PR is merged, the Developer changes the status of the bug to Resolved.
- Based on the Fixed Version, QA checks Resolved ticket queue.
- QA go to TeamCity and deploy the changes to the QA environment
- QA verify the bug and change the bug status as per Bug Reporting Procedure#DefectLifeCycle
How to deal with Production Defects?
When a production bug is found following action is taken by each team:
- Support team log Jira ticket for production bug.
- The Prod Dev team updates the label of the ticket with the ProductionBug.
- Dev/QA team do the root cause analysis.
- The functional team reviews the bug priority.
- The Prod Dev team fixes the issue and based on priority either the Hotfix branch is created or else the fix goes into the usual release branch.
- QA team review the bug and add a test case in automation or manual test suite.
- QA team test the bug and give the sign-off.
- Prod Dev lead creates Release Overview page.
- The DevOps team is informed to deploy the build on the production.
What Do You Think?
Did this work for you?
Could I have done something better?
Have I missed something?
Please share your thoughts using the Contact Us form. Also, let me know if there are particular things that you would enjoy reading further.
Cheers!