There were a number of people who didn't get the cartoon about differentiating between a good and a really good tester. For those who didn't get it or like the cartoon, thank you for return to this blog again :o)
The idea behind the cartoon is that it can be very difficult to assess the performance of a tester, this can be specially hard during the recruitment process. For example, a tester with a testing qualification (ISEB/ISTQB) does not necessarily mean they are a good tester (nor does it mean they're a bad tester!).
I’ve been recruiting testers for around 4 years and it’s not getting any easier. It can be very hard to determine if the candidate is actually any good at testing, it's one thing giving answers to questions in an interview but it's completely different testing real applications. If I had to give any advice, I would recommend employing testers who you think are suited to the culture of your work place; would you get on with them? Would other testers/developers get on with them? Also, for our workplace, it’s important that the candidate understands what type or style of testing they are getting into: is it heavily documented? What SDLC is used? Is there a requirement to use automated test tools sometimes/all the time?
I could give you more advice on recruitment, but I'm afraid I would have to charge you and I couldn't guarantee the advice would be of any use.
;o)
Use of a practical exam would help, but I suspect it would be hard to come up with a useful test that interview candidates would be willing and able to take during the available time.
ReplyDeleteThe first real job I took after college did something like that. It was a developer's job. Before the interview, they asked me to send in some program I wrote. I did. They studied it and asked questions about it during the interview (to make sure it wasn't written by someone else.)
I thought this was a great idea, but only because I was a student and therefore had lots of software I wrote that I could send them. It wouldn't work for someone who's been working for corporations for 20 years and therefore doesn't own anything he wrote in the past 20 years.
We used a very simple test during an interview we did last year - I drew up a heavily simplified design of one of our apps, and asked the candidate to talk me through it, discuss what he'd be thinking about testing, where he'd want to know more detail, and so on. He instantly asked about something I'd planned to add, and forgotten.
ReplyDeleteRemember that a tester is interviewing you as much as you are interviewing them - I'd be much more impressed by a place that asked me to test during interview. If I went for an interview and was only asked "waffle" questions, I'd expect working there to be an exercise in frustration.
I once had an interview for a testing job where their was a practical element. The company basically threw in a couple of spelling mistakes and deliberate bugs here and there. I was told to find as many as I could in 10 minutes. I was told afterwards that their were 10 bugs hidden in the application... and I found 11 genuine bugs. Has to be one of my proudest moments as a tester :)
ReplyDeleteWould definitely agree that some people “have the gift of the gab” and have read the BCS books inside and out, but when it comes to physically testing an application, just don't have the ability to back it up.
I have a real life example for you:
ReplyDeletehttp://consumerist.com/2010/03/little-girl-gets-arm-trapped-in-coke-machine.html
Agreed, testing the system design probably wouldn't have accounted for a curious 6-year old, but what about any object trying to go the wrong way in the coke machine?