Movie tickets and bugs in agile
Submitted by Erik Petersen on Sun, 24/12/2006 - 04:21.
bug tracking/incident management | context-driven testing | development methodology | extreme programming (XP) | general software testing | perspectives | test approaches
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?
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?