This morning, while smelling the wonderful aroma of coffee, The Offpring beamed an exhaustion melting smile at me when the great folks at Soma pulled a song out of the crevices of my record collection that has a groovy, gravelly beat that I hadn't heard in years. The hook is left, the beat is Jeff....

Goodness.

But amongst that Goodness, there is Evil lurking in my head. Specifically, the kind of evil that QA needs to have.

Textbooks assert that from a business point of view, engineering is a monolithic blob that needs some amount of resources and thus becomes responsible for putting out a product that works perfectly based on marketing's requirements. In real life, the process is generally a lot more transparent. Releases need to be managed, cost of maintaining older code come into play, and the timing impact that new releases have on customers and market pressure are just some of the many details that tightly couple day to day engineering to day to day business.

One of the biggest challenges engineering faces in managing their end of the bargain is testing -- how do they make sure the product that they have committed to delivering works as advertised, doesn't have unexpected side effects, and is (if applicable) secure? After all, code that spontaneously explodes doesn't tend to go over so well.

A few things come to mind...

QA must be blunt

This means telling it like it is and being punks about it. This includes telling engineers that their code sucks, telling marketing folk that their estimates are grossly unreasonable, and telling sales people that shipping something prematurely can end really, really, badly..

QA must be evil

Negative test cases should be a staple of every QA group, but you don't need to look further than Bugtraq to see that they aren't. Negative test cases means being evil about their inputs -- sending a million byte input when all that is expected is a 4 byte value, etc. More importantly, the teams that have to act on the errors that come out of these test cases need to treat them as real bugs. Responses like "well, that will never happen in real life," or my favorite, "that's not a valid input," should be a no go.

QA needs executive level support

QA folks are often put into the position of being the naysayers of an organization. After all, all they can do is find problems. The more esoteric the problem, the more support they often need. We just need to remember: one doesn't need to look too far to find examples where the esoteric become real business problems.

By no means complete...

This is by no means a complete list of things a QA department needs to do. It's a job that can't be easily summarized in a few scant words thrown into a blog entry. However, a good QA department with the necessary executive support is worth their weight in gold. They provide a complete picture of where a product is so that spontaneous explosions don't become a problem. Following QA's advice isn't always the right thing to do -- it is simply a risk that needs to be known.