How to find (and keep) a tester who is developer

Question

I work for a software vendor whose market is developer tools and we have been looking for a QA person for our products.

Since we are a small shop the position will be a combination of Support and QA however since we make developer tools, our support consists in large part of actual development (in that the person must read and understand our customers code and find and point out bugs in it).
The QA portion will also consist of writing applications (in a variety of platforms and languages) and testing how they work with our tools.

The main issue I am running into is when you tell someone with development experience that the position contains "QA" it its title (or even in the job description) they shy away from considering the job.
I'm very interested in feedback and suggestions for how I can find a good person to fill this job and ensure that they are happy doing it. Any ideas?

Answer 1

Money and responsibility.

The reason I shy away from these types of jobs is they dont tend to hold my interest long enough. Having real development tasks should keep you out of that category. The other problem is the salary is usually significantly lower with that in the title.

Answer 2

I think you have a toughie here:

• The cost of a full time developer for doing the job you require would be too high.
• Most dev's (including myself) would get incredibly fed up, very quickly. Most dev's passion is coding, they want to do it as much as possible. Where TBH, from what you have said, it may be very little in the job role you have.
• I would say perhaps look for a Junior, someone fresh with little experience. They will probably mould better to your testing/QA process, and it gives them a chance to start looking at production code, with perhaps opportunity to work with it.
• Unless you are lucky, I would not expect a "developer" to stay for long, so either expect a bit of turnover, or possibly expand to a full dev role if required, and get a cheaper sole tester in.
• I know you are a small shop, so finances may be a large part to play, but I would say you need to weigh up the possibility of getting a dev in and fixing the problems you have if they occur that often. Testers are cheap by comparison. May be best to get a tester in, find all the issues, then get a contractor/part time dev in to fix issues.

Answer 3

I agree with Adam, money and responsibility are key. I would suggest that, if you're within a small company, that your QA team is small/non-existent. That probably means there's good opportunity for someone to come in and make a genuine effort to contribute and shape your companies QA policy, procedure and workflow.

Our company had a similar issue with QA, and we're still not there 100% with it. But giving the QA person the power to dictate policy and procedure, and participate in all aspects of product development so as to keep them in the loop has worked well for us. This means, when it comes to QA and testing, we've got someone who understands the product, knows it inside and out, has been heavily involved from the start, and has heavily shaped the procedures they themselves, and the development team, will follow. Responsibility is key.

Answer 4

I am a developer, but spent time working as a QA person (test writing, automation, tool writing/coding). I saw it as something I was doing on the side, and would eventually move out of.

The main reason I wanted out was that it simply was not the career I wanted. No amount of money/responsibility would change that. However I think respect has something to do with it as well. A lot of QA work is simply unappreciated, so that is something that would need to be clearly explained as "not how things work at your company."

I would find someone who wants a QA position, but has strong developement/coding/problem solving skills. They could fill in doing the tool creation or other small coding tasks, but it would be on the side. Sort of a reverse of my feelings above.

Answer 5

I think the ideal combination of jobs is product manager + QA. What I mean by product manager is someone who writes requirements documents and is responsible for making sure the product meets the requirements. This person would be a peer of the lead developer, not a superior. A person who is a developer but likes management and wants to take that career path might be very interested in that combination of roles.

Answer 6

To start with you can just take "QA" out of the title and description if that seems to be 'hot button' that is keeping candidates from looking at the position seriously.

From your description, your position doesn't have much in common with a traditional 'tester' role - the work is mostly writing and thinking about code, not banging on someone else's code and trying to break it. Think of it as a fairly eclectic, tools-oriented development position, and try to advertise and staff it accordingly. (And expect to pay accordingly as well - you get what you pay for.) There are quite a few developers out there who have good skills, but maybe a little shorter attention span than others, and who would prefer to work on a succession of mini projects rather than a longer-lasting piece of a bigger project.

Answer 7

You may just want to keep "QA" out of the title, and call the position "Developer Support" or something like that. Don't mislead any candidates about the duties of the role, but you can cast it more as a "You will be responsible for building the releases and ensuring they are ready to ship to customers."

Also make sure that there is a career path that leads into more development, not more QA, if that's what the candidate wants.

Finally, make sure that the other developers treat this person as a fellow developer, and not as somebody outside the team.

It's sad that "QA" has some stigma attached to it among developers, but it does.

Answer 8

Dude, A certain company I work for has found the solution to your problems. Hire QE not QA. QA (Quality Assurance) does have a stigma to it. The job title itself implies boring rote tasks to most developers. QE (Quality Engineering) sounds just as bad, but doesn't scare off nearly as many people.

If all else fails just hire a developer. I mean seriously, you want someone who can write code, so hire someone who has training in that. The thing is, you need to look at your applicants and talk to them. You are looking for someone who knows how QE works and you want to hire a developer that works in the language your program uses not what it's written in.

Answer 9

I was a programmer working as a tester for a little time. If I may, the answer is quite simple: let them do whatever they want.

If you give them free reign, I can guarantee that your software will be tested in ways you never imagined.

If, on the other hand, you try to control such a person, then they will grow to despise you. This is inevitable.

The benefits outweight the costs. If you're a large corp then this decision is easy. Just hire software developers and tell them to "go to town" on your product. You'll love the results.

Answer 10

Money and responsibility are key, as Adam and Chops point out. Quality engineers should be on the same pay scale as the developers. Interesting work is also an important factor. The role sounds like a nice variety of tasks.

At my company, developers are often loaned to the test team between projects or when test team is swamped. Some have a knack, others don't. Still, most developers would rather test their own code than find bugs in others' work. The test managers actively woo developers with strong testing skills. I resisted switching to the test team for seven years. A promotion, a 20% raise and a promise that my role was primarily trouble-shooting, management and planning finally convinced me to switch. I do more hands on testing than I thought I would, but I get the challenging work too.

Pay comparable to development. Be truthful; disclose actual expectations of the role. Change the title to Software Quality Engineer.

Answer 11

The most common title for this posotion is "Software Developer in Test".

But I think another trouble is much more important - its hard to prevent a person with good testing and dev knowledge from migrating to Dev team