Course 5: Issue Rejections

Learn all the values of issue rejections in the Applause platform.

Issue Rejections

When a bug is either not in scope, a duplicate, not an actual bug or does not follow proper guidelines, a rejection is appropriate. A rejection for any reason other than WAD will impact a tester’s rating. Rejection types are explained in detail below.





WAD (Works as Designed)
  • Tester did not know the specifications and took a guess

  • The issue 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 and it is reported in the cycle (this would otherwise be a duplicate)

Note: 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 more information from the tester to verify if the issue still exists or not or to provide more info if needed.




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




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 issue lists are extremely large, lacking detail for testers or 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




Other

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