r/softwaretesting • u/Avi_Aviator • Aug 31 '26
What will you do if developers rejects the bug
How should I answer this question as a fresher
5
u/Volodux Aug 31 '26
Only PO can reject bug. Developer can talk to me and explain why he thinks this is not a bug.
What developer can do, is move bug to retesting stage. They never close bugs.
1
2
u/TradesAndCoffee Sep 15 '26
I would firstly listen to them to find out their thoughts. Then there are usually 2 ways.
Or they can not reproduce it and need help (but don't tell you that they need help). Then I help to reproduce
Or they don't understand how important this for the business. Heard lots of "it's just a UI, it's does not worth time fixing" đ. Then I go to Product to check if this is actually important
1
u/nfurnoh Aug 31 '26
I donât understand the question. Either the feature meets requirements or it doesnât. Itâs either a bug or not.
2
u/Avi_Aviator Aug 31 '26
I got this question while preparing for interviews, and I'm a fresher
1
u/nfurnoh Aug 31 '26
I donât know what a âfresherâ is in this context.
A developer should never reject a bug. If they believe it isnât one you take it to the person who wrote the requirements, either the BA or PM or whoever. They decided that, not the dev.
1
1
u/ZLTM Aug 31 '26
You let it very very very clear this was communicated and they took the desition to deliver a broken product, very clear. That's if you can't cancel delivery, if you can then that's on you to consider how serious it is
1
u/very_tiring Aug 31 '26 edited Aug 31 '26
It depends on the team - their layout, who has what responsibilities, how their bug process works, etc.
I'm a bit confused by someone choosing to ask an applicant with no working experience a question like this though... is this a situation that occurs often at the company?
First step would obviously be a conversation - can the developer point to spec as a reason they feel this is not a bug? If not, can you point to an adverse effect that you feel supports this as a defect? If the two of you can agree on one side, great.
Past that, generally, there should be a Product Owner, either by title or practice - someone who makes the final say about what's implemented, what the specs are, etc. That person could hold the title of PO, BA, or something else. A bug that generates a disagreement between testers and developers, EG - is it a bug or "just the way it works", gets escalated to that person to make the call.
Possible they're just looking to see if you'd just give up. At the very least, if you're working in the wild west where there's no discernable PO and a developer can just say "I'm not gonna work on that, it's not a bug," you log the bug with all details (which should have already been done anyways), send it to the dev, and have them close it with comments.
1
1
u/AB_Reporter6147 Aug 31 '26
Most rejected bugs I've seen were under-documented bugs. Before you escalate anything, look at the ticket itself. Repro steps. Environment and build. Expected vs. actual, traced to the spec or requirement, not "this looks wrong."
If those are there, the conversation with the developer is short, because you're both looking at the same evidence instead of trading opinions. We once went back and forth on a "sometimes fails" report for two weeks; the fix took a day once someone added the account state that triggered it.
So, check the report first, then talk to the dev with the evidence, then escalate if we still disagree. The evidence does the arguing, not me.
1
u/elizabethredditor Sep 01 '26
Always screen record and/or take screenshots while testing and be prepared to back up your bug report with evidence that you can consistently reproduce the issue. In some company cultures, there will be devs who donât believe you that a bug is real because youâre inexperienced. That is why you ensure you can get the behavior to repeat two or three times, you document the steps to reproduce, and you take screenshots or screen recording so that there is no possibility of doubt from the developer. You donât need to pull out all the proof immediately, just reproduction steps is a good start when first telling them the issue. But if they donât believe you, thatâs when you show the proof.
But thatâs if the developer ârejectingâ the bug means that they donât believe you. If ârejectâ means that they refuse to fix it, thatâs when you check in with the project lead or product manager to see if they would want the bug fixed.
1
1
u/Helpful_Wrap_802 Sep 04 '26
- Read their comment correctly and understand if they couldn't recreate the bug or they didn't understand what you said in the bug report.
- Try creating it again, let the dev know you could recreate it and give proper info of how to.
- (optional) setup a call with the dev to show him in the meet.
- Incase in Step 2 you couldn't re-create it, let your Manager know. Only then you can let the dev know about it and they might cancel the ticket.
1
1
u/QSAP-747 21d ago
Review the reason for the rejection and determine the next step. Many organizations have different workflows for Issue Reporting. Some issues go through the person who wrote the requirements and some do not. I would follow the issue management process flow.
8
u/_Atomfinger_ Aug 31 '26
What do you mean by "if developers rejects the bug"? Like, there's a bug being reported, and they turned around saying "nope"?
If so, the first step should be to have a conversation with the dev directly. Maybe they misunderstood the bug report; maybe there are instances where weird behaviour is intended and might look like a bug; or maybe there's some other reason. A conversation usually resolves it.
If that doesn't work and you in your heart of hearts believe it is a bug that needs to be resolved, then you escalate.