My last posting in the Defect Tracking Patterns series is not really another pattern, but instead a discussion of loose ends and other oddities that don't fit elsewhere.
Capture Bugs With Tests
Simple advice: When you have a bug, write a failing test that demonstrates the bug. Write it before trying to fix the bug, and then add it to the test suite permanently. Then write the code that makes the test past. If that bug ever pops up again (that never happens, right?), the test will start failing again, immediately, before the rebugged code gets put into a release.
No Bug Database
From the XP world comes the idea that instead of having a list of the bugs that need fixing, capture the bugs as new or changed requirements, and have the customer prioritize them along with the ongoing development. There's some wisdom in that, because it helps the to remember that nothing is truly bug-free, and that making important features work well has more payback from a business standpoint than fix a lot of minor defects, and the team gets to estimate how long it will take to fix something and add that time to the overall schedule.
Thanks to everyone who commented on these, please do send me your comments, or visit the version on the wiki at DefectTrackingPatterns, and thanks especially to Brad Appleton and Linda Rising for their help with the early revisions.