Hi John,
I've been running a small team for years. Originally just myself but now we have 5 developers and one technical writer.
Most of our serious issues, the ones that have cost us the most, are the in the logic and business rules area. Code errors generally show up pretty quickly and we have great systems for identifying these. But logic and rule errors can have a really big impact, especially on the data and can go on unnoticed for extended periods.

I've usually found that producing good documentation, even if the customer doesn't read it, provides the best means of avoiding these "bugs". The point is that someone is reviewing how the code works in "common sense" mode. "Telling the story" of how the software is supposed to work is very revealing of faults in design and logic.
Our documentation happens in two stages...
1. The coder writes a technical description of what he has done or is doing in our change control system. This often links back to a customer request.
2. The technical writer (which could be the coder in a small shop) writes up the user manual which necessarily involves using the application with a copy of real world data.

My experience is that, even when I was a one man band, the best work was produced when I/we were diligently updating the "user manual".
Ever since we hired a technical writer our software quality, as perceived by the customer, has improved exponentially.

Finding someone who is a good "tester" is really very difficult. Out of scores that I have come accross I would guess that only two or three have really made a difference. The best ones have been frenetic on-site users who really care about their job and who can think in systems mode.


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