So we’re coding away – as you do – on our lovely new product (Blatant Plug : Exchange Server Archiver). Things are going well code monkeys are ooking nicely, testers are being evil as only they know how.

Now I’m all for thoroughly tested products, things weren’t always this way and I remember when I started working with full-time testers and took every bug as a personal insult. Afterwards I came to realise that we’re all working to get the best product we possibly can in the time available out the punters.

OK, back to the story. A bug was raised, this is a good thing, let’s have a look what have the testers done now.

Hmmm.

What.

What!

Let me get this straight you started the archive service, it wrote an XML configuration file out to a directory. Things are going well so far. We have a running service and a config file. You then, whilst the service was running, after it successfully saved the config file, removed the write access to the location where it saved the XML file. It carried on running, but no, that wasn’t enough for you – you had to go and make a change, prompting the archive service to try to save it’s XML config file again, it knows it has write access, it just did it when it started up, yet funnily enough it now fails.

Now I don’t argue that technically this is a bug, but really, I mean, is this actually ever going to happen in the real world. My argument was no and I wanted to close the bug as “NotABug” but the tester wouldn’t budge. I brought the test lead in, they wouldn’t budge. I brought in a tester from another team. Still no. At which point I admitted defeat and set the bug to “Future” instead.

Now opinions wanted – is this a bug or should I be allowed to close it as “Won’t Fix”?

If there is no consensus there may have to be a paint ball battle to solve this thorny problem.

This post has been brought to you with 🙂 placed wherever you feel like in the text.