Information Technology Dark Side

How I Find Problems in Software
I use a mnemonic called HICCUPPS* to help me find problems with applications I test. The idea is that as I test I look for anything that is inconsistent with:

• History of the product
• Image of the product
• Comparable products
• Claims about the product
• User expectations
• other features within the Product
• Purpose of the product
• Statutes that apply to the product

*Not my invention. Google it.

Not Every Problem is a Bug
I have a tendency to enter any problem I find as a bug. There are lots of reasons for this, including:

• Users tend to think everything they don’t like is a bug, which translates into pressure for me
• Bugs seem less likely to be ignored than feature requests (stories) from a tester
• I don’t have to think about it if I just call it a bug
• I often can’t remember what stories have already been implemented and I’m too indifferent too do research to figure out if something was defined in a story or not before I call it a bug
• Part of me just doesn’t care. “It needs to be fixed whether you see it as a bug or a story”

This creates a tension between me and the devs because they look at a bug like “such and such list should be sortable on column headers” and they rightly call it new development. For lots of testers, this could become a regular argument. Lately, I’ve just been saying something like this:

You’re right. Change it to a story.

Be Wrong

I’m motivated here by a couple of things. First of all, I try to cultivate a belief in myself and others that being wrong is no big deal. One of the ways you do that is by practicing being wrong. In a situation where there is no compelling evidence that I am right other than I just want to be, I try to assume I am wrong when my peers disagree. The ability to acknowledge possible faultiness in your own smartiness is a key factor in having healthy relationships.

Testing Adds Value
Another reason I have become more liberal about logging problems as stories is to demonstrate the value that testing brings to the application. You see, the way we estimate development, the estimates are an expression both of cost and value. So, if I, through testing, create 20 points worth of new development in a given iteration, I have made it possible to add 20 points of value to the product. That’s kind of cool to be able to articulate the value created by testing in metrics beyond bugs found and bugs fixed.

Quality Has a Cost
Bugs aren’t pointed in our approach. This is because if it really is a bug, we already got credit for it when we shipped the feature I found it in. In other words, we probably should have found it when we built it, so getting points for fixing it is double dipping.

Stories, when they really are stories and not bugs, do get points. They have a cost. Pointing stories found through testing makes it easier to prioritize them. An eight point story that addresses a purely cosmetic issue is probably going to be prioritized lower than a 2 point story that addresses a functional one.

Knowing the cost of a story helps me avoid getting wrapped around the axle with some issue I think is mission critical but really doesn’t matter much in the grand scheme of things. It helps me put it in the context of the entire development flow and see it relative to all the other things we need to do.

Be a Liberal Story Writer
Don’t get bent about some problem you found being a bug or a story. If you suspect it might be a story, or your colleagues feel it’s new development, log it as a story. Don’t sweat it much. I’ve seen testers get absolutely irate about this, and developers too. Ironically, I’ve seen irate testers also say what I said above : “It needs to be fixed whether you see it as a bug or a story”, all the while making the case for its buggishness. Don’t do that. Err on the side of points if there is a chance you are wrong and trust in your team’s ability to refine the accuracy and criteria of such judgments over time.

Have a nice day.

Dave

Stumble it!