I'm trying on understand what are the common skills and knowledge that candidates for technical testers are missing and thus failing at job interviews.
The reason I ask those questions stems from the time we spent and invested into finding the right testers for projects in two companies I have been to. For the last several months, we have been searching for a technical testers for regular positions, rejecting more than 20 candidates on a way.
I found some common reasons for rejecting candidates (below), but I wonder whether they are common only for our projects or my local market. If those skills are more common, maybe there's some training missing in my area? Or maybe testers do not know what skills they need to learn? Or maybe those skills are more common for developers and we should try to convert them into testers?
Here are the reasons:
Overestimation of one’s programming skills. Many candidates thought that if they were scripting tests in Selenium, then they know programming. An example of such a failure was when an experience test automation engineer was not able to implement simple function that parse integer from a string. Programming goes much beyond Selenium scripting and I think is a vital skill when a tester is supposed to write backend test and contribute to the test automation library.
Poor test case design skills. Many candidates for more business-like positions (or simply black-box testing positions) were not able to apply test case design techniques for real problems even though they had ISTQB certificates that certify they should. They were also often unaware of possible negative test cases that could trick the system or crash it.
Reluctant to troubleshoot bugs. Many candidates failed at troubleshooting bugs they reported, leaving the whole responsibility to the developer. While the line who should do what is negotiable and depends on many factors1, I believe basic troubleshooting information can lead to better cooperation between testers and developers and thus shorten the time necessary for fixing the bug. The classical failure in this area was when a tester could not explain during interview what was the architecture of the system they had tested in their previous position and thus could not pinpoint where potential integration bug could occur. When such testers were employed, they often reported bug reports that were hard to reproduce for developers and thus often closed as invalid.
1Faught, D. R., How to Make your Bugs Lonely: Tips on Bug Isolation. ANNUAL PACIFIC NORTHWEST SOFTWARE QUALITY CONFERENCE; 471-480; 2004