A lot of times, what is logged as a bug by a tester is usually an opinion. A tester observes the behavior of the subject and feels something is not right. On further analysis, s/he develops on the idea and forms an opinion about the behavior or atleast has a set of questions about the behavior which when answered could throw more light on whether there is a problem or not.
Requirements ( which are often misinterpreted as document(s) ) , design and other specifications are considered as the reference points instead of being considered as targets of testing. So, if a tester thinks something is wrong but the current behavior matches these reference points, the corresponding bug is often marked as “As-Designed”/”Invalid”. The only way available is for the tester to log it as a change request or a feature modification request, which is often logged with the severity and priority level of 10000.
The problem is not confined to just the management aspect or the bug life cycle. There is another life cycle which runs in parallel to a bug lifecycle – Tester/Developer emotion lifecycle. If the severity of the bug is reduced, or if it is marked in any state apart from the ones that indicates that the developer is going to consider it for fixing, the negative emotions in the tester get triggered. If a tester reopens a bug or there is a disagreement for severity and whether it should be considered a problem or not, the developer emotions go towards the negative axis.
Another thing which further adds to the fire is that bug management systems are used to extract bug logging data for testers so that the same can be used to evaluate their performance. This further puts the pressure on testers to go to extremes to save their bugs ( rather than sell what is useful ). The developers are also assessed similarly with respect to how many bugs were logged against the areas for which they are responsible and they would like to reduce the numbers, reduce priorities,
Overall, the bug management systems have become more of a battleground rather than just a tracker system for software issues (or not). They sometimes also act as a tennis court where the players want the ball in the other’s court at the earliest, with as much force as possible and think they should earn extra points if the ball manages to break a nose ( let’s leave other funny areas ). The sportsmanship is ofcourse missing in the game.
Wouldn’t it be nice to either rename the existing bug management system or put one in parallel under the name “Opinion Management System“? After all, no one can mark my opinion about the software behavior as “As-Designed”, “Will-Not-Fix”, “Not-Reproducible” etc. Also the management would not be able to measure testers based on number of opinions expressed, the developers would not be judged based on how many opinions have been expressed for their areas. An opinion just helps in building the argument, can be answered with a contrasting opinion. It does not have a severity / priority.
If a decision about whether there is an agreement about an opinion and what actions need to be taken, is arrived at, then it can be tracked in the bug management system.
We could have ofcourse used the bug management systems in the right manner but the history proves otherwise.
What’s you opinion?
Edit: If you have missed the satire ( dark humor ) part of my post, please read it again. You might have missed the message.
Good thought Rahul, I agree to some points and disagree on others.
Here are my thoughts.
“Opinion Management System” ?
1. A view or judgment formed about something, not necessarily based on fact or knowledge.
2. The beliefs or views of a large number or majority of people about a particular thing.
So opinions are not based on facts otherwise it would not be called opinion. Why to raise something which can not be measured? And if everybody starts raising opinion than Timeline will go for a toss and product will never be shipped(?)
I am not sure what all companies you referred to where number of bugs are taken as a measure of tester’s performance, at least I’ve never heard of any such organizations. If that kind of Performance Management (appraisal system) is in place….than the problem is bigger than defining an O.M.S. its a Management problem also.
It’s a tester’s responsibility to present a clear picture before management and educate them and that would need open & honest communication.Sounds good?
Bug metrics for performance measurements, rather than an exception, are used by most of the companies. It’s pleasant surprise that you haven’t heard about them because throughout the last 5 years of my participation across conferences and meetups with hundreds of testers, this was one of the common discussion points.
By opinion, I mean the first definition quoted by you, as it conveys that the opinion may or may not be based on facts/knowledge. The facts/knowledge in the bugs context are often the reference points in the form of requirements/design docs & specifications, functional specifications etc. The moment a tester raises a bug which goes against these, the bug is not dealt with the same respect and focus. This is especially problematic with companies which focus more on processes.
Now let’s go back to the message. Do I really want an OMS created? Do I really want the BMS to be renamed? Well, I would like to see if someone does that! The purpose of this post is rather subtle. I want to pass a message on how we deal with bugs. And how this approach has spoilt the basic relationship between development and testing teams. A platform which is supposed to provide information about issues about the software and having healthy discussions, has become a war zone, a platform to find scapegoats, a platform where everyone tries to get rid of the responsibility of holding the current control and would like the bug to be in a stage that lies with someone else beyond the button click.
Management loves numbers. Bug management systems provide a lot of them. The same numbers can help in indicating the health of the software, but the management, more often than not, takes it one step further. They want to check the health of software testers and how much they should get in terms of salary hikes based on these.