Hiring Testers: What skills to choose?

I work in a good environment for a quality engineer, or software tester. My company has enough size for there to be variety in teams, yet is no so big that we are out of touch. We have a particularly good sense of community among quality engineers who would not have reason to meet if it were not for the fact that knowledge sharing is actively encouraged.

We share knowledge sometimes by sending a few testers to a conference and listening to them present the things that, essentially, caused them to have the biggest emotional reaction - a moment of epiphany, a feeling of disapproval, a change of heart.

In the latest, a bit of a 'war of presenters' was mentioned. One of them went into great detail about how all quality engineers should be made to be as technically knowledgeable as a good developer. The other was very passionate about hiring people based on the more intangible aspects, such as whether they could solve problems, rather than looking for someone technically proficient.

I was hired on the latter principle, general ability, experience, and attitude over intense technical training. I had doubts that I was going to get the job, and honestly responded in the interview that if they were looking for someone with extremely high levels of technical literacy, I was not the right employee for them at this moment in time. I felt I needed to say it, because I had seen the lengthy requirements lists on job advertisements that I had hunted through. I'll admit, it made me feel a little inferior.

However, my employers do something that did not seem to be accounted from in this war of presenters at the software testing conference. They take both approaches, depending on what is more appropriate for a given team at a given time. They seek balance.

We have both technical testers, as well-versed as any developer, who write automated scripts, analyse performance of products on every level, who find complex bugs and proceed to drill down to the root of them so that the developer need only write the fix into the code. We also have testers who use black box testing, who rely on internal tools to capture logs that developers can use for investigations and who unearth any annoyance that may assault an end-user's eyes. Both types of tester are useful and it is rare that you will find someone truly talented at both things. Even if you do, they probably cannot cover everything (unless your product is very, very, small).

The different types of testers can be used in different ways. They can work together pair-testing and passing knowledge to each other. This enables them to become more rounded in experience. They can work separately, one testing the interface and another performing load testing. This enables them to become experts in their specialised areas. Which of these is best is a topic for other discussions.

Essentially, I don't see what the fuss is about. You hire people based on what fits the needs of your team and your specific company culture. Preaching that one type of tester is better than the other is completely illogical to me. Testers are not all the same, and the field of quality engineering is not all that small.

I work in an agile environment, so I will talk more about the effect that has on quality assurance and how it is performed another time.