Hi John

I am one of those small shop developers and as a result I virtually never get any kind of official specification for a project. The customer usually gives me verbal description of what they want but has seldom thought through the details. So I develop a rough prototype quickly and give it to them to get them thinking. Then I refine it based on their feedback. This usually takes a couple of rounds. So there is no use doing much testing until the project becomes more concrete. Secondly the customer rarely wants to pay the added cost for good testing. They are usually in a hurry to get the application and just want me to fix a bug when they discover it. I have remote access to all my clients so I can usually fix it in a few minutes.

I have developed a fairly robust framework over time so the bugs are usually related to not properly implementing their business rules. Generally I hear from the customer during the 1st month after implementation but rarely after that.

So from my prespective formal testing is not cost effective because it will take longer to develop all the test cases than it does to develop the application. The customer does not see value in this added cost and much prefers to know that I will fix something if it occurs.

I had a large corporate customer specifically say that they prefered rapid deployment with 80% functionally over a well tested application. They felt there was a competitive advantage to this approach and were quite willing to manage the risk.

Simon


>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.