Jonathans Virtual Bugs
http://www.kohl.ca/blog/archives/000066.html
"As a tester, what do I do with the bugs we discovered but couldn't get the unit tests finished for"
"On small teams, I will keep a running tab in my notes of these bugs...This doesn't scale well though."
In general, we view bugs as part of the progression of the story. It can take several passes to get a story and all its interactions correct. The specification may be wrong, the implementation may be wrong, even the testing may be wrong. It takes time to hammer a story into shape.
Bugs are simply cards that clarify the story or tests. Most importantly, it is no ones fault.
We differentiate our bugs from our stories by using green bug cards instead of yellow story cards - they are easily written on, modified, attached to stories or thrown out. They can contain hints for testers (about virtual bugs), or feedback to developers. We find paper much more versatile, organized and personal than computers at tracking this stuff.
posted by Ted O'Grady at 11:58 a.m.
1 Comments:
On the XP team I've been working on, we do the same thing with logging bugs as story cards. They are recorded on pink cards. We put stickers on them (green when it passes, red if it fails), and put notes on the back etc.
When we find bugs at a faster rate than the code is being developed for the stories, at a certain point this can cause too much drag on development productivity. We end up with some of these left over at the end of the story. What I gather is you absorb these into the bugs found after the story is developed.
What I like about this approach is it prevents the two classes of bugs emerging. I like the idea of "view[ing] bugs as part of the progression of the story". Thanks for the post.
-Jonathan
Post a Comment
<< Home