I’m fed up of being told that a bug or usability issue I’ve found is ‘vanilla functionality’.

Wherever I’ve worked, when this situation has cropped up, the only reason development has been done and testing is needed, is because we didn’t order vanilla!

For those not familiar with the jargon, the term vanilla refers to plain and unaltered, the ‘original’ state of the software before your particular flavour of enhancements and modifications are added.

An example would be some generic software that creates invoices. The first change you’d be likely to make would be to add your own company logo. The rest of the software would then be vanilla. Later on you might want to add a facility to specify a discount, say 5% to apply to resellers.

Now, say I’m testing this software. My focus is on the logo and the presence of the reseller discount when appropriate. I’m not a computer running an automated test though, and if I spot a typo on the terms and conditions, or that the VAT rate isn’t right, then I’m going to flag it up as a defect.

On one hand, I can understand and appreciate the developers’ response; this has nothing to do with the change and so they can’t be held responsible for it. On the other hand, we’re all trying to produce the best work we can, in a usually hyper-competitive environment, so just occasionally I’d like the response to be ‘OK, let me see what I can do’.

We know that the flavour needed to be customised, that our company wanted strawberry ice cream as vanilla didn’t quite cut it. But if, when we taste the results of the strawberry recipe, the flavour is too sharp, we shouldn’t be against the general principle of adding a little more sugar.

Advertisements