If you were a CIO ...

... What would your test policy be? Is an interesting question posed by Annie-Marie Charrett on the SoftwaretestingClub.com Site.

It turns out that Annie-Marie is contributing to an IEEE council on the subject, trying to make a standard.

My first thought was:
- What problem does a testing policy (document) solve?
- When would such a document be appropriate?

Here's my more detailed response:
Look, international standards are great - for products. They are the reason that I can pick up any AA battery and plug it into any AA outlet - they clarify the required form factor, voltage, and tolerances for both.

For _process_, however ... not so much. *HOW* the 1.5 volts is delivered is entirely up to the manufacturer. If he *had* a standard for batteries in the early 1970's, it would have been zinc-carbon. In that case, alkaline would not have been "standards compliant", we'd never have the duracell bunny and our batteries would run out in about 1/10th the time. Oh, and forget about rechargable (ni-cad and later nimH), that's just crazy talk.

The next left of abstraction is to define the process by which those products are made. While we do have some process standards (ISO or Gmp), let's be very careful to not stifle innovation in software testing.

So to be direct: If, as a CIO, I had some *problem* for which I thought a test policy might solve, I suspect I would post the problem on a wiki page and ask my direct reports to solve it.

To quote the one-minute manager - "I don't make decisions for my people."



(Credit where it's due - The seeds of battery analogy come from PeopleWare, 2nd Edition, Pg. 187. Yes, I looked it up.)