Nowadays, software test engineers are in a constant need to improve the software they are testing so that it can enhance their test effectiveness and increase their confidence in the system overall. In order to do that, they test the software to validate its functionalities and find bugs. Finding a bug may sound pretty straightforward in some cases, but that doesn’t mean reporting it effectively should also be a quick job. A good bug report is of utmost importance to you, developers, product owners, and the whole team in general.
Before going in-depth in what should the content of a good bug report be, let’s first explain what is a bug and its life-cycle.
What is a bug?
Bug (defect) is an error in the software that causes it to throw some incorrect output. The bug can arise in many layers of the system from the requirement stage or in the code or maybe when testing the back-end services or the UI.
No matter on what stage the bug is found, you need to make sure that:
- You confirm that it is a bug in the system
- Raise it to the appropriate level depending on its severity
- Talk with developers to reproduce it again
- Double-check all the things you need to do to reproduce it
- Put yourself in an end-user role and assess how important it is to be prioritized
Lifecycle of a bug
Let’s say you found a bug that needs to be fixed right away. QA engineer can report it to developers and from that point on several things needs to happen:
- First, the bug is created – NEW
- Then the bug can be opened for the developers to work on it – OPEN
- Developers fixed the bug after a couple of hours/days depending on its complexity – FIXED
- Testers retest the bug they’ve reported to check whether it still persists or not – RETEST
- If the bug is still active then testers return the bug back to developers for further investigation – REOPEN
- If the bug is fixed then the testers gather test evidence from that bug and move the ticket to status done – CLOSED
What should be in a bug report?
Now that you have a clear picture of what is a bug and what is its lifecycle, I’m going to dive-in in into what content should a reported bug have.
Title
The title is very important since that is the first thing the developers see when the bug is assigned to them. The title should not be too short or too long, should be descriptive enough, and should cover the functionality name where the bug arises.
Wrong: Update does not work
Correct: Cannot update user catalog number
Summary
In the summary section, you briefly (a couple of sentences) explain what the bug is and what is the output from it.
Wrong: Drop-down button on the page does not work
Correct: Drop-down button on the user catalog section does not work correctly when it contains more than 3 items.
Environment
If the bug you are reporting is on the API service side then you can mention the environment name as well as the API name and its version that this bug was found. Other third-party systems, dependencies, and their versions can be also mentioned.
If the bug is focused on the UI side then you can add all of the above mentioned back-end information plus the website name and its URL.
Wrong (not enough info):
| Environment | Version |
| test-environment.test | 1.0.1 |
Correct:
| Environment URL | ENV Version | API Services | API Version |
| www.test-environment.test | 1.0.1 | test-api-service | 0.1.1 |
Severity & Priority
Adding severity and priority gives the developers and product owners a representation of how important this bug is so that the work can be prioritized accordingly.
Severity can be set as:
High – Impact the main system workflow and block some of the main functionality
Medium – The functionalities are working fine. The impact is more focused on the wrong output of one particular functionality
Low – Doesn’t affect functionalities, no blocking issues, just a small UI fix or typo’s, etc
Priority can be set as:
Major – Must be fixed asap since it is a blocking issue
Critical – Should be picked up for investigation since it affects one of the main functionalities
Medium – Can be picked up for investigation since it gives a wrong message response for a particular service
Minor – Can be picked up for investigation when resources are available
Steps to reproduce
Here you can define all of the steps that are needed in order to reproduce the bug. The steps must be easy to read and descriptive enough so that the developers and other members of the team can easily understand what they need to do to reproduce the scenario.
Wrong:
- Open user catalog
- Click on details button
- Check output
Correct:
- Go to www.test-environment.test portal
- Navigate to the user catalog section for item 22 on the left menu tab
- Find and click on view more button
- Check whether details are shown for the item 22
Expected result
Here you should add what should happen from the actions above as an outcome. When should the expected behavior be for this particular scenario?
Wrong: Details for user catalog section are shown
Correct: Details for user catalog section item 22 are shown
Actual result
The actual outcome/result of the scenario.
Wrong: Details for user catalog section are not shown
Correct: Details for user catalog section item 22 are partially shown
Screenshots proof
Any additional screenshots from the actual vs expected result should be helpful. Also, screenshots from the exact section when the bug appears or screenshots from all of the deployed services in the environment under test.
This is also important because image representation is always better than text and that is the first thing a human eye notices. That’s why always try to add screenshots from a particular area of the system.
An example of a good bug report
By now, you have a good idea of what a bug report should contain, how the information should be structured and how descriptive the information should be. Here an example of a good, effective, and structured bug report:
A few last words
A bug report is not something to be taken lightly. It is a serious skill that every QA engineer must attain. Knowing that in today’s world we have mostly iterative development approaches where small parts are delivered in short spans and often we must regression test all of the application including new tests, finding new bugs in the system is a challenge and knowing how to report them correctly is very important within the members of the team and to the project overall goals.
Share this post
Latest Posts
- Test Analyst’s Responsibilities in Risk-Based Testing
- Crucial Aspects Of Superior Test Code Quality
- Streamline Your Cucumber BDD Tests with Gherkin Lint: A Comprehensive Guide
- How to Test Authentication and Authorization with Confidence + Best Tips
- Exploring the Three Scrum Artifacts: Grasping Their Essence and Effective Utilization
