How to Report a Bug

It feels wonderful to be able to write the first blog post on our product as it is being released. I thought the most pertinent and easiest subject to write about would be the heart of the tester’s process: how to report a bug once you have found one.

First, and foremost, the first and most important rule of reporting bugs is to be as specific as possible! I cannot reinforce enough how imperative it is for testers to write every possible piece of pertinent information. It is very easy for a tester to see a problem in front of them, and not realize that they are not communicating the needed information. When attempting to recreate the problem, a testing manager will be looking at a bug without being familiar with it at all and only through the information the tester provides will they be able to (or not to) recreate the problem.
More specifically related to our platform, here are a few tips for using the uTest Platform:First prior to starting testing you must review the information supplied by the company under the release details. This may include critical information for testing (like sign in codes) or specific test scripts that need to be downloaded.


Now for the information you need to supply when reporting a bug:

Subject: This denotes the title and type of bug. Please fill in with the best categorical description possible.

Type: Type refers to the category of bug. At the moment, there are only a few classifications such as: GUI, logical and Technical. However, as applications are released more types of bugs will be added. Please pick the type which most closely is associated with the bug you found.

Severity: This indicates how severe the bug is to the application. A bug which has only minor impact (i.e. a broken link), is not nearly as severe as a bug which causes the application to crash.

Frequency: How often does the bug happen? Frequency indicates if you can replicate the issue every time you go through the steps, or if it only works a few times.

Maturity: Maturity enables you the tester to report his own impression of the maturity level of the application he is testing.

Action Performed: The test case is the process which the tester went through in order to recreate the bug mentioned. This is the most critical fieldpiece of information because the testing manager will try to reproduce the bug based on the information supplied in this field. Please attempt to list all environment details (for example if you had another application open, etc.), and the exact steps you took in encountering the bug.

Expected Result: This field refers to the tester’s expectations when encountering a situation. For example, if a tester was going to click on a link, the expectation would be that the link would bring them to a specific page.

Actual Result: The result refers to the actual occurrence. In the example above, if the link brought you to a different page, or no page at all, that would be the “result.”

Error Code/Message: The error code refers to if the application gives an actual code output (which it may or may not). An error code might look like: “Error 24282x” The message is reserved for any message displayed; i.e. “Error in code line 272….”

Environment and Additional Info: Environment and additional is where you enter any additional information about the platform you are running, or other external conditions you think might have caused the reported bug.

Attachments: Screenshots and logs are highly important to describe a bug in a professional manner. A good screenshot can make the diffrence between a crystal clear bug and a vague bug. we recommend to attach any file that may help the company to understand the problem faster (and approve the bug faster…).
That’s it for now.

Happy Testing.