beyond what is seen on the surface so you can better interact with them. It also means having the ability to produce quality solutions with computer science concepts. Test executors shy away from these concepts and argue that they are outside of the scope of a tester's job function. A test engineer is excited over the prospect of streamlining processes with technical concepts, such as scripting language automation and test tool customization.
Differentiating Engineers and Executors
When evaluating resources, whether during an interview or on the job, there are certain things to look for that indicate on which side of the dichotomy the resource falls. The first is whether or not the resource is capable of relaying a basic understanding of testing concepts and terminology. You can always look at someone's resume and find strategically placed testing buzzwords, but be wary of people who can't speak concerning the information in their own resumes. I can't tell you how many interviews I've conducted where interviewees have drawn a blank when asked to describe what's included in a typical test case.
In addition to being able to speak on basic testing concepts, the applicant must be able to speak about these concepts using previous experiences as support rather than as definitions. Many people mistake being a subject matter expert for being a test engineer. When asked about the basics of testing, they talk endlessly about functionality of applications they've worked on without addressing testing's body of knowledge at all. Without an understanding of testing's basic concepts, it doesn't matter how important he was in his last position because the skills won't be transferable. True test engineers can effectively discuss basic testing terms and concepts using personal experiences as support. Key concepts include:
- Test cases
- Test planning
- Defect analysis
- Requirements analysis
- Requirements coverage
- Test reporting
- Test process improvement
The ability to develop innovative ideas is another way to differentiate between executors and engineers. This doesn't have to be anything major, and it doesn't even have to be specific to testing. All it has to be is something that provides a glimmer of hope that the individual may be able to engineer solutions. In an interview, I like to ask, "Can you tell me about an accomplishment that you're proud of that required you to be creative?" His answer tells more about him than other conventional questions about testing theory. This allows the true test engineer to shine, particularly if he doesn't have a lot of testing experience. A good response describes a situation in which he noticed the existence of a tedious process and took the initiative to create something that made the process more efficient. A test executor will almost always sink on this type of question.
Finally, if you already have a testing professional who consistently comes up with excuses instead of solutions, then he may be a test executor.
Exposing the testing dichotomy in this column is not meant to suggest that there is only room for one of the two groups. There is room for both test engineers and test executors in software development projects, but the two can no longer be thought of synonymously. For the health of IT organizations and the growth of the testing profession, it must be made clear that test engineers offer a level of expertise that can never be expected from test executors.