Hi,

There are only 3 requirements for a good product tester and they are as follows:-

1. The ability to think like a blond.
2. Have the ability to put your head on back to front. (Think lateraly - NOT) A bit like a blonde but worse.
3. Have the ability to get the product to do something it was never designed to do. (This also requires the ability to ignore the 1000 error messages that occur prior to getting the desired result, then say I think your product has a problem.)

A good testers standard reply to the product designers question, "Why did you do that" is "Cause I could" and give no other details.

>Hail, fellow Vulpics!
>
>I recently was informed that I was turned down for a quality assurance position with a major company after 3 weeks of interviews with no less than 13 different people because they felt I wasn't enough of a "manual tester".
>
>While I respect their decision, it felt a little like bookeepers declining on an accountant because they weren't sure he could maintain a cash drawer.
>
>This wasn't the first time in the past several months that I've run into earnest organizations who really wanted to do good product testing but were all into buzz and didn't understand practice.
>
>I recall reading years ago about the "Cargo Cult" management anti-pattern where you did something because you thought it was the right thing but didn't grasp it entirely. It seems that this mentality is pervasive in testing - in IT as a whole. In the Fox world, there are those trying to change that - Russ Swall comes to mind - but I'm not sure that it's making an impact.
>
>I can't back up my assertion with hard facts, but I'm pretty sure that most VFP developers are very small shops with 1-3 developers. In my experience, that seems to be the case. Having been one, I can tell you that my approach to clients was to get the application done by deadline and fix issues afterward. Perhaps the wrong approach.
>
>There are a lot of emergent agile methodologies that stress early test involvement in software lifecycle, but how realistic is that with small development groups, limited budgets, and stringent deadlines? Most contracts I ever saw included a week or two of "testing" (nothing formal) and
>then some sort of warranty.
>
>Good testing, on any contract, saves everyone time and money but how is this realistically addressed in the economic realitites of being a VFP developer? The existing protocols and methods are simply too expensive and resource-intensive for your average shop.
>
>There should be some sort of solution for the small provider that doesn't inflate the cost of the project nor significantly reduce the profit of the project.
>
>But what is it? Not sure, but maybe it's something we can explore together. I'm hoping for some great replies, but please feel free to email me at jskoziol@msn.com with deeper insights.