EY refers to the global organization, and may refer to one or more, of the member firms of Ernst & Young Global Limited, each of which is a separate legal entity. Ernst & Young Global Limited, a UK company limited by guarantee, does not provide services to clients.
7 Things to remember for making a good bug report
When writing bug tickets, remember that the sole audience is the developer who will be implementing the fix. Reports must be concise and exceptionally clear about what is going wrong and what the expected end result is. All important details should be put on the table to ensure the developer can diagnose, fix and retest in the right timeframe.
In practice, the bug ticket is like a recipe. Miss one ingredient and the dish won't turn out as expected. So here is our recipe for a strong bug ticket:
1. Reporter & assignee
List the name of the individual reporting the bug. If the defect is raised on the current ticket being tested, QA can assign it to the same developer who worked on the original ticket. If a new issue is raised that is not related to any current ticket, the assignee field can be left for a project manager to find the right developer.
2. Title & description
Write a specific title relevant to the nature of the issue. This is the first thing a developer sees, even before opening the ticket and reading the details. The description should be a short summary of what the problem is. It is usually one to three sentences long. It should state exactly what is happening.
3. Steps to reproduce
Clearly describe the steps that need to be taken to witness this bug happen in real time. Steps should be thorough and easy to follow. Do not assume or skip any reproducing steps. For complex issues or bugs that are not reproducible all the time, it is best to meet one on one with a developer and discuss the issue further.
4. Actual behavior vs. expected behavior
Detail the actual behavior — what happens after the reproduction steps have been executed. Include screenshots, URLs and any other supporting information. Then specify the expected behavior — how the system should behave in real time. It is necessary to outline what the user should expect.
5. Severity & priority
Evaluate and describe the severity of the bug's impact on the tested system: critical, major, minor or trivial. Priority indicates the urgency of the reported bug — how critical it is for the business. High, medium or low priority assignment determines the order that bugs will be worked on after they are reported. If there are many bugs in the backlog, a bug triage meeting should be held that includes the product owner or project manager to review the severity and priority assigned.
6. Environment & devices:
List the environments where the bug was detected to ensure the developer can replicate it. This is because the application may behave differently in different test, user acceptance testing (UAT) or production environments. It is equally important to define the type of platforms and devices used: URLs, mobile devices and the operating system.
7. Affects version:
List the application version where the issue was detected. For example, you found a bug in your software that affects versions 1, 2 and 3 of your software. You should put 1, 2 and 3 for the “Affects versions” field. This allows the development team to track bugs or defects in already released code, and trace back to where the bug originated.