10 Reasons Why Your Bugs Are Getting Rejected and What You Can Do for It as a Tester!

If you’re a tester and wondering reasons your bugs are getting rejected, we have compiled a list of 10 reasons and provided some recommendations on how you can improve.

I am not going to spare her. She has rejected 7 bugs, I reported, within the last three days. I know she is using personal grudges as a professional sword.

A teammate was fuming and the discussion suddenly caught fire when a couple of other teammates shared the same experience with other developers. The team meeting turned into a discussion point about bug rejection.

After some discussion, we all did a simple exercise to save ourselves from the humiliation of bug rejection in the future.

Each of us started taking notes as the reasons for bug rejection for the last 10 bugs, reported and rejected. The list of those rejection notes helped us understand the future track of bug reporting and identify the wrong assumptions made.

Bug Rejection And Reasons Behind It

Instead of disclosing the list, I prefer to share the key bullet points of the outcome. Here it is:

#1) Misunderstanding the Requirements

For any reason, if you did not understand the requirement properly, you would definitely look out for the misinterpreted requirement in actual implementation and when you did not find it, it would be a bug according to you, which will finally get rejected.

Real-life example: After testing a recipe, you found it was tasteless as salt was not added, but you did not know that salt was supposed to be added at the time of serving otherwise, it can affect the look of the recipe.

#2) Requirement Implementation

As a part of an earlier discussion, you knew that a specific requirement was going to be implemented in the XYZ way. But while developing, the developer found it was not possible to follow the XYZ path, so he followed the ABC path that was not communicated to you.

In case the requirement was not implemented as discussed, reporting a bug is necessary.

Real-life example: You asked the tailor to prepare a shirt and when you were asked for the trial, you rejected it saying you did not find buttons on it. The tailor’s justification for placing the buttons inside the front border to maintain the shirt’s overall appearance would completely shock you.

#3) No Clear Requirements

When there are no clear requirements available, everyone is free to assume the requirement in his/her way, and this leads to an assumption at a personal level. When you see personal assumption is not satisfied, you mark it as a bug.

Real-life example: You need to draw a cycle when the teacher announced she had expected the students to draw a bicycle. After half an hour, when she checked everyone’s drawing, she did not find anyone matching her expectations. Everyone took the vague statement in their way and the outcome was a tricycle, a baby cycle, too many cycles, a cycle with the wheelchair, and so on.

#4) Change in Requirement

Here is another example of miscommunication most of the time. When testers are not communicated about requirement changes, more bugs will be reported and ultimately rejected.

Real-life example: You are going to reject the sandwich when you find it used honey bread rather than the banana bread you ordered. At least you knew your partner changed the bread type of order while you were on the phone and, of course, he/she did not find it necessary to share it with you.

#5) Understanding Scope

While testing, you test something that should not be considered testable at a specific point or is not at all covered under product criteria; you are going to be a victim of bug rejection.

Real-life example: You are supposed to sweep a room, and that is the only focus. Still, if you complain about the mess in the other areas, you are going to be ignored.

#6) Test Environment

An application/product is a combination of many hardware and software requirements – major and minor, and when the proper test environment is not used or something is missing from the test environment, the application/product crashes and a critical bug is reported.

What happens next is–deep investigation because most of the time, we unintentionally do not take care to provide minor details about the test environment we used, and that increases the developer’s work. Ultimately bug gets rejected.

Real-life example: Those yummy muffins you tasted at a friend’s house a couple of days ago were awesome and after following the recipe, the muffins were not even nearer to the one you had.

Well, you were not supposed to use stale butter, as fresh butter was not available; you were not supposed to add the pinch of gram flour as you thought it might add the taste, and you were not supposed to cook it on the pan as the oven was out of order.

Recommended reading => How to Effectively Prepare “Test Environment”.

#7) Test Data Used

Test data used for testing was mismatched with a requirement.

Real-life example: Even after knowing that the calculator is useful for numeric processing if you try to add special characters and when the calculator responds unexpectedly, you think it was improper. Is that true?

Recommended reading => Tips to design Test Data and Test Data Management Techniques.

#8) Duplicate Bug

Someone has already reported the same bug, and you did not take care to check for the same before reporting the bug. Once more, rejection.

Real-life example: The customer support person will not be happy when he receives multiple complaint calls for the same product from each family member. Wasn’t one call enough, he would think.

#9) Improper Bug Description

When the developer cannot understand what you were trying to convey via the bug report, expect them to reject it because they are also loaded with other tasks. Additionally, if the bug report lacks proper description and required details, regardless of the bug’s criticality, they are expected to mark it as rejected.

Recommended reading => How to write a good Bug Report?

Real-life example: You need to unlock the car, take a sit, and should start by moving the keys in a clockwise direction….the car did not start and so you are upset. Weren’t you instructed to check for petrol? Oh, a mistake in the manual as it assumed that you would surely understand that it should be by default checked.

#10) Non-Reproducible Bugs

While reporting a bug, you never realize the importance of the reproducibility of the bug. Just making sure whether the bug is reproducible always or appears randomly can save hours of work and one more rejected bug.

Real-life example: What would the doctor check for when you complain about a rough cold but do not find any symptoms? Oh, I was just sneezing hard, will not make the situation better.

Conclusion

Most of the time, our human nature allows us to think negatively when the bug reported is rejected. Genuinely, developers do not see a specific reason to reject the bug if it is valid.

So, next time onwards, please do not focus on the bug count. Focus on qualitative bugs with proper details because ultimately, what matters is how you helped improve the quality of the product and not how many bugs you reported.

Also Read => How to get your all bugs resolved without any ‘Invalid bug’ label?

About the author: Bhumika Mehta, a team member of STH, is the author of this informative article. She is a project lead carrying 7+ years of software testing experience.

Have a joyful testing experience! Once again, I’m eagerly awaiting your perspective on this.