Bugs are things that are wrong with the application. More precisely, a bug is something that the submitter thinks is wrong with the product. When you're training people to use FogBugz, it's important that you not scare them away from entering bugs. If you emphasize that bugs are for things that are actually wrong, you can set up a thought process among casual testers that goes like this: "Gosh, that looks like a bug to me. Maybe I should report it. But I haven't read the product spec. This is my first day working with the program. Maybe it's supposed to work that way. I'll wait. I can always report it later if I find out for sure it's a bug."

The end result of this sort of thinking is that the bug never gets entered—and therefore never gets resolved. Remember, developers can only resolve bugs that they know about. You should let your testers know that when in doubt, they should open a bug. It's a lot easier for the program manager to close off a bug as By Design than it is for them to deduce the existence of a rare bug that they were never told about.

0 0

Post a comment