It's late on a Friday, and you're about to go home. Suddenly, a new email appears in your box. It's a bug-tracker ticket: One that was closed two years ago.
What sorcery is this?
Necromancy! A Zombie Bug is any bug ticket that was previously worked on by a developer, verified to be fixed by the appropriate authorities, closed...
...and then resurrected from the dead.
Why does this happen?
1.) The system was the same.
The reporter remembers a bug in the same system, and suspects that this bug must be somehow related to the earlier bug.
2.) The symptoms were similar.
The reporter remembers a bug that had similar symptoms, and suspects that this bug must be the same bug.
3.) Search revealed an old ticket.
The reporter has been told many times to search the ticketing system before opening a new ticket. Upon finding a ticket that sounds very similar to the problem she is having, she adds her observations to that ticket, instead of opening a new one. You can't blame her: This is what she was trained to do.
4.) Someone may have been lazy.
Why go to all the trouble of opening a new ticket, when you can hijack an old one?
What's so bad about zombies?
1.) A ticket is a unit of work.
Many companies use their ticketing systems to keep track of worker productivity. How does it look if one of your tickets is suddenly two years overdue? If the ticket was Approved, then the work was done, and the ticket should remain closed, to reflect that.
2.) A ticket is a historical record.
Ideally, a bug ticket keeps track of the entire history of a bug, from the initial report to the final approval of the fix. If the fix was approved, then the bug presumably no longer existed, at the time of that approval. Therefore, if the symptoms are seen again, this is clearly a new bug, and should receive a new record.
3.) The reporter has incomplete knowledge.
A lot of bugs have similar symptoms. In most cases, the reporter has no way of knowing if this is the same bug.
4.) The details are important.
Zombie Bugs often lack critical details that a developer needs to fix a new problem, and may contain older details that are irrelevant to the current problem. This can lead to a lot of wasted time for everyone involved.
What to Do
We don't have to live with Zombie Bugs. Here are some things that we can do to put them down for good.
Maintain a "No Necromancy" policy for your team's bug tracker. If you catch your team raising the dead, let them know why this is bad. Tickets should only be re-opened if your team genuinely screwed up and approved something they shouldn't have.
Most modern ticketing systems provide a way for tickets to reference other tickets. If you think that a bug may be related to an existing, closed ticket, then simply make a reference to the other ticket. You should still make an effort to provide a detailed description of the bug you are observing. It may be a new bug, and the developer is going to need as much detail as possible to fix it.
Close all Zombie Bugs promptly, and gently explain why.