Movie tickets and bugs in agile

I've been thinking about the way agilistas handle bugs recently. Several years ago, I was the editor of an internal IT newsletter for a large Australian financial organisation. Every month, I'd include a critical thinking puzzle, and I select a correct entry to win 2 movie tickets. I was able to give these out to my Australian readers, but I used to get some entries from our Indian IT shop as well. I arranged to have them win 2 movie tickets as well, if they were chosen as the winner. I thought this was a comparable prize, then I discovered that movie tickets are very cheap in India. In Australia, the prize would pay for a weeks public transport, but in India it would be only a day or two.
This difference in value is the thing that concerns me most with agile approaches. I've been reviewing some material in a book draft by Jim Shore and Chromatic recently, and its focussed my thinking on this. Bugs are important things to testers, and we need to get them fixed, we need to have a guaranteed fix rate every release. Agile methods (esp. XP) lumps bugs in the general feature bucket, and if new features are seen as being more important, then the bugs wont get fixed. In fact, the XP fixation with velocity sees bug fixes as evil things that slow down the rapid introduction of new features. Well, that may be true but bugs need to be fixed, and if they are hiding other bugs, then surely they are more important than new features.

Another value issue relates to agile developers believing that they find all bugs, and system testing is only needed in exceptional circumstances. Jim and Chromatic (and Ron Jeffries) are all now acknowledging the power of exploratory testing in assisting agile development (after I've been ranting from my soapbox), but there still seems to be this belief that developer testing (at a component and component-integration level) will find all behavioural system level bugs, and system testing is only needed when the devs muck up. I'm trying hard to push this point but it seems to be a hard one to make.....
Any suggestions?

Comments

In fact, the XP fixation with velocity sees bug fixes as evil things that slow down the rapid introduction of new features. Well, that may be true but bugs need to be fixed, and if they are hiding other bugs, then surely they are more important than new features.

Where did you get this from? In your previous sentence you get it right.

Agile methods lump bugs in the general feature bucket, and if new features are seen as being more important, then the bugs wont get fixed.

Some bugs never need to be fixed. I know that is hard to hear as a tester but it is true. Some features will never get implemented and that is fine as well. Agile methods are about having the flexibility
and freedom to continually re-prioritize and change directions.

I would be interested in your thoughts on Shore's chapter called No Bugs. I find the idea a little hard to fathom, but admire it as a goal. It is also a bit of a misnomer - it should be no bugs logged, because many are fixed immediately.

Anyway, good site, love the posts.

Ben,
Sorry about the massive delay replying. My context has typically been semi-agile projects that have massive lists of requirements to get thru, and bug fixes could jeopardize the projected completion date. In retrospect, they should have built slack in to each iteration to handle it. I am typically talking about bugs that need to be fixed but being pushed into later iterations, and hiding other bugs that cant be investigated.
I did a very big review of No Bugs, posted privately to him as the marked up chapter. My noises led to them extending their ideas about exploratory testing. I an reticent about the no bugs concept, as bug information tells us where bugs clusters are which is the main area to test. Also tracking bugs helps speed up bug fixes if they re-occur. You may have an automated test to detect the bug occuring again, but doesn't it make sense to keep a record of the fix? Without tracking bugs, this info is lost. Lisa Crispin is writing an article for Better Software about this....

Erik Petersen
www.testingspot.net