When a bug is either not in scope, a duplicate, not an actual bug or does not follow proper guidelines, a rejection is appropriate. So the platform provides respective rejection reasons:

• Duplicate
• Need more info
• Did Not Follow Instructions
• Out Of Scope
• Works as Designed
• Other

Note: A rejection for any reason other than Works as Designed (WAD) will impact a tester’s rating.

DUP (Duplicate)

• Issues already filed in the same cycle that the tester could have found by searching
• Issues that were in a known issue list provided in the cycle
  • When Known Issues lists are extremely large, or lacking detail for testers or lacking jargon laden that would have made the issue hard to find, it is often better to give the testers the benefit of the doubt for their efforts and reject these as WAD instead. Because WAD doesn’t negatively impact their ratings.

Need More Info

The tester didn’t provide appropriate evidence to the bug after numerous info requests.

DNFI (Did Not Follow Instructions)

• The tester ignored clear instructions which affected the outcome or made the report unusable
• These issues can often be solved by using the tester messenger instead of reject

OOS (Out Of Scope)

• A bug is logged that clearly falls into what is explicitly stated in the Out Of Scope section of the test cycle (testers will assume if it’s not mentioned in the out of scope and not explicit anywhere else, that it’s a bug. It is therefore best to be explicit in the scope and out of scope section)
• If the scope is narrowly defined and reason dictates that the bug would generally be considered out of scope (i.e. scope is to test the search results and a bug is reported against the Terms of Service link), then this reason is acceptable

WAD (Works as Designed)

• Tester did not know the specifications and took a guess
• The bug reported is not a true bug and is simply how the system works
• Can be used when a Known Issue has not been fully communicated to the testing team (this would otherwise be a duplicate) or when anything has not been properly explained.

Notes:

• Issues that can not be reproduced at a later time, should be rejected as WAD (Works as designed) or approved as “Won’t Fix” for that scenario.
• Also remember that you can request for more information from the tester to verify that the issue still exists or to provide more info if needed.
• Rejection for this reason does not affect the tester’s rating.

• Rejecting as WAD and Approving as “Won’t Fix” are designed to encourage testers to submit issues when they are unsure about them, so potential concerns aren’t missed for fear of rejection.

Other

All rejection reasons should be covered by using the above ones. In case you have a different reason for rejection, use Other. And this reason should be used only for issues that can be reproduced at a later time.