>
>The good thing about a good Q/A is they have a talent for identifying and checking out those maddening edge cases ;-)
>
>The best company I have worked for was Geneer, a company which consciously patterned itself after the west coast software companies despite being located two miles from O'Hare. The perks included every employee having an office with a door, the best hardware and software, all casual dress code (which raised some eyebrows among our more staid building occupants, LOL), a 100 dollar a month book allowance, and a fully stocked free kitchen available 24/7. Some of the young guys ate four meals a day there, LOL. The company motto was "Software done right." I thought maybe it should have been "Miracles performed here" or "Here be magicians." It was a wildly exciting place to work.
>
>The best bennie was incredibly bright coworkers. I was no slouch and had to work my hardest just to keep up. When I joined the company I was a cocky coder jock who underestimated the Q/As at first. Just testers, I thought. I quickly learned better. The typical project team consisted of five people, three developers and two Q/As, one of whom acted as project manager. They were really, really good and saved my bacon more than once. Very anal, which is a good quality in a developer and an even better one in a Q/A.

I have no doubt QA could be a real asset. The problem is in this case QA was laid on for show. The guy they have doing it would be okay for doing what would basically be user testing, clicking on UI stuff and seeing if it blows up, updating records and then checking the result on the back end. We used him for that on a previous project and he was adequate.

But now we are into a very very data-centric project that he really doesn't have the business or technical background to understand in any meaningful way. I'm afraid he also doesn't have the mental horsepower to get up to speed quickly in these areas. ( but then I am cranky old egomaniac who feels that way about most people and most things <g> )

My own opinion is that a real QA should never test any code he couldn't have written and certainly shouldn't be testing code he doesn't understand. I'm lucky that I work remotely and I have a wise colleague who knows how to keep me at my most productive so he runs interference for me and protects me from the dolts and protects senior management from having to process my low opinion of QA's "contributions" on this project <s>