Effective use of testers (and any other development resource) is only possible when you have a clear-cut process. The process is the important thing; without it, you have cowboys with keyboards doing whatever the last manager who spoke to them said to do.
There are many, many ways to go about setting up a good testing strategy. These are the things I feel are common to them all:
- A tester has veto over a developer. If the tester says it fails, no-one can override him/her. Period.
- A tester has veto over a designer. If the tester says the design is untestable, no-one can override him/her. Period.
- Developers should write unit tests. Testers should write system tests.
- As many tests as possible should be automated. Ideally, the entire application is smoke-tested within 15 minutes of any checkin, with the whole team being notified of any test failures.
Beyond that ... I prefer a test-first, code-later approach, but that's because of where and how I work. Other companies prefer to have a design-code-test-recode-retest methodology, and it must work for them because they're still in business. *shrugs* YMMV.
- In general, if you think something isn't in Perl, try it out, because it usually is. :-)
- "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"