Some skills I can think of off the top of my head (from Lisa)
- Ability to analyze and prioritize risk and think of ways to mitigate it
- Ability to specify executable tests (not necessarily to automate them, but to format them in a way they can be automated, such as Fit)
- Ability to define and estimate testing tasks
- Excellent communication skills necessary!
- Ability to work together with team members
- Ability to self-direct (can't wait for someone to say 'now test this')
- Ability to share responsibility for quality with team members, and to allow the customer to define the level of quality needed (this is hard for many traditional testers who are used to 'owning quality' and deciding when it is ok to release).
From the agile-testing? list:
In agile-testing@yahoogroups.com, jkohl@t... wrote: Hi Lisa;
I've done a little bit of recruiting for testers on agile teams. I try to get a read on the person's attitude. Few people from the QA school of thought have even heard of agile development, so if they haven't heard of it I don't take it as a bad thing necessarily. I'm looking for a candidate who epitomizes what Jerry Weinberg says about a tester as someone "...who sees variation when others see a universe of one.", has a teachable attitude, takes testing seriously and seems to enjoy a challenge. If those things aren't there, then they won't work in an agile team. Some things I look for:
- teachable attitude. someone who wants to learn. 99% of testers I've worked with have to learn about agile when they start. those that have excelled for me have known little about QA for some reason.
- contributing to a side project, maybe an open source one (if they are a developer)
- taking courses (in anything, I don't care if it's software related or not)
- "snap" in the interview: the candidate picks up something and runs with it passion. I watch for their eyes to light up when they describe finding a difficult bug
- someone who questions the status quo. a lot of QA people seem to love the status quo because they have a set of documents to generate bug reports from. I want someone who is smart and can test in areas of uncertainty who doesn't need requirements docs. This is hard to interview for.
These things usually tell me a lot about the person, and whether they will fit.
The best candidate I brought in had no agile background but was keen to learn. One of the worst had some head knowledge of agile and could answer the recruiter's questions. I took them on a recommendation without interviewing them myself, and they were QA Police. The questions that I focus on are around skills and have people design tests and solve problems. I like Joel Spolsky's "Guerrilla Guide to Interviewing" http://joelonsoftware.com/articles/fog0000000073.html and use a model that is quite similar. I use behavioral-descriptive questions that focus on what the candidate has done in the past based around scenarios that I have observed are a challenge for a tester on an agile project. I'm told my interviews are tiring and have no fluff. :-)
I don't usually have any canned questions beyond "tell me about a project you particularly liked and why", I just make a list of what skills I need for that position and make up behavioral questions based around them, and have them solve problems to prove that they have the skills. I might have an interview schedule kicking around if you'd like to see it. For phone screens, I usually look for someone with the background I'm looking for, and see if they can think on their feet. That narrows things down considerably. I generally get a feel for a candidate based on a lot of different things that show me their attitude rather than a right or wrong answer.
Hope that helps.
-Jonathan
Back to TeachingAgileTesting
Back to ContentTutorial
