Edible versions

All you QA people out there -

• How often does your QA group “choke” on versions delivered by the development group?
• Are you used to “unedible” versions which just don’t taste right?
• How about versions which simply come as a blackbox where you have no idea what changed, therefore no idea what to do with the version, what to expect of it?

Now all of you DEV people - think about the times where you installed 3rd party products/updates which caused you the same digestion problems…

Those unedible deliveries cause a variety of problems. Lets start with the fact that whoever gets the delivery wastes a lost of time chewing it up, in the meantime not only delaying coverage of the new delivery but also NOT making progress on previous deliveries (the classic question of when to commit your QA organization to a new build delivered by R&D; and risk coverage progress for the earlier but known build. Especially tasteful when delivered to your plate a few hours before the weekend)

When the contents are unclear, QA people can only do general coverage, and the time it takes to verify regression concerns and make sure whatever we intended to fix was indeed fixed grows longer.

What is the point here? same as a sane person would refuse to swallow unmarked pills coming from unmarked bottles, refuse to take a version/build/delivery that is not documented sufficiently. I’m not aware of many good reasons not to mandate Internal release notes.

And DEV guys - consider some dogfooding on each delivery, even if its “just” to the friendly QA people next door. Lots of work you say? Well then, time to introduce Continuous Integration and Smoke Testing…