Hiring Software Developers for Testing Positions

Question

Would you hire a software developer/engineer for software testing position? If so, why?

What are the pros and cons for hiring development engineer as test engineer?

Answer 1

Software developers can be the most qualified individuals to perform software testing (provided they can assume the mindset of a user), but they'll be bored silly after a few months, unless you can give them something creative to do, like write unit tests and/or integration tests. That's probably how you want to approach this anyway, with the intent to automate as much of the testing effort as possible.

Unlike software engineers, who typically test what works, a testing engineer must approach the problem of software testing from a different perspective: "How can I break it?"

Answer 2

The Pros:

1. They are probably smart

2. They might know good boundary test cases that other testers might not think of. "Oh, I bet they implemented this using an array of length 10... so what if I put in 11?"

3. They may be helpful in setting up automated testing.

4. You may be able to transition them into a developer role sometime in the future.

5. Their QA could include things like code reviews, unit testing, and database schema validation.

The Cons:

1. They might not actually want a QA job. They may just be taking yours for a paycheck and will quit when the next development job comes their way.

2. They may want a higher salary than non-developer QA.

3. They may do too much of what I put in as #2 pro - wasting time when there is more important/relevant QA work to be done.

Answer 3

It all depends on experience. My 2 cents are that the testers you hire should have domain knowledge on the application your trying to sell.

My organization has testers which are former users, developers and product managers. A good mix ensures that the testing is done objectively.

Answer 4

Why not if he is good QA engineer? Pros:

• he probably has a good understanding of developer typical mistakes
• he has a good understanding of development process from developers perspective (in will be a valuable experience)

Cons:

• there is a risk that he will realize that testing is to boring =)

Answer 5

"The Software Development Engineer in Test Position" from Microsoft would be a real world example of this, just in case anyone thinks this could never work.

My big concern would be why the developer wants to be testing instead of other roles like development, deployment or support. I can see where this could be done and in some cases rather worthwhile as long as there is a reason for the developer taking what some could see as a step down in terms of roles.

Answer 6

I would be hesitant to do so. Development and testing are two different skill sets. It's like asking if I'd hire an architect to be a building inspector. There is a lot of common ground between the two positions, but a different way of looking at things.

However, it would depend on the type of testing being done.

I would be less hesitant to hire a developer for security testing than I would be to hire one for usability testing. A programmer should have a better idea of how to hack into a system than a non-programmer, so I would think they'd be better for security testing.

There are also differences in pay scales. From my perspective, a developer would only take a lower pay scale job as a temporary position until a better job came along. Unless I had definite plans to make an offer into a better position, I would be hesitant to hire someone at a pay rate lower than their true worth.

However,in this economy, there are plenty of developers out of work that just want a foot in the door. As a hiring manager, this may be a chance to give someone a chance that would not normally pass the screening process and give them a chance to prove themselves.

Answer 7

Here is my two cent:

Pro - Developers can actually look into code and find error ordinary QAs may not; and sometimes fix them themselves.

Con - Building the app is a developer's strength and pretending like they are users is QA strength. You need the latter for test.

Answer 8

There is plenty of really buggy code out there that was (obviously) written by developers. Not all developers care about bugs very much, so you probably wouldn't want to hire them to do QA.

On the other hand, the right developer has insights that a non-developer might not have regarding QA.

Interview them for the QA position, if they have the skills and motivation there should be no problem.

I agree with the points about developers getting bored doing QA, consider that too

Answer 9

I was a SDET for a multiple million user web-service project. I think a skillful SDET is totally worth the money, if you are can find one.

Pros:

1. automation tests are amazing, especially when SDET can make tests running simultaneously. How much are you willing to pay your QA team if they can sign-off a release candidate within 30 minutes?

2. SDET can be another API customer, they will give you feedback before your customers use the API.

3. They know how to code and know the common mistakes developers would make. But the key is what they don't know - the source code. As the result, when they write test cases, they do not make any assumptions and their test can capture can't be caught by the dev unit test.

4. able to develop a working load testing plan. Load testing isn't a easy job. I have spent 2 weeks just load testing my load generators before I started to load test the service.

Cons:

1. It is nearly impossible to find a skillful SDET.

2. If you do find a SDET, try to keep them happy and motivated is hard.

3. SDET is like a dead-end job, there is no career path for SDET. Once a SDET is promoted to a lead position, his/her career is reaching a dead end.

I think your best choice is to hire a junior developer as SDET, let him/her work on test cases for a year or two and then promote him/her to a developer position.

Answer 10

QA'ing APIs (especially mulithreaded) then for sure - he'll have to write code for that and be clever to ensure conflicts and for systematically generating test data. Someone who does this right makes a huge contribution.

QA'ing applications requiring unautomated UI manipulation and manual verification probably not

But it really depends on how your organization views QA. How much verification is done by the development staff now?

Who knows the guy might actually end up giving you a truly splendid test environment and sets of tests that finds 17 bugs that have been lurking in your product for 3.5 years.

Answer 11

If it looks like the developer is only interested in the testing position because the job market is tough and he/she hasn't found a dev job, then I would be a little wary about it because there's a real risk they'll jump ship the moment a dev job opens up somewhere. If you just need a monkey for six months this might be ok, but if you're looking for a significant contributor and/or have a complex product with a longer learning cycle, then it could be a problem.

If it looks like the developer is genuinely interested in testing, then it sounds great. They will have a good understanding of how software works. Note though, that testing is a different skillset than dev work -- you really have to think like a user, be an advocate for the user, and be tireless about trying to break the software in new and exciting ways. This person may require some mentoring / training in testing to be effective, but long term will likely be very good at it.

(Note that just asking them plainly what their motivation is might not yield a straight answer..)