Tuesday, March 11, 2008

works as designed

You definitely heard this one, developers use it as a reason for closing bugs, you even used it yourself. It sounds perfectly natural, at least to me, the developer. I bet testers hate it. 3 simple words to close a bug with.

And now I'm questioning if the construct is correct. How much sense does design make to a tester? And considering that some teams have this open policy where clients can see all the product bugs, how much sense does design make to a client?

To find out the answer, try this: in UAT, go to your client and tell her that the bug she thinks she found is actually the behavior as designed. Don't be surprised if she asks you What design? Now if you are smart you'd shut up and go check the spec that she counter-signed, if you are not-so-smart (read stupid or inexperienced) you'd say: What design?! The UML class design, the interaction and ORM diagrams!
By now the smart reader noticed that the works as designed construct is flawed. If this is the case, then my proof worked as specified.

P.S. If I were the client, I'd only sign contracts that say the software vendor must ship works as intended software.

1 comment:

John Torjo said...

I do agree that "works as designed" should actually be "works as specified".

However, about being the client and signing contracts that state "work as intended" is a really bad idea for you, the developer. Just think - the client, even if he received exactly what he wants, he can still say "It doesn't work as intended".

It's too vague - at least for me. So, it's the client's job to make sure "works as intented" is actually "works according to specs". You can help though ;)

Best,
John