Improve Bug Report Writing Skills

A bug is the deviation of the actual result from the expected result. Each bug found during the testing process must be reported for its further fixing. A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result or to behave in unintended ways.

A Good Bug Report always helps the Development Team and Non-Technical Persons to understand the Bug clearly. If the Bug Report is good, the chance of fixing it is high. Otherwise, it may lead to rejection or clarification. Before reporting a Bug, make sure that the Bug is reproducible.

The first step in writing a bug report is to identify exactly what the problem is. Saying “something is wrong” is not helpful; saying exactly what is wrong, and how to reproduce it, is. If you can tell exactly what is wrong, and reliably reproduce an example of the problem, you’ve isolated a bug.

It is a brief summary of the bug specifying the actual issue including the module etc. The goal of the summary is to make the report searchable and uniquely identifiable.

A bad example: Drag Crash

A good Example: Drag-selecting any page crashes Mac builds in NSGetFactory

A detailed description of the bug containing test steps, expected and the actual results. The overview or description of a bug report is to explain the bug to the developer, including:

1. Abstracted summary of behavior (e.g. interpretation of test failures)
2. Justifications of why this is a bug
3. Any relevant spec links
4. Interpretation of the spec
5. Information on other implementations

We number our steps from beginning to end so developers can easily follow through by repeating the same process. We prefer to keep step numbers relatively whittled down by using the “>” symbol.

Example description for steps to reproduce a bug:

1. Go to settings > Profile (this would take the user to new screen)
2. Tap on More Options > Delete Account

This way you can provide more process information that leads to the next step without having a reproduction list that appears tediously long.

The test results, including Expected Result and Actual Result, will show the developer what’s wrong. Expected Results describes what should have happened, and the Actual Result describes what actually happened.

Expected and Actual Results are necessary for a bug report. The former implies what the user is expecting or what the requirement contains, and the latter implies the outcome of the test execution.

Any pertinent screenshots, videos, or log files should be attached. Testlio bug reports usually require both a video and a screenshot, depending on the nature of the issue. If the issue requires steps to trigger the bug, then a video is required. If the bug is, say, a minor UI issue that is always present, then a screenshot will suffice. Logs are also required no matter the issue.