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.