Hi John,

In the first company I worked I (and later my Russian colleague) was the only in-house developer with few contractors outside (later we were down to only one outside person). The software we were writing for internal company's use and basically we tested it on our users. We did receive an immediate feedback and provided bug fixes and enhancements right on the spot. No formal testings were either introduced, though we did use a special software Bug Tracker.

In my current company we have two people which are doing QA for us. It's also internal company's software, so if the bugs slip into production version we would hear response immediatelly. We don't have formal test plans here either...

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