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 joined in sharing the same experience with other developers. The team meeting turned a discussion point about bug rejection. After some discussion, we all decided to do a simple exercise to save ourselves from the humiliation of bug rejected, in the future.

Each one of us started taking out notes as the reasons for bug rejection for the last 10 bugs, reported and rejected. The list of those rejection notes proved useful to understand the future track of bug reporting and what was the wrong assumption made.

Bug Rejection And Reasons Behind It

Rather than revealing the list, I would like to share the outcome bullet points of the list. 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 would 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 that 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 were aware that specific requirement was going to be implemented in XYZ way. But while development, the developer found it was not possible to follow the XYZ path and so he followed the ABC path and that was not communicated to you.

Ultimately, you are going to report a bug when you found the requirement was not implemented the way it was discussed.

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. When the tailor explains that putting on buttons on the front would have impacted the overall look of the shirt and hence he put it inside the front border, you would definitely dumbfounded.

#3) No clear Requirements:

When there are no clear requirements available, everyone is free to assume the requirement in his/her own way and this leads to an assumption at a personal level. When you see that 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 own way and the outcome was a tricycle, baby cycle, too many cycles, cycle with the wheelchair and so on.

#4) Change in Requirement:

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 definitely going to reject the sandwich when you find it used honey bread rather than the banana bread you ordered. Least you knew that your partner changed the bread type for 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 start testing something which should not be considered as 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 definitely going to be ignored.

#6) Test Environment:

An application/product is a combination of many hardware and software requirements – major and minor both, and when proper test environment is not used or something is missing from the test environment, application/product crashes and a critical bug 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 a friend’s house before a couple of days 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, 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 mismatching 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. Really?

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. Again rejection.

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

#9) Improper bug description:

When the developer does not able to understand what you were trying to convey via the bug report, expect it to be rejected because they are also loaded with other tasks and when they do not find proper description and required details in bug report, no matter how critical the bug is, it is expected to be marked as Rejected.

Recommended reading => How to write a good Bug Report? Tips and Tricks.

Real-life Example: You need to unlock the car, should take a sit and should start by moving the keys in 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 will surely understand that it should be by default checked.

#10) Non-Reproducible bugs:

While reporting a bug, you never realized 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 the rough cold but he does 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 in improving 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: This useful article is written by STH team member Bhumika Mehta. She is a project lead carrying 7+ years of software testing experience.

Happy testing! As usual waiting for your views on the same.