I’m trying to fill two technical tester positions. It’s exhausting. All the resumes are starting to look the same. They all tout:
- Extensive knowledge of the SDLC. Who cares? I’ve been testing for 15 years and I’ve never encountered a situation where extensive knowledge of the SDLC has come in handy…I’m not even sure what it is. Who is motivating this? Are there that many Test Managers out there saying, “what we really need, is a tester who knows the SDLC”?
- Understanding of test automation tools like QTP? “Understanding of”?
- Ability to map test cases to requirements in Quality Center. It’s been 6 years since I’ve seen Quality Center but I don’t recall it being that difficult a task.
- Performed different types of tests like Functional, Regression, Smoke, UAT, White Box, Black Box, Grey Box, and End-to-end. Darn, I was really looking for someone who could write “integration tests”. Oh well.
One resume said:
- Extensive QA experience via hands-on testing? Is there a way to gain experience without being hands-on?
Another said:
- Fixed tested bugs and coordinated with developers in release of bug fixes during every Sprint Run. Hmmm. Perhaps you should start by testing your resume verbiage.
During an interview I asked:
Me: According to your resume, you worked on a team using Test Driven Development. Was it effective?
Candidate: Oh yes. At the end of Sprints, if the developers had time, they would write some unit tests for Stories we were about to release to production.
During another, I asked the following easy question:
Me: What are some attributes of a good bug report?
Candidate: Documenting the bug is the most important attribute.
Finally, after an interview with me, for a programming position, the candidate remarked, “That’s odd, I’ve never seen a man in a QA role.”. It reminds me of a little post I made years ago that almost lost me some friends.
BTW - If you live in the Atlanta area, have excellent DB and SQL skills, and are capable of testing something without a UI, please drop me a note. I may have an awesome job waiting for you.
RSS
I currently have an all-male test team: me and four others. First time in my test career I've not been part of a test team that was mostly women.
I have similar challenges finding talent. There are lots of test positions in my area for the big corporations who manage software development very much like manufacturing. Candidates with that experience generally think that you have to have requirements and a thick test script to do any testing. When I ask what they think they might do with no requirements, their answers almost always involve trying to force someone to give them requirements.
Recruitment agencies could be a contributor to this?
I had no choice but to go through an agency to find my current job, and they sent my CV back twice so I could put more of the "key words" in there.
"You've got functional and integration testing, but you haven't mentioned regression testing, you need to add that before we can submit your CV". Etc.
Yes, this is all too typical in tester resumes.
Earlier this year, when in an interview, I asked a potential hire what testers they read or blogs they follow. Almost everybody read nothing. One person said, "Tech Crunch".
Did you hired the (clearly inexperienced) guy who said "I’ve never seen a man in a QA role"? :et's not get into the "are women better testers" argument again! :-)
I run into similar difficulties looking for full-times for our team.
Have you considered looking for new grads? I work with a lot of co-ops (hire + mentor + evaluate), and (usually) after they're ramped up, they become a valuable member of the team, probably because they haven't been influenced by manufacturing-style software development.
In regards to listing different types of tests, I was unfamiliar with many of those terms the first few years I did QA. I got a lot of my early experience from a company that just did "white box" testing, using "efficient test cases." There wasn't "boundary value analysis," or "decision table testing," or "smoke testing". We "just did" white box testing. Everything else was a subset of achieving quality with that methodology.
As I have become more familiar with these terms over the last year or two, I wondered if I was shooting myself in the foot by not researching these terms and including them on my resume (coincidentally along with most of the other items you list.) I always preferred to focus on types of software I've tested, real-life cases of finding and preventing bugs, and tools I'm actually comfortable using (as opposed to "familiar with.)
I've been reading your blog for about 3 years and i don't know how many times I've found myself dealing with the same situations you post in your blog entries :)