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

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

A team mate was fuming and the discussion suddenly caught fire when couple of other team mates joined in sharing 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 future.

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

bug rejection

Image source: TrainingJournal.com

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 recipe.

#2. Requirement implementation:

As a part of earlier discussion, you were aware that specific requirement was going to be implemented in XYZ way. But while development, developer found it was not possible to follow XYZ path and so he followed 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 trial, you rejected it saying you did not find buttons on it. When the tailor explains that putting on buttons on front would have impacted 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 assumption at 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 bi-cycle. After half an hour, when she checked everyone’s drawing, she did not find anyone matching her expectation. Everyone took the vague statement in their own way and the outcome was a tri-cycle, baby cycle, too many cycles, cycle with wheel chair 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 banana bread you ordered. Least you knew that your partner changed the bread type for order while you were on 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 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 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 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 test environment we used and that increases developer’s work. Ultimately bug gets rejected.

Real life Example: Those yummy muffins you tasted at friend’s house before 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 pinch of gram flour as you thought it might add the taste, you were not supposed to cook it on 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 requirement.

Real life Example: Even after knowing that calculator is useful for numeric processing, if you try to add special characters and when 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 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, mistake in manual as it assumed that you will surely understand that it should be by default checked.

#10. Non-reproducible bugs:

While reporting bug, you never realized the importance of 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 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 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 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.

Recommended reading

25 comments ↓

#1 Suresh

awesome read. most of things drill down to requirement understanding. isn’t it?

#2 Nikita Jain

Thanks for posting this article……….its really helpful !!!!!!!

#3 Viki

Thanks for sharing buddy!

#4 Vikram

Excellent Work!!! Help us to improve our quality a lot…..

#5 malligaRanjith

This is an awesome article who is getting this type of issues on tester’s life . Thanks for entire team :)

#6 masthanaiah

Good work.. this article helps a lot for all viewers…

#7 Gaurav K

Real life examples are really good

Regards
Gaurav Khurana

#8 Satish

Nice article shared! Thankyou

#9 Bhumika Mehta

@Suresh, @Nikita, @Viki, @Vikram, @Satish, @Gaurav, @masthanaiah, @masthanaiah

Thanks a lot for your readership and glad to know that you found the article useful. Tune in for more :-)

#10 Akhil

It was very much helpful….Thank you..!

#11 Banandh

Real Life examples are awesome and Thanks for sharing this Article Guys!!!

#12 Silambarasan

Awesome

#13 Vinay Saxena

Nice findings.
What should we do if our reported bug is rejected but it is correct ?
What should be the bug status now – NEW or REOPENED or …. ?

#14 Suresh

Thanks for sharing the nice article…

#15 Varun Setia

Hello Ma’am,
I have been continued reader of software testing help and ofcourse your post as well. Your posts are always so informative. Thanks for sharing your wonderful views with us.
Keep Posted ma’am…:)

#16 Sweksha

Really a helpful article …. and the best part is “Real life examples” …… :)

#17 subhashini

Awesome… I love the real life examples… will help me explain something in interview… Thanks

#18 Rajahmix

Wooow your post is truly addressing the challenges we facing as testers, either we overlooked the functional spec or we did not provided proper details about the burg for the developer to understand it. Thank you this is great

#19 Vineeth VP

Very useful information. Keep it up !!!

#20 gaurav

Gr8…Thanks for sharing

#21 Rebecca Pervin

very very helpful…..

#22 Harish Padaki

Excellent Article.

Almost 90% of the times there are the reasons for the Bug rejections.

Very True.

#23 Piyush Prakash

Hi

I am not agree with the 9th point basically Improper bug description. If developers are not able to understand the description, they can change the BUG status as a Information Needed they can not simply reject the BUG, they can ask for more clear information or any other supporting documents.

#24 Piyush Prakash

Please don’t mind about my comment

#25 jaya

I do agree with piyush…if they cant understand ..its their understanding issues…sometime happens when tester do write steps badly,,,but this not comes in reject…you can have FEEDBACk option In your tracker…

Also i did not find enviromental issues rejects basis

Leave a Comment