Here are some snippets from a letter I wrote this morning:

I have a slightly different point of view. QA provides information on the state of the product, in terms of risks. This information is used by the product management team to determine where to go next in the overall development process. Acceptance testing should be done by ops or the customer (though it can be done by QA if it is spec'd out by ops or the customer, and QA can help them write the spec). Regulatory testing is like acceptance testing.

QA should not be the gatekeeper - that leads to high turnover in qa management :-)

What I do is figure out how to run the test effort. I can identify the areas of risk, and staff appropriately. I can measure the ongoing effort and identify problem areas. I can predict how long it will take to test something. I can write killer documentation of the process. I can figure out how to improve the testing process, both on-the-fly and after-the-fact. And I can share with senior managers the benefits and tradeoffs of particular testing approaches ;-) Finally, I do it all while having fun, and making sure the testing team is having fun.

All that is not easy, and I could make a long list of specific techniques that I use to do it so that it's not seat-of-the-pants guesstimation.

...

Most senior managers don't know what they want from a qa effort. I treat them as my customers, helping them to decide what works best.

9:16:13 AM