4

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?

|improve this question|||||
6

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.

|improve this answer|||||
  • 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. – Laura Hensley Oct 25 '12 at 20:43
4

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.

|improve this answer|||||
  • Needing to juggle between projects is a common problem, I think. Your last paragraph is my testing life. – Kate Paulk♦ Oct 26 '12 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... – Joe Strazzere Oct 26 '12 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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