Laws of Software Development

Gerald M. Weinberg has two books Secrets of Consulting and More Secrets of Consulting that have a number of guides, rules of thumb, advice, rubrics, and so on. I found these immensely helpful. At the same time I am reluctant to use the term ‘law’ (as in Newton’s laws) – because ‘law’ implies that the idea is /always right/. Still, there are a few things I have seen enough times in a row to classify as dang strong bits of advice(*), and a “law of software testing” has a nice ring to it.

So, after years of doing test automation, after speaking at large conferences about it, consulting on it, running events and getting a broad and deep consensus from the community, Here is Heusser’s last law of test automation:

“Despite all your automation awesomeness, with you automated build and build verification hooked into your CI and FITnesse and sellenium and automatic deploy and deployment-notification emails … before you send those notification emails to that distribution list, you probably want to have a human being poke and it and make sure it’s ok.

Just trust me on this one. Or don’t; your call.”

That’s my last law. I suppose I should go find the first few. 🙂

–heusser
(*) – Yes, I am a card-carrying member of the context-driven school of software testing (www.context-driven-testing.com) – so I am a part of a community the essentially censures the term “best practice.” For nearly any “best practice”, I can find examples where you might /not/ want to do it. And, when it comes to finding absolute things that are always true on every project, the few I can come up with are in the area of “brush your teeth and wear deodorant.”

This latest bru-ha-ha on the intarwebs about context-driven could be better?

That’s tomorrow’s post, bub.