This article provides a guide for hiring a Software Quality Assurance (SQA) specialist. It provides tips on what questions to ask and what problems to avoid in order to hire the right person.
What criteria do people use to select QA engineers? It's natural to think that the right kinds of people to hire are people just like you-but this can be a mistake. In fact, every job requires its own unique set of skills and personality types, and the skills that make you successful in your field may have significant differences from the skills needed for the QA job.
If you read many job posting specifications for QA roles, you'll find that they commonly describe skills that are much more appropriate for a developer, including specific knowledge of the company's unique technology. Some specifications are so unique and lofty that it seems the only qualified candidates would be former heads of development!
Realistically, the QA person you seek should have the adaptability, intelligence, and QA-specific skills that will enable them to come up to speed on your project quickly. Relevant experience includes testing procedures, test writing, puzzle solving, follow-through, communication, and the "QA mindset."
Unless they are testing a programming interface or scripting language, a QA person's role is to test the product from the end user's perspective. Contrast this with developers, who look at the product from a code perspective. Consider the difference between being focused on making the code perform in a very specific way and wondering what would happen if you did "this" instead of "that" through the user interface.
It's remarkable that the people who are assigned to interview QA candidates tend to be anything but QA people themselves. Most often, developers and HR people do the bulk of the interviewing. Yet QA is a unique discipline, and candidates need to be evaluated from a QA point of view, as would accountants, advertising staff, and other specialized professionals. QA people often have the feeling that they need to have two sets of skills: those that interview well with development engineers, and those that they actually need once they get the job.
What Not to Do
The first mistake you can make is to assume that you don't really need a QA person. Code-based unit tests do not represent the end user's interaction with the product. If you tell your boss that you "just know" it works, or base your assumptions on unit tests, she probably won't feel reassured. Before the big rollout, she is going to want metrics, generated by a professional.
The second mistake is to conduct the interview as you would for a development position. Even though more and more QA people are getting into programming, most of them aren't developers. If you give most QA people a C++ test, they will fail.
Quite often, developers are tagged and thrown into a room with a QA candidate just to round out the interview process and make sure that everyone on the team feels comfortable with the choice. But many developers only know how to interview from a developer's perspective. When asked to interview someone, they will usually give them a programming test, which might eliminate candidates who have the best QA skills.
Unless they are testing from the API level, most QA people don't go near the code. They approach the product from a user's perspective. You are not looking for a programmer; you are looking for someone to represent the user and evaluate the product from their perspective.
What QA People Do
If the actual requirements of QA almost never involve any experience with the programming language, environment, and operating system, and very little to do with the type of program being created, what criteria should we be looking for? If QA people aren't programmers,