Sometimes there are situations in my daily testing work, where I have to ask me:
Was this seemingly wrong behaviour of the SUT what I’ve found right now realy a bug? Should I raise it in the defect management or bugtracking tool? Sometimes it’s betther first to talk with stakeholders/developers before doing anything else…
What are the consequences when I will raise a defect right after I’ve seemingly found a bug?
Here are a few scenarios of what can happen:
Stakholder/dev team will say: „No, that’s no bug!. So we will sign it as a waste defect and never fix it!“ That sometimes happend when I find some bug’s „in the wild“ or during exploratory testing when no spec or user manual for the testobject exists. And then they often say: „It’s not a bug“ (and I think: They say it in that way, cos they’ve missed to write the correct behaviour down in spec/user manual!).
Stakeholder/dev team will say: „Maybee it’s a bug, but we have no time and resources to fix it – so we will waste it!“ (This is true story from my daily work).
I hate this scenario: Why can they say to „waste“ a defect/bug only when they not have the time or resources to fix it! In my opition it’s not a waste cos they already said „maybee it’s a bug“!
Or will they say: „Ok, youre right – it’s a bug. But we have no time and resources to fix it right now. So we will set the severity down and fix it maybee in a year!“
I think: It’s also not right to set the severity down only, when they don’t have the time or the resources to fix it right now. But on the other side I think: It’s not my job to control every single datafield of a raised defect/bug. And it’s also not my job to control, how the dev-team/stakeholder have to work with my found bugs! As a tester I can only make some suggestions about „how the SUT will work and won’t work“ or I can show them where are the „blind spots“ in the SUT and where might be problems when doing special scenarios in the SUT. I think: „Testing is a service for dev teams to help them to find problems when using the code they produce from the the point of view of a customer!“ And I also think: „Testing is NOT the job to controll the work of dev teams (coding, developement)!“ As a tester I don’t say: „Dear developer! To solve that problem, please use a for-loop instead of a while-loop! :-)“
So at the end I will say: „Ok, they confirm that that what I’ve found is a bug. But when they will set down the severity or do anithing else with the defect I raised: Who cares? When they need to do it – Why not. I don’t care!“
They might say: „When no customer will raise it, it’s not a bug!“ Then I will say: If they realy want to work in that way: Why not! I don’t care! I’m only that little of person who can make suggestions of what might run wrong. But it’s not my problem, that they don’t accept my offer! But I hate the concequences of this: Ofen I know, that at least one customer will raise that bug, what I’ve found ;-( and then I have the ungratefull job only to do the retest for the fix of a bug what actually I’ve found first and before the customer had found it!!!!
There are thousends and millions of scenarios more, what can be happen when seeminly find a bug and whe have to ask the question: Is it realy a bug and should I raise it in defect manamgent/ bugtracking tool?
I think there’s no true answer for the question wheter some behaviour in SUT is a bug or not. It’s highly depending on different contextes, of „how“ the concering dev team’s and there stakeholders work, if there are working instructions in your company and what they tell you about „bug“, if there are special deliveries for certain customers or not, if there is a specification and if it is up to date or not, and, and, and…
What’s your opinion about that all?
kind regards, Ralf