Many think testers have the power to declare something as a bug. This normally goes without saying. How about the inverse?
Should testers be given the power to declare something is NOT a bug?
Well…no, IMO. That sounds dangerous because what if the tester is wrong? I think many will agree with me. Michael Bolton asked the above question in response to a commenter on this post. It really gave me pause.
For me, it means maybe testers should not be given the power to run around declaring things as bugs either. They should instead raise the possibility that something may be a problem. Then I suppose they could raise the possibility something may not be a problem.
17 comments:
Subscribe to:
Post Comments (Atom)
RSS
This is a great question. I think in the end you are absolutely correct, and as a tester I can't think of a worse feeling knowing a bug made it to production because I didn't think it was worth reporting.
Declaring something a bug pretty much has to be a positive action, doesn’t it? You can’t declare something a bug and keep it to yourself.
But right or wrong, how often does a tester observe something not to spec, out of whack, unexpected and mumbles to self “Welllll, probably not really an issue because of X” and continue testing? Maybe for very good reason - e.g. the way something behaves is more consistent with what the rest of an application does. Of course in that case I raise an issue with the spec. But I’m picky like that.
I suppose another scenario would be when a bug is raised by another tester. Then tester B might have an issue with the bug that test A has raised. (Darn that tester B.)
I agree with what you are saying, but I think there are definitely exceptions. Ultimately it's the business who can say that something is not working like they want it to. HOWEVER there are times when there are obvious bugs. Mispellings (small, but still looks unprofessional), application errors, etc. - those types of things are definitely bugs.
I'm not sure the word should be 'Declare' but I think that testers are instrumental in presenting different viewpoints on whether things are bugs or not. They are instrumental in determining impact those things have on the system. I don't believe you should squash the need and value of conversations.
What does "declare something is a bug" mean? What does "declare something is not a bug" mean?
For me, if you find an issue, you write a bug report. That doesn't mean you've declared anything, other than that you think you have found a potential bug, and an issue that needs further investigation.
If "declare something is not a bug" implies "don't write a bug report, even though you think there is an issue needing further investigation", then I don't think anyone should be doing that.
To me the thoughts are similar to this discussion: http://www.allthingsquality.com/2010/04/non-reproducible-bugs.html
Testers declare something not a bug every time they successfuully execute a test. It's their main outcome.
Am I missing something?
Joe,
Good questions. "Declaring something is NOT a bug" would require something to be a bug in the first place. To some teams this simply means, logging something in the bug tracking system. If we start with that premise, should a tester have the power to delete something from the bug system? I would say no. Not without running it by the team first.
If one agrees, then shouldn't the inverse be true? The tester should NOT have the power to enter something in the bug tracking system.
Well said, Scott Ellis. That is my thinking too. And I think it is the point Michael Bolton was trying to make in his post. Far too often, we put our trust in a tester's declaration of a bug, and forget the conversation.
lisapollard, yes, good point. Maybe testers should only declare obvious bugs...
Yury, yes, you are missing something. I'm afraid it wasn't a very clear post, so, my fault.
I'm talking about a bug that the team has already exists. Maybe they have even decided to fix it. It is logged in a bug repository. It has a BugID. Should testers have the power to reject such a bug? No, right? Especially, if the team already decided they wanted to fix it.
you can define something as
1) a defect / Bug - obviously Contradicts the Acceptance criteria for a new piece of Functionality
2) User Experience / Functionality Stands but is a bad Flow --> the user has to do things which are outside agreed 'look and feel'
3) Question For Discussion - open for Design/user expierence/Developers and managers to Discuss an Issue - "wouldn't it be better doing it this Way?" type Questions and putting them into a list of possible Change Requests/Future Features = this would lead to TDD.
reject it after discussion if they can point to Requirements/Acceptance criteria which prove the Bug is raised in error.....
1. What is meant by obvious bugs? - If we think more critical, we might see and explore different bugs from different perspectives.
You meant to say: we should not raise them?
2. If tester raises a bug, and after posting in Bug reporting tool - Then after, discussion with other tester - he thinks: It cant be a bug (functional)
And Developer reporsts it as Not a Bug - Is it leads to testers credibility of not raising valid defects?
Srinivas, you asked, "are you saying testers should not raise bugs?"
Not entirely. I'm saying testers should be careful about how they raise bugs. Instead of assuming they have the power to log a bug report and have it show up somewhere as an official bug, maybe they should raise the issue informally first. That would cut down on the other problem you mentioned; testers losing credibility by logging rejected bugs.