Bug Rejection Reasons & How to Avoid Them

Submitting clear and valid bug reports can be challenging since each report is evaluated based on multiple criteria. One of the most common rejection reasons is duplicate reports, which occur nearly twice as often as any other reason. Below you’ll find the main rejection types, what they mean, and how to avoid them.

Duplicate Reports

A bug is rejected as a duplicate if the same issue has already been reported, even if it appears in a different part of the app but follows the same reproduction steps.

How to avoid duplicate submissions:

• Review the Tester Specifications. Some issues are considered duplicates when triggered in the same way, regardless of location. If the behavior is already reported, add a comment to the existing issue instead of creating a new one.

• Check the issue tracker first. Many issues can appear across multiple devices. If it’s an easy-to-find issue, it’s likely already reported. Taking a few moments to verify can save time and prevent invalid submissions.

“Not an Issue”

A bug marked as Not an Issue usually happens when a report is unclear or incomplete, making it hard for moderators to understand the problem correctly.

How to avoid this rejection:

• Be clear and detailed. Provide all essential information while keeping it concise.

• Understand the product. Make sure you know how the app is intended to work. What looks wrong might actually be expected behavior.

• Be specific. Don’t just write “This shouldn’t happen.” Instead, explain why it’s incorrect and how it should behave.

“Not in Scope”

Even if you’ve tested the same app before, keep in mind that the scope and focus can change with each test cycle.

How to avoid this rejection:

• Always check the scope and focus in the Tester Specification before testing. If an issue falls outside of these areas, it will be rejected even if it’s valid.

• Pay attention to excluded areas or flows. For example, the app might be fully in scope except for payment or subscription features. Any bugs reported there would be rejected.

Note: This rejection type is quite common and is discussed in more detail in this dedicated article.

Poor Quality Report

This rejection is about missing or incomplete information. If required evidence (e.g. logs, credentials, or specific attachments) is not provided, your report can’t be properly evaluated.

How to avoid this rejection:

• Read the Tester Spec carefully. It lists all evidence requirements, not just screenshots or videos.

• Attach proper evidence:

  • Video for dynamic issues (crashes, loops, unresponsive buttons, flickering, etc.)

  • Screenshot for static issues (typos, alignment, or layout problems)

  • If a static issue requires user interaction to appear, treat it as dynamic and record a video.

• Write clearly and professionally. Use proper English, short sentences, and logical structure. Avoid vague or confusing descriptions that could prevent reproduction.

Summary

By carefully checking the Tester Spec, providing clear and detailed reports, and ensuring complete evidence, you’ll reduce your rejection rate and contribute higher-quality reports to every test cycle.