We are recruiting test engineers to two existing projects, that up until now had a single test engineer juggling between them. The projects are not expected to grow significantly in the near future, each will have 1-3 testers. The projects are not related in any way (well...Android is the underlying layer in both, they use the same devices and share some of the tools). We are considering one of two options, each with its pros and cons:

  1. Have a test team per project, possibly each with a team leader. Pros - testers can be highly specialized, resource allocation is not affected by other projects. Cons- even though the projects are exiting, I am worried from long term boredom. we can't focus effort at peak times.
  2. Have a single test team with a single team leader. Pros - generally resources can be allocated much better. Cons - multitasking tends to harm specializing.

Are there any other options? What to choose?

2 Answers 2


My personal preference is to share resources across features and even products. While working on a single feature or product does increase specializing, that in itself has some associated cons:

  1. If the person specializing in a feature has missed something important and everyone else is not familiar enough with what they are doing to notice it, that could be a problem.
  2. You mentioned boredom - it's easy for someone working on the same tasks day in and day out to go on auto-pilot and again the risk would be that they miss something important.
  3. You also run the risk of someone leaving the team, even temporarily for vacation and having nobody qualified to step in and take over.

Another pro I have noticed is that because people are moving between projects, it forces good practices around documenting processes. Nobody can have some process in their head and not written down.

  • 1
    A + because I totally agree, esp. point 1. Each person having different strengths brings a different critical eye to the same code and thereby the potential for finding different bugs. While it is helpful to assign a 'lead' for each module or feature, it is infinitely more helpful for all testers to know at least a little about every feature. Commented Oct 25, 2012 at 20:43

Both can work, and as you point out, both have pros and cons.

I am currently in a situation where we have insufficient people to be able to dedicate them to any project(s). The juggling between projects is constant, and starting to wear me down. Each day seems like "so which projects do I have to disappoint today?"

If the projects themselves can be effectively scheduled, and the schedule "sticks" to a reasonable degree, juggling folks between projects can work.

If your projects are constantly delayed, extended, or new "phases" are invented that demand immediate attention (as seems to be happening here), juggling people among projects can be a full-time job.

  • Needing to juggle between projects is a common problem, I think. Your last paragraph is my testing life.
    – Kate Paulk
    Commented Oct 26, 2012 at 10:27
  • When I started at my current company, we staffed up for three concurrent threads of development (corresponding to two product lines, and one for infrastructure enhancements). We had little juggling. Over six years later and we are attempting to handle 8 or more projects at any given time, with no additional staff. Juggling happens constantly now. Much more challenging these days, and not as much fun. Oh well... Commented Oct 26, 2012 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.