INTRODUCTION
If your bug report is effective, then its chances are higher to get fixed. So fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and in this writing will explain you how to achieve this skill. If a tester is not reporting bug correctly, engineer will most likely reject this bug stating as irreproducible or take more time to understand the bug.
Effective bug report can reduce the time between finding a bug and resolving it.
The aim of bug reporting is to explain an issue to engineers as soon as possible to aid overall product development. Before the QA team starts writing a bug report, they should know the answers to the following questions:
- WHAT? — What has happened with the application?
- HOW? — What did we click/do to produce the bug?
- WHERE? — Where exactly in the app did we find the bug? What is the webpage and/or server (environment)?
Let’s start how to create effective simple bug report!!
STRUCTURE OF A BUG REPORT
- Bug ID
- Bug Summary
- Bug Details
- Bug Priority
- Bug Description
- Attachments to the bug report
BUG ID
Bug ID should be unique and have simple format. The simple format will have us if we need to mention the bug id to engineer. If we use tools like JIRA, JIRA will automatically assigns an ID to the bug (card).
Good: PI-123, BUG-002, etc…
Bad: 12413–13413–124412, PISX-135135–9058, etc..
BUG SUMMARY
The summary may be considered the main part of the bug report. For starters, we advise QA to use short and informative titles. A bug summary usually consists of a module and short description of the problem. A short description is one or two sentences that tell exactly what happened. We should avoid describing emotional reactions or subjective opinions.
Good: “About the company screen. Red strip on the top of the screen” or “Layout issues in the ‘Rules’ screen.”
Bad: “Something wrong with Rules” or “Why are there problems with the screen???”
BUG DETAILS
We should state the application version as well as the test environment. Usually, an application is updated every two to three weeks. For example, we might release a new version of an app with bug fixes every two weeks. This means that there’s no need to create a late bug report about some problem in the 2.01 version if we have already implemented the 2.21 version by now. We need to add new reports in a timely manner, and always to specify the exact version of the application in which they reproduced a bug.
A test environment can be a website version, an operating system, or a web browser depending on the type of the bug. For instance, you may have two websites — www.my-website.com and testing.my-website.com. These are two different environments (test server and production server) and they may exhibit different bugs. Therefore, QA must indicate this data as a URL in their bug report. A browser name and version is usually mentioned if layout issues were found. We need to always report an environment. It makes the work much easier as web developers will know exactly where QA discovered an issue.
If we don’t add this data, then engineers may check an irrelevant test environment. They won’t find a bug there and may even close the task while the bug persists.
BUG PRIORITY
These two metrics may either be listed as separate characteristics or united in one parameter. It depends on the bug tracking system your QA use. Bug Priority is an estimation of the impact of the bug on the application, along a scale ranging from highest (a bug blocks key functionality) to low (a bug is very difficult to reproduce; main functionality works as it should, but there are minor issues with some rarely used functions). Generally, We use this tool.
Types of Priority:
- Highest: No further testing work can be done, application crash, loss of data
- High: Major loss of function.
- Medium : Minor loss of function.
- Low: Some UI enhancements.
BUG DESCRIPTION
QA should provide engineers with Steps to Reproduce and Results in this part of the bug report.
Steps to Reproduce: This part of a bug report is dedicated to a description of how the bug occurs. The more informative QA are, the better. Steps to Produce include:
- The description of where in an application an action was taken. QA should mention a browser, its version, and the system state: a user type, user state, system initial data, and the location where a user was.
- Actions — what a QA does to produce a bug.
- Actual results — An actual result is what happens when a QA reproduces a bug. QA team need to provide a screenshot of the actual result for comparison with what was expected. An expected result is what we predicted as normal functionality under the given conditions.
- Expected results — An expected result is what we predicted as normal functionality under the given conditions.
BUG ATTACHMENT
Point the bug on attachment, you can move pointer around for video and create marking for image, or attach some document report, etc..
TIPS AND TRICK
- Use simple English, or Bahasa Indonesia (locale) if you think it would tell the problem clearly;
- Tell specific location where the bug occur;
- Bug title is short description of the bug itself, it should tell what happened;
- Bug description must be short and sharp, easy to understand and tell what actually happened;
- Add or attach any document / link strengthen your argument;
- Use ordered list for step, you can mention ‘repeat step [number]’ to create the step shorter;
- Begin the step with specific location where the bug happened or the entry point which cause the bug appear;
- End step with telling us what is expected and actual result;
- Practice makes perfect.
