What are key advantages of adding developer who can test vs tester who can code

Question

Background: To hire for an engineer position in a small(2-3 developers) agile team where there is no existing "tester" in the team.

Problem statement: We are trying to decide what skills we should be looking for - a software engineer with development background who can effectively test at least on unit / integration level or a tester who can understand & review application code directly and can write unit level tests.

What are the key advantages and disadvantages of adding a developer with some testing skills vs adding a tester with some development skills?

Answer 1

TL;DR:

The difference between a developer who is using test automation, vs a automated test developer is philosophical and academical, but in reality they have nearly-identical set of skills (and difference in other skills will be bigger than this difference).

---

If you are hiring a developer who cannot test, it is not a real developer and obvious no-hire.

If you hiring manual tester, no development skills are required.

So I assume assume hiring for a position with substantial responsibility for automated testing.

Now you are presumably comparing a developer who already knows (or willing to learn) your test automation technology, vs automated tester. Some people call them "software developer in test", which tells you all you need to know. They are developers, but instead of your core system, they are developing tests for that core system.

If you will be interviewing 1000 people to hire 200, it might be not a total waste to ask your question. But because you are hiring just one person, you just list core and nice-to-have competencies, and then hire best overall candidate.

And quality of the candidate is more complicated than just being a developer (and if developer cannot do unit tests for own code, it's a no-hire) or a tester (manual? test automation is just development using different libraries). For that single hire, you need to account for

• other skills (communication, sys admin, personality fit, etc),
• level of those skills, and level of domain knowledge (previous experience with similar systems)
• transferable skills from previous projects
• previous experience (and/or lack of it) with dozen of tools you use,
• estimated time to get up-to-speed with missing skills and expense to get them (and do you have time to wait)
• "vibe" from the candidate and candidate's willingness to gain those missing skills (it is difference between learning during work hours if I have to, vs learning in my free time because I am so eager to learn the technology)

People are not cogs, especially for small group, where you are flying very low, contribution of every member is obvious, there is no place to hide, and bad hire can make or break the project. You need to evaluate individuals, and chances you will have two candidates with exact same level of all other skills (and so difference mentioned in original question will be the decisive difference) is zero.

Your best bet would be a former manual tester, who already knows your core system, and is eager to learn programming and upgrade skills to test automation. Or a former core developer, who for whatever personal reason is interested to learn your test automation technology (vs being forced to learn it).

Edit, Feb 2019:

Also, testing on unit level is best done by the developer who is changing related code. a (failing) test should be written for each reported bug (to make sure it is correctly detected), then bug should be fixed (so unit test will pass). It would be a waste of time to someone else (tester) learn relevant code deep enough to write unit tests (core developer already knows everything relevant to write that unit test).

Answer 2

This really depends on what the complexity of your software is supposed to be. For simplicity lets segregate two types of software:

1. Complex software requiring strong development skills and knowledge
2. Simple software requiring middle skills and less knowledge

For type 2 I would hire a "tester who can code" because a tester will be developing the code having the professional intuition and understanding of what the typical problems such the software could have, thus it will help to overcome such issues on the design or implementation phase.

For type 1 I would hire "a developer who can test" but I would not really rely on that dev anyway and I would still consider having some test resource in addition. Either on a part time or as outsource or freelance relationship if we're in tight budget. Because normally developers do not look on their own code in a critical manner and even might miss some important testing aspects like testing integration with other components or usability testing.