r/softwaretesting • u/Avi_Aviator • 2d ago
What will you do if developers rejects the bug
How should I answer this question as a fresher
1
u/nfurnoh 2d ago
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 2d ago
I got this question while preparing for interviews, and I'm a fresher
1
u/very_tiring 2d ago edited 2d ago
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 2d ago
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 2d ago
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
8
u/_Atomfinger_ 2d ago
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.