Right up front, you have to decide which approach is going to provide better QA for your product: Environmental mimicry or egression testing. The choice you make will dictate the people you hire: Subject matter experts (SME) or scripters. And need I bother saying that each choice has its advantages and drawbacks over the others?
Most everybody knows about the importance of regression testing, and why you need a scripter. If you don't, a scripter is somebody who can write scripts that automate the testing. Because if you don't have automated batch tests, then by the time that version 62 of the software rolls around, the test team is just going to focus on testing the new features, and absolutely nobody is going to want to open up the program, click on "save file", and type in "foobar" and hit okay for the 63rd time, and that means regression bugs will creep and not get caught. Some tasks just have to be automated or they won't get done.
But you also need SMEs for environment mimicry, or rather to build a test environment that hopefully shares many similarities with the real world. For example, let's say you have a software application that reads in a PDF file and prints it out to a color plotter. You may need a color SME to calibrate the plotter and plug in the proper ICC profile so that if the plot comes out looking terrible, you will be able to determine if it's the app that is causing the problem or something else.
If you are building a version one of an application, then your tester is probably a SME, a industry expert who works with the developer team in building the test environment, generating test cases, and acting as a sounding board when discussing feature requests. Important note: Discussing features and their implementation is the most fun part of a job for a SME, whereas the first two responsibilities can oftentimes be tedious and annoying. So you need to stay on the SME to make sure they understand that's their job to make sure the plotter has paper loaded, and yes, they need to fill out ALL fields in a test case report.
A good SME is a Godsend, not only acting as eyes and ears for the developers, but also for the product & project managers. A bad SME can make your life a trip into purgatory that lasts well past the completion date of the project. It's most important to hire a SME with really good oral and written communication skills: Somebody who can sling the paperwork and talk to developers is worth their weight in gold. If you are building a version one application, the absolute worst choice you can make is to hire a junior engineer or programmer and have them learn on the job. If the enraged customer base don't tear the poor guy from limb to limb at the first opportunity, then the sales force will pummel the guy senseless at the first trade show. The best SMEs have a reasonable amount of street experience, very good communication skills, and a pretty thick skin. The relationship between your head developer and the SME is key indicator of how well the project is going: If the two are buddy-buddy and give each other excellent grades on their performance reviews, then all is well with the world. If the two can't stand each other guts, then you should be spending a lot of time pacing the bedroom floor at night, losing sleep (and also looking over resumes so you can replace your SME).
Sadly, a development team tends to lose SMEs over time. Usually, as soon as a project is launched, the SME's time is usually taken up dealing with the documentation team, customer support staff, demonstrators, and the sales force. Over the long term, a software development culture where the code-writers are king and everybody else is a second-class citizen, tends to grate on a SME. They either go native (learn to write code themselves) move up into management (like yours truly) or move over to technical sales (where the money is better).
Scripters start to make their appearance near the end of a project, or if the application is a version two or higher. If you have inherited a team with scripters, then you have been blessed, as they are one of the signs of a mature and competent development group (daily builds and proper source controls are other signs). In a perfect world, you would have your SME feed test cases to the scripter who then builds an automated suite that can take the app through sanity checks on a daily basis. However, for this to happen you need a lot of things to fall into place: 1) A scripter who listens well 2) A SME who communicates well and does not feel threatened by the scripter and the automated tests 3) Developers who respect the progress and don't break the automated test suite with gratuitous radical changes to the application.
On most projects, this level of sophistication in building a test environment doesn't occur because of logistical constraints. However, if you are hoping the application that you are building is one that will last for a decade, it's crucial to the maintainability of the code base that you build a strong test infrastructure. Without a good SME, you'll have no eyes and eventually get brain damage from running into walls all the time. Without a good scripter, you'll give up running your sanity tests over the long term, and eventually your application will collapse under the weight of unfixable regression bugs.
