There are two types of known bugs in the world. The “official” known bugs – those that are known to the Head of QA and the Head of Development – and the “unofficial” known bugs, those that are known to the programmer who put them in the code, and him alone. Usually, these unofficial known bugs are only in this world for one or two days, until the programmer fixes them; I therefore call them the Day-to-Day Bugs.
The problem with both these kinds of bugs is that they’re not known to the people that are most likely to run into them – the testers.
The day-to-day bugs are unique in that they’re often known only to the programmer who created them. The problem is that a compilation – or even a few compilations – might be performed with the bug still in existence, and those compilations are given to the testers. If they run into the bug, they will spend some precious time causing a bit of a mess: they’ll investigate the bug, report it and feel triumphant; but the bug will travel to one of the programmers, not necessarily the one who created it, knows about it and is quite likely already working on fixing it.
So we have a tester wasting time reporting known bugs, and two programmers working on fixing the same thing without knowing about the other’s involvement. This clearly is of no use to anyone. The answer is that we need some sort of mechanism in place by which programmers inform everyone of a bug that will be in the following few compilations.
E-mails work just great – unless you have a lot of modules and compile very often, in which case you’ll be bombarded with day-to-day bug reports. Better than e-mails, then, are an updatable page on the company’s internal site, an Excel file or even a database, if your DBA is willing to soil his precious servers with your bug lists. Ideally, everyone should post to this list, or send an e-mail, the moment they realize their bug is going to be around come compilation time.
Few things are as frustrating as spending a couple of hours investigating something only to have your bug report returned with a “known bug” stamp. If it were known, you’ll rightfully ask, why wasn’t I informed? There’s really no excuse for not maintaining a list of known bugs. This will help programmers cruising around relevant areas of code, and will certainly help testers wasting their time reinvestigating a bug someone else already found.
For official bugs I recommend avoiding e-mails at all costs – although official bug lists are not updated as often as day-to-day bugs are, they’re updated often enough and are, to begin with, large enough to make e-mails messy.
How to Structure and Maintain your Lists
The easiest solution is to structure your list the same way your testing environment is structured. Do you have a whole lot of modules under a single version tree? Do you have a whole lot of versions under a single module tree? Whatever your work structure, your list structure should mimic it as closely as possible. This will make posting and searching for bugs intuitive.
One thing you have to stay on top of is bugs that are carried over from version to version. You’re on version 5. You find a bug, report it. This bug won’t be fixed until version 8. Will your list for versions 6 and 7 have the bug, or will you leave it in version 5? Although it’s of course possible to go read all previous versions’ bug lists every time you’re looking for a bug, it’s both messy and dangerous – you’re likely to delete version 5’s bug list when you decide you no longer support that version.
The same care should be given to bugs that can show up in more than one module – don’t list them just in the module you happened to discover them in, because it’s unlikely that if someone else runs into them in other modules he’ll read your module’s bug lists before reporting the bug. If you have a joint infrastructure for all (or most) modules, it’s best to have Infrastructure listed as its own module, and list the bug there, where it’s assumed to effect all modules unless otherwise specified.
A significant problem is with removing bugs – people often forget to. This isn’t bad just because it creates a list the size of Texas; it’s bad because a tester reading through these bugs might find an old bug, similar to what he’s about to report. Now he won’t report this bug, thinking it’s a known issue – but this bug was already fixed, and if he’s encountered it again, that is a real problem in your software that’s about to be ignored.
This won’t solve all your problems, of course – these bug listings are very short and often don’t cover the whole range of possible effects for each bug; but at the very least it will help point your tester in the direction of the right programmer when he encounters an odd behavior, and will spare him some time investigating funky behavior ten other people had already noticed.
P.S.: your technical writers might be able to help you, both in understanding how to structure your lists, and in understanding how to explain a bug in twitter-length entries.