Which one should I hire next, a developer or a tester?

Question

We are currently in the progress of developing a new product, all of the sudden, most of our dev team resigned and switched to another company.

There is only 1 developer left in the team, *sigh

He's been ranting on getting another developer and a tester to help him out, but which one should I hire first ?

Should I hire another developer and give him testing job also, or should I just hire a plain tester.

(hiring a tester is more cheaper here than hiring another developer, financially speaking)

Answer 1

If "most of your dev team" resigned, why are you only considering hiring one person?

And isn't there another problem, if you're asking us instead of your remaining programmer?

EDIT:

Without a better idea of your workload and the skills and work habits of your programmer, it's impossible for us to know. But since you'll only have two employees, I would expect they'll both need a fair mix of both testing and coding skills. Or you might consider a crash course in Software Testing for yourself - it sounds like a little more direct experience in your business technical skills (and a closer relationship with your employees) would stand you in good stead.

Answer 2

I suggest getting another developer, developers can always test. But most testers aren't going to be able to develop.

Answer 3

I think you need to get address the issues regarding the departure of your previous employees before you think about hiring another one.

Answer 4

Before you hire anyone else, find out why the rest of your dev team resigned and fix that issue. That may well inform your decision about who to hire next. In particular, while it's unlikely that the whole team would resign due to your one remaining dev, it's just about possible - in which case you'd be finding a new dev to start with.

Hiring someone and then finding they quit soon afterwards is going to be expensive and time-consuming. You'll also find that good developers will be reticent to join a company which everyone else has just left, unless you can assure them that whatever the problem was has been fixed.

Once everything else is fixed, if you've still got the situation of "budget for one more, and still got one dev" then you should look at what your current codebase is like. Is it a disaster waiting to happen, which could really do with some good testing to shake out all the problems? If so, hire a tester. Is it basically okay, but you need to add new features on this solid foundation? Hire a developer, but explain to them that they'll be expected to do testing as well.

Answer 5

Something is weird about this question. However, taking the weirdness aside, I'd say you need to calculate the workload. If you hire a developer and expect them to do a lot of testing, you'll be disappointed; they'll leave. However if you spread the load between them that'll tie you over until you can get a tester to take on all the testing for two full-time developers.

Just make sure you don't have the situation where developers are testing their own code.

Answer 6

Testers don't have to be full time to work effectively, especially if only supporting one programmer. However, they do tend to be much more organized in their testing methodology than programmers testing other programmers - so my advice would be to hire a part time tester before you lose the one programmer that you have left.

Answer 7

If your developers gets hijacked all the time, then perhaps hire a tester. He can take off some of the load of the developer.

Answer 8

Get a developer and institute some XP practices, mainly pairing, TDD, and Acceptance Testing. This will address the quality hole you have today.

Answer 9

Besides fixing the initial issue, you might consider the following:

• You mention "hiring a tester is more cheaper", which an initial issue. Hiring the type of testers you want to have isn't going to cost you less than a developer. The usual opinion is caused by hiring less skilled testers, which of course will charge less.
• Blur the tester vs. developer line. What we do is have developers automate their smoke tests using a tool like selenium rc, coding the tests using the same "unit" testing framework as the one for the unit/integration tests. Testers will review the tests and expand on them, so it is actual collaboration going on. From this you can tell you need testers to be able to code, and developers to be able to "test" (at least the basic scenarios).
• Use agile, continuous integration, etc. Ideally you want someone with real background on this, but being on a constrained budget might complicate it.