This post is in more of a notes style than my previous ones. I was originally planning on making this more prose-like, but I’m not going to after all. I kind of like the way it reads now. Maybe it’ll lead to more questions, but I’m going to call it a blogging experiment. 🙂
Cem raised a question of metrics in XP and how the perceived lack of metrics can lead to some testers flipping their “bozo bits” on XP
Mike -> some teams do, question of personal actuals (for performance reviews) vs. knowledge of peoples’ skills gained from pairing
Jeremy -> A project’s goal should be to have zero bugs. Don’t have thresholds of “okayness” since the bugs below that threshold may be hiding other bugs.
Cem -> “OK, as long as you’re not doing maintenance” — depends on whether project started immediately fixing bugs or you’re dealing with legacy code that comes with a backlog of bugs.
James -> a dedicated testing staff *will* create bug backlog, plus there’ll be controversial bugs that can’t be immediately fixed until something is resolved (possibly needing conflict resolution between two stakeholders or other similarly time consuming processes)
Mike -> key thing you want to know is injection rate from developers
James -> one thing that is a big problem: Projects ship with open bugs (bugs for which no decision has been made), therefore Borland had policy when James was there of “always ship with 0 unresolved bugs” (a resolution may be to decide not to fix it)
Cem -> different kind of backlog that you might run into with some more experienced testers -> high volume test automation (use computer to generate lots of tests) finds complex bugs (stack overflows, pointer problems, etc.) that take a long time to troubleshoot. Cem created new category for tracking these defects (called Dumpster, used to avoid metrics counts that penalized the team for leaving a bug open) used for defects that were hard to reproduce/troubleshoot. Every week, one programmer and one tester would go “dumpster diving” and try to find patterns. Thus, there are some situations in which a backlog is fundamentally necessary (to get the patterns to fix the complex bugs).