4

I've become a leader of a group of 30 developers. We run Scrum and we have different teams for each Product Backlog.

We have no testers across the teams and I'd like add them.

My main question is:

1. Creating a different backlog and a Testing Team, where they would be shared among all Product Teams?

Pros: We could hire less testers

Cons: We could create a bottleneck to Tests Team

2. Hiring Testers for each Product Backlog

Pros: We have no bottleneck cause each Tester is allocated to a specific product

Cons: We have to hire more people.

Our goal is: Deploy the code developed in the sprints strongly tested.

Based on your experiences, which option do you think should work better under which circumstances?

Improve this question
5
  • 1
    You have listed pros and cons, but no actual question. What are your goals? As it is, I would flip a coin because I have no idea which option meets your requirements.
    – user22815
    Oct 22, 2015 at 2:43
  • 1
    @Snowman, you're right. Just edited the question
    – user31566
    Oct 22, 2015 at 3:07
  • "Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule" - Scrum has very few rules so if you break something like this it means you aren't doing Scrum. Maybe you disagree with that rule, as so many people answering here. That's fine, but if you do follow that advice you should make it clear to you dev team and other stakeholders that you are no longer doing Scrum.
    – Nathan
    Oct 22, 2015 at 14:45
  • @Nathan So how would scrum deal with testing? "Scrum doesn't differentiate between developers and testers" is hardly helpful. What is the scrum way to deal with testing; have everyone deep testing? Saying something this critical is "off spec" is a tad damming of the whole thing
    – Richard Tingle
    Oct 22, 2015 at 18:15
  • @RichardTingle Yes, the scrum way is to have everyone deep testing. Scrum developers are supposed to be multi-skilled, meaning good at analysis, good at programming, and good at testing. The fact that finding such people is difficult makes scrum much harder than the marketing would suggest.
    – Matthew Flynn
    Oct 30, 2015 at 16:15

5 Answers 5

Reset to default
5

We could hire less testers / We have to hire more people

That is a misconception. The total amount of testing work is still the same in both scenarios. And if in scenario two a tester dedicated to one product would run "out of work" because there is not enough to test to give him 8 hours work per day, you would probably assign him testing work from a different product either (at least, temporarily).

We have no bottleneck cause each Tester is allocated to a specific product

Same as above - you can still get a bottleneck because there could be too much to test in one product for a single person to meet your schedule.

What you should ask yourself instead is: are the different products mostly independent from each other so they can be tested individually? And do the different products need very specific knowledge to test them well (which means testers have to specialize for each product)? Then it makes sense to assign each product one or more testers as "experts" for this product.

On the other hand, if your different products are just parts of an application system, with heavy interaction between them, then assigning different people strictly to different products does not make much sense (remark: that might not only be true for your testers, but also for your devs). And even if not, if the products do not need specific user knowledge so anyone with a test plan can start testing the thing immediately, the option of shifting testers between products makes your team more flexible and helps to avoid bottlenecks.

Shifting people between different teams, however, comes always for the cost of more communication and organizational overhead - when a team can work completely on its own, it might be much more efficient as when when some of them have to work on different things in parallel. You will have to decide for yourself what works best in your case.

Improve this answer
1

If you're actually doing scrum, rather than something with a few Agile principles which you're calling scrum, then this is easy as there are only three roles in scrum: the product owner, the scrum master and the development team. You can't have a separate "test team" because a feature isn't finished until it's been tested, so your test function has to be part of the specific scrum team.

If you're not actually doing scrum, then do whatever works best for you. I don't actually understand how you're doing product development at all without some testers, but that's a different issue.

Improve this answer
11
  • Scrum as described in text books is always described as a scenario of one small team, for one product. The OP's situation is more complex, there are multiple teams and different products involved.
    – Doc Brown
    Oct 22, 2015 at 5:57
  • 3
    Scrum is juts a start point, not a fixed methodology. Thinking of Scrum as some unchangeable holy scripture is missing the point of it entirely.
    – gbjbaanb
    Oct 22, 2015 at 7:39
  • Not doing 'official' Scrum and then saying it doesn't work is slightly annoying though. I guess the 'official' answer is to improve your feature specs until the acceptance test can be demonstrated at the end of the sprint
    – Ewan
    Oct 22, 2015 at 13:29
  • 1
    @gbjbaanb No. Scrum has very few rules, so yeah it is a starting point. But if you do starting breaking something from it's very short list of explicit rules, like by seperating dev and test effort, you aren't doing Scrum and should stop pretending you are.
    – Nathan
    Oct 22, 2015 at 14:37
  • @NathanCooper what you've just said is that Scrum is not Agile. Fair enough - I always found Scrum to be too heavyweight a process to be agile. Remember: Agile says "people not processes", if your process is so constrained and rigid, its not Agile. (the Guide also says there are no testers in Scrum, all members of the dev team are developers. So if you want to do scrum, call those testers devs and let them code - the Guide also says the team is self-organising and anyone can work on any part of the tasks!). So, if you have testers.. then you're not doing Scrum :-)
    – gbjbaanb
    Oct 22, 2015 at 14:53
1

I think it depends what you want your testers to do. In some cases a tester is a developer, writing unit and other automated tests. In some cases they are manual testers who write and/or run through test scripts. In some cases they are implementation engineers who test that the product delivery does what the requirements actually wanted.

In these cases you need a different deployment of testers. In the dev-tester, he needs to be part of the dev team with knowledge of the development changes. In the requirements-tester he needs to be part of the product team with knowledge of the product delivery.

QA is another interesting aspect - in this case its more of a deployment/production team that are very disconnected from the development process. (ie you drop them the final shrink-wrap product that will, if passed, be given to production).

So - as with so many things - a bit of a mix is appropriate. I found a tester per team works very well as they need the knowledge of the product the team is working on to help test it efficiently. But the testers who are assigned to the product are also very important as they're the ones who tend to know all the social, configuration and customer history of the product that often gets lost between developments.

Improve this answer
1

I would strongly recommend having the testers part of the development teams rather than as a separate function. This is for three main reasons, based on my own experience managing teams organised in both ways.

  1. Testing can be done as part of the sprint (you say you're doing Scrum) meaning a more complete Definition of Done for your teams and less chance of rework down the line.
  2. Testers can work more closely with the development team which can actually reduce the amount of testing which needs to be done. This can be because a tester and developer pair up to test and fix something in parallel. Or, testers are involved in the planning so can guide developers as to edge cases they should consider. And finally, testers being part of the planning and working closely with the developer lets them more easily work out what does and doesn't need re testing after each change is made.
  3. Finally, you maintain a nice team focus rather than any us vs them feeling between the development teams and the testing team. This is not guaranteed to occur with the other set up but having your teams split like this can lend itself to such behaviour.
Improve this answer
0

In my experience testing a feature usually takes longer than developing that feature. So if you have pure test roles you are going to need more testers than developers.

However, this can vary greatly depending on how much test automation you have in place and how specific your feature requirements are. Similarly, if you have very tight specs, the amount of product specific knowledge needed to test a feature is less, you can test it just from the description. Whereas with a looser spec you would expect the tester to use product specific knowledge to fill in the gaps. ie 'ahh but when the app is in state X the feature fails'

Given that you are worried about resourcing and bottlenecks I would suggest that you modify your scrum process to include some of the concepts from KANBAN.

Here you assign a volume to each stage of development, and only move a task into the next phase when there is available capacity. This makes it very clear where the bottlenecks in your process are and gives you a rough idea of how much more resource you need to assign to that area to clear them.

Improve this answer

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