Differentiating between bug and feature - more often than not is a result of someone (typically a developer or a tester) trying to prove some other person (typically again a developer or a tester)wrong. Somebody says "See this seems to be a bug to me - I trying to be like typical end user" where as somebody yells back "Look this is as per this document and no where it is mentioned that the feature should work like this".
In simple words, the difference between bug and a feature OR "Desirable" and "Undesirable" OR "Expected" an "Not Expected” - is with respect to some REFERENCE. What is that reference? Who defined it? How credible is it? The moment all the concerned parties and entities involved in Bug-or-Feature conflict agree upon this Reference - the distinction becomes very very clear.
In most of the cases - requirements document, market survey or some expert opinion is considered to be the reference. The confusion in most of times is because of lack of reference (Oracle) and still worse the lack of knowledge that “there is no Oracle".
If I find myself in such situation - I simply say "This is my observation on this feature. I think we should analyze and explore to see if anything wrong here. I would be happy to participate in this exploration. I would not get into issue of whether it is a bug or feature - I am not the right person to decide that. I only report on observations that I make with respect the features I test.
so next time when you hear an argument like this --- Just ask this question - "Can all of us first agree upon the reference?". I bet, you would sound lot intelligent in the crowd ....
Shrini
5 comments:
Hi,
I'm a professional tester and I must say I don't agree with main point of view: I think What distinguishes a bug from a feature is a matter of correctness, and not if it is "Desirable" or "Expected".
Many times what is correct is not expected, not desirable, not user friendly, etc, but it is not a bug. We may decide to NOT fix some bug, after evaluate the risk or other factors, so it turns into a bug-feature. It is not correct, and we know it, but it will remain like this.
In my 6 years of testing I have had lots of discussions with developers like "That's a bug!", and I found lots of "tricky" issues, but I always know what is correct, at least in my point of view. And I know that they also know!
I maybe wrong but always taking the "let me bow down because i don;t want to get into a hassel" approach create frustration? It almost sounds like being too meek to express your opinion when you say I am not the right person to call this a bug. You are a tester, and if you won't call a thing a bug, no one ever will.
very true shrini..and the biggest pblm noone bothers if you tell like this and the issue just slips off as the top mgmt is intrested to just reduce the number of SPRs by somehow and at the end of the end they lose the quality of the product.
and when there is ny production defect, they will yell back to the testing team tht the testing is not done properly..do they think testers have 10 hands to do functional,regression testing, develop automation scripts and maintain and run them...
these managers ahve gone crazy
It looks like a good approach to me, Shrini. "Correctness" is often not easy to tell, and besides that, it's irrelevant. If the people who control quality like the way the product works, then it is correct by definition.
The role of a tester is to effectively reveal information about the product, not to be a little preacher thumping on a requirements bible.
It does make sense to take the best interests of your clients to heart, and to construct the best arguments you can for persuading them if you feel they do not fully understand how their interests are being threatened. But in the end, testing is not about your own opinion. It's about service to opinions of others.
A professional tester, I would say, is neither judge nor jury, but rather a defending attorney, raising questions and evidence.
Hi Srini,
Thanks for pointing me to this post in the first place. Your views are nice and i prefer this as one of the good approach to handle this kind of debates.
But then, things may not be that smooth or simple in all the scenarios.
I work for a product development company and most of the requirements will be captured by the Sales / Architecture / Management Team with some inputs from the Customers.
Here the requirement is not specific to a customer and the big problem as i said earlier is the Clarity on the requirements itself.
In product development, there will be different customers and see all these requirements won't come in from them.
As i said in my post
That's Expected Behavior and Not a Bug
The root cause for most of the scenarios from my perspective are that
1. Clarity on the requirements across the teams (Management / Sales / Arch / Dev / Testing)
2. Attributing the Technical Limitations to the Requirements and not disclosing the same
3. Not coming up with the required documents that will clarify the ambiguities
4. Lack of understanding on how the Systems behave in general ( Take a step up and see how this should behave in the real time )
5. Taking things personally instead of understanding the system
Post a Comment