Opinion Management System

February 14, 2012

Opinion Management System

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.

Rahul Verma

Software Testing

Anti-Boxing, Bug Management System, Bugs, Software Testing, Tester Psychology, Testing Experience

7 responses to “Opinion Management System”

Rahul Gupta

February 14, 2012

Good thought Rahul, I agree to some points and disagree on others.
Here are my thoughts.

“Opinion Management System” ?

o·pin·ion/əˈpinyən/
Noun:
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?

LikeLike

Reply
Rahul Verma

February 14, 2012

@Rahul,

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.

LikeLike

Reply
1. Rahul Gupta
  
  February 14, 2012
  
  @Rahul,
  Thanks for the quick reply.
  
  I myself met you once during GTAC’10 at Hyderbad and we never get to discuss Bug Metrics as a base of performance management. I may be wrong and I can only say that I have been fortunate enough not to work for such immature organizations (& management) which measures performance on bug raised.
  
  I agree that such things do spoil tester/ developer relationship but don’t you think that we are also part of the problem…in some ways? In my little over 6 years of work exp. I myself confronted (debated) so many people who had been blindly following ISEB/ISTQB/CMMI but when questioned they couldn’t justify their beliefs.
  You mentioned “Management loves numbers. Bug management systems provide a lot of them. ” Isn’t it our responsibility to educate management on some of the things?
  
  “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! ”
  If you think that it would be helpful to have OMS…than why don’t you create one? Probably it would help me and many others to understand the message. Only thing I am afraid is, the management would then start measuring performance based on Opinions raised :p.
  
  If you or anybody else is working for such Org/Management….they need to change (either org or the management).
  
  Note- I am not a good writer so please forgive me if anything said is not professionally correct.
  
  LikeLike
  
  Reply
  1. Rahul Verma
    
    February 14, 2012
    
    @Rahul,
    
    The theme of the GTAC was “Testability”. If the theme were on the test management issues, the bad state of software testing, we would have seen the magic. The conference also had invited chosen set of people who are actively contributing to the community.
    
    I’d like to extend an invitation to you to attend the Bangalore Testers Monthly meet, and I’d like you see the practical nature of this problem across companies.
    
    I don’t disagree to your point w.r.t. educating the people who fall into the trap into such misleading measurements. And I trust that I know various people in the industry who do that. It takes courage to question the person who is going to do your salary appraisal and there are a lot of softer aspects to the way this must be handled. So, the question is not what should be done. That’s the subject of a motivation topic. I do a lot of such talks in addition of practicing this for myself. The question is how many testers do you see around yourself doing that? So, the problem persists.
    
    I guess w.r.t. the OMS, I should have put a lot of smilies/symbols to indicate where I meant satire rather than seriousness. The creation of OMS is a satire on the bug management systems. I’ve tried to sum it up in the end – “We could have ofcourse used the bug management systems in the right manner but the history proves otherwise”. So, the message is clear. Use your existing bug management systems in the right manner.
    
    LikeLike
Joe Strazzere

February 14, 2012

If your company has the cultural issues you mentioned (corresponding bug too often marked as “As-Designed”/”Invalid”, Tester/Developer emotion, evaluating the performance of testers and developers based on bug count, etc) then changing the name of your Bug Tracking System to an Opinion Tracking System won’t solve these problems.

Attack problems directly, rather than trying to be cute with names. You could call them “Opinions” or “Feelings” or “Hunches” – they are still bugs.

LikeLike

Reply
1. Rahul Gupta
  
  February 14, 2012
  
  @Joe,
  
  You said what I was trying to say. Thanks for your comments.
  
  Thanks,
  Rahul Gupta
  
  LikeLike
  
  Reply
Rahul Verma

February 14, 2012

@Joe,

Thanks for sharing of your thoughts.

First of all, treating a company as one unit is fine in some contexts and not in some others. For all practical reasons, all big companies are infact sets of companies, which vary hugely in terms of employee satisfaction levels, the developer-tester relationships etc.

I am not referring to my current team when I wrote this article. Can I vouch for all teams in my current company? – that would be over-generalization. The test manager role is a very important one and many a times, the person executing this role affects the way these aspects are handled. I’m lucky to be working with a great manager at present, though I wasn’t as lucky for some occasions earlier.

Coming back to the opinion management system. As expressed in my reply to a previous comment, the purpose of this post is not the creation of another system. The name – “opinion management system” in itself sounds funny rather than cute. The purpose of the post is to highlight how we are using the bug management platforms.

I choose to disagree with the last point in your comment. Every record that goes into the bug management system is not a bug. That’s the reason such a system has to introduce so many states for the same, including the ones mentioned in the post and quoted by you. On the other side, the system fails to capture the opinions of testers, because there is a hesitation in logging as the model of BMS forces named states. The rejection states are not taken up in a healthy way by the test management guys. I hope that you understand that I’m not talking about just one BMS.

There’s another thing in your comment which came as a surprise to me. It’s the part where you ask/suggest – if developer/tester emotion is a problem with my company… The emotional conflicts between developers and testers are more common than this phrase suggests. I’m representing a big problem that the industry faces in this blog post, and not a reflection on the current development team with which I’ve been dealing with (infact I have talked about dev/tester relationships in our team as a role model for others in various forums).

The subtle message I’m attempting ( and possibly failed at delivering atleast to you ) to pass here is that there must be openness in teams w.r.t. to expression of opinions. The process of measuring too much and using metrics kills this and should be done in a careful manner.

Moreover, I’ve begun to believe that test reports which involve free expression of view points about the software are more useful than logging bugs for everything. The tracking system should be used only for items for which the team (dev+testing) have agreed to take actions.

LikeLike

Reply

Rahul Verma: My Petty Bits