Clarifications

In the previous post I discussed how you should consider the technical skill level and domain knowledge of your customers when considering prospective testers for your software tools. I would like to add a couple of clarifications.

1. This doesn't mean that all your testers have to fit the same mold. On the contrary, I am a fan of diversity on multiple levels. Having a team from diverse backgrounds tends to increase the size of your group's technical arsenal
   
2. That discussion totally ignored skill and experience in the discipline of software test. An experienced user of specific tools is not necessarily a good tester, and could likely benefit from education in the subject. Similarly, a tester with no industry-specific experience - but who has been working in the field of software test for a decade or two - can bring a lot to the table regardless, and tends to raise the professionalism of the group.
   
3. Can someone learn either the domain knowledge or the software test skills? Abso-freakin-lutely. My pet peeve is when a company will only consider someone for a function if they are currently performing that exact function in their current job. I believe one of the most important considerations should be the demonstrated ability for a person to learn and produce.
   
4. What if your tool has multiple levels of users? Perhaps you provide enterprise software, where administrators set it up and keep it running, analysts customize the tools to the company's needs, and then the typical user of the front end belongs to an industry specific demographic, whether they be engineers, accountants, or clerical. In a case like that you need to determine which skills should be in every member's toolbox, and which merely need to be represented in the group, or at least accessible to it. For example, you may only need one Oracle DBA, while everyone in the group knows how to drop and add a user in order to reset the test data. Or everyone familiar with the technical lingo and basic use flows, but a couple with enough experience to develop datasets and map out more complex usage scenarios.

The general subject of what makes a good tester has been covered in many places, so I won't get into that here. You can find a useful discourse on the subject - and on most things test related - in
Testing Computer Software, by Kaner, Falk, and Nguyen.