What skills technical testers candidates are missing?

Question

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 factors¹, 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.

¹Faught, D. R., How to Make your Bugs Lonely: Tips on Bug Isolation. ANNUAL PACIFIC NORTHWEST SOFTWARE QUALITY CONFERENCE; 471-480; 2004

Answer 1

If those skills are more common, maybe there's some training missing in my area?

I am not sure what your "area" is but, training and certifications can be done online via ISTQB (on-line or in person).

Or maybe testers do not know what skills they need to learn?

Remember that like CS, QA can come from many backgrounds; ranging from manual to automation specialist.

Or maybe those skills are more common for developers and we should try to convert them into testers?

A dev would still require training and will be more expensive.

I'll cover each bullet point:

Overestimation of one’s programming skills.

This happens all the time. The only way to gauge is to test. In past interviews I have been asked and have asked others to write a simple coded test. Point out that Selenium IDE can be used, but the test needs to be executed using something like JUnit.

Poor test case design skills.

Asking them to provide coded examples in the interview will shed light on test design.

Reluctant to troubleshoot bugs.

Often this requires domain knowledge. Having steps to reproduce ought to be enough for any dev to turn on debugging and step through.