Reporting good quality bugs is not always easy. There are so many criteria and aspects to count. In this short lesson, we’ll tackle some of the biggest elephants in the room, the reasons for the rejection of a reported bug.

1. Duplicate reports

This may seem obvious at first but it is still a mistake made often. In fact, this rejection reason occurs twice as often as any other.

When reporting an issue, if the same issue has already been reported, it will not be considered valid.  

💡 Here are some steps you can take to ensure the issue your report will not get rejected:

• Read the tester spec carefully. There are certain types of issues that are considered duplicates as long as the method of causing the issue to occur is identical, even if they occur in different areas of the application. If you find behavior that has already been reported, it is best to comment on an already reported issue and mention any other areas where this occurs, even if the issue does not belong to you.
• Check the issues reported on the cycle. Hop into the tracker and see which issues were already reported. Many of the issues encountered will generally occur on multiple devices. The easier it is to find and replicate the issue, the higher the chance this was already discovered and reported. Note that rushing is not ideal, not only will your issue be rejected, but you will have spent time reporting an invalid issue which could have otherwise been spent checking for other issues.

2. “Not an issue”

An issue marked with this status usually reflects an improperly described bug, which causes misunderstandings during moderation.

💡 Three simple steps to avoid having your issue rejected:

• Report the issue clearly and provide all the necessary information. While it is important to keep bug reports short and concise, make sure you always provide enough information. The more detail the Test Managers have, the less likely your issue will be rejected. 
• Understand the application. Before you begin testing make sure you understand the application you are testing. Context is extremely important for certain features. What may seem like a bug in one application, might be understandable in another.
• Avoid repetitive or vague descriptions. Using language such as “This behavior happens” or ”This behavior shouldn’t happen” isn’t constructive and needs to be avoided. Instead, explain why the behavior shouldn’t occur or suggest how it should behave.

3. “Not in scope”

While you may be testing the same app during multiple cycles, the scope and focus of the test can change.

The scope refers to what the general purpose of the cycle is.

Meanwhile, the focus, zones in on a particular feature or update that may have undergone recent updates and can potentially be unstable as a result.

💡 What are the correct steps to follow?

• Check the focus and scope of the test. Check the Tester Spec to see which areas are in scope for testing and what the focus of the test is. If the issue does not match the scope and focus, even if it is valid, it will be rejected.
• Check if any areas or flows are not to be tested. This is the same as above but needs to be emphasized. Sometimes the spec will mention a specific aspect that should not be tested.

As an example, the Test Spec may have the entire application in scope but will request that you do not test the payment/subscription section. This means that, while you may report any issues you encounter, these should not be related to that specific section or flow.

Note, that due to the high number of issues rejected because of this issue, the Not in scope rejection reason is also debated in the next article a little bit more details.

4. Poor Quality Report

This resolution focuses almost exclusively on the information provided or requested from the tester. If there is information or evidence required, this needs to be included. Sometimes a client specifically requests that something must be included in the report. If this is missing, the issue will be rejected.

💡 Solutions:

• Read the tester spec. This makes us sound like a broken record, we know, but really, all the information you need in order to test will likely be in that document. Evidence does not refer simply to a video or a screenshot. You may be requested to provide a specific log or attachment, in addition to the video or screenshot. Other times you may be requested to add login-credentials, title tags, etc.
• Provide the right evidence for the right situation. Often times we see testers provide screenshots for dynamic issues. This is wrong. If an issue needs to be observed in action to be understood, a video needs to be provided. A flickering screen? Stuck in a loading loop? Application crashes? A button doesn’t work? Provide video evidence. Screenshots are intended for static behaviors that do not require user input to trigger. Some examples include text typos, overlapping* or misaligned images, etc.

*Note that a static issue will require a video if the user needs to force the behavior to occur. For example, if a text field starts overlapping another field only when the user taps on it, it is no longer a static behavior.

• Make sure the report is clear and easy to understand. Sometimes the report is simply poorly written and is misunderstood. Ensure the sentences make sense, are written in proper English and can be easy to follow. If the description of the issue is too complicated or not clear enough, it can be misunderstood for another issue, or it simply cannot be reproduced.