Uncharted Waters

Jul 1 2014   11:21AM GMT

So you want to scale your team

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

You have a team of developers and they have been doing such a good job that you need more of them so they can do more of what they’ve been doing. But your test team is just barely keeping up with things as they are and you only have so much budget to go around. This is a good problem to have, but it is still a problem. If you absolutely can not hire more folks that specialize in testing, there is still hope. There are a few options you can consider that might help you to continue producing that same good software with a minimal staff.

Reduce WIP

Work in progress, multi-tasking, and task switching are great killers of productivity often talked about but seldom killed. A lot of people know this intuitively, but saying no to another feature or an all-important hot fix to production is tough. The more you try to do at once, the less actually gets done and delivered. You don’t have to take my word for it, this is just math. Doing a little less each iteration, and do it better, can help get software from paperwork to production much faster. Your teams can work on several projects at a time, getting a little bit done on each. Or, work on less, hopefully much less, and get the work into production fast.

Improve code quality up front

There are a number of ways you can do this and most involve your development team investing a bit more time in creating a set of tests that get run with each product build. Mike Cohn developed this pyramid to describe how he thought automated tests should be layered to create a maintainable system. At the bottom he hat unit tests which are very small and tend to look at a couple lines of code at most. Above that he has the service layer which is were you will find things like REST interfaces. And above that he has UI tests which tend to be fragile and difficult to maintain. Having a system of tests like this for your project can provide important change detection and help your testers get a better product. This means less time spent testing things that could have been caught earlier and potentially needing fewer testers. It’s not a guarantee of better code, but it can help. Continuous Integration and  a little devOps magic are where you might want to go after this.

Train developers to test

Writing software is an activity that takes skill and dedication. Testing software is no different. Being cross-functional is fairly common on agile teams. Developers test, testers write production code, and everyone is involved creating requirements and whatnot. Cross functional teams mean that you don’t have to worry about a lack of testers of developers slowing down the project because someone can switch into that role if needed. They also mean that you have a group of people with a particularly shallow skill set in some areas that you will occasionally have to depend on. The downside is that you can end up with a group of people that may not excel at anything in particular, but at least you have testing  if you need it in a pinch.

Just hire that additional tester

Most of these suggestions take some time to get to a point where they are actually useful. Reducing WIP can take till whenever the next sprint to start or longer if you are fighting cultural forces that say you need to do all the things NOW. Efforts to improve code quality are always best when started yesterday, or today if you didn’t start yesterday. Training non-testers to test software also takes time and some people just aren’t into it so you’ll not get their best work.

Scaling teams is a tough problem. I’ve seen as many solutions and, well, not great solutions, as I have teams.

How have you dealt with this problem?

How did that work out for you?

3  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • MGEakin
    One thing I always coach is to have the team look at the full test pyramid and identify if any tests are already accounted for at lower levels. For example, you might be able to use only 1 GUI layer password criteria test if you have numerous unit layer test case around the criteria. Fewer GUI & Integration/Service layer tests = (hopefully) a faster tester.

    You might also look at paired-testing with a developer and a tester pairing together. All layer of tests are written by the pair first, then code, then refactor.
    50 pointsBadges:
  • Justin Rohrman
    I'm actually a huge fan of paired testing between developer and tester. Whether the pair is using that as a tool to generate test ideas for something programmatic or testing on a dev environment before checking to reduce churn time, it's all good.

    FWIW I think the GUI part of the triangle should be much much smaller. Unfortunately, GUI tests at scale most often lead to waste and failure. The promise just never came through.
    2,130 pointsBadges:
  • MGEakin
    @Justin 100% agreed. I always coach a much flatter pyramid. Especially as your application grows. Feedback time is critical. It's not as useful to everyone if you are waiting overnight for all of your GUI regression suite to run. It is much more useful if you can bottom-pyramid-load most of your tests where feedback is much quicker and the scripts are much easier to maintain and scale.

    FYI: I wrote a blog on the testing pyramid (http://goofytesterguy.blogspot.com/2014/06/expanding-test-triangle.html) that you might find interesting. Cohn did a great job starting it, Allister's addition was a great add, and I took it to the next level to cover the complete testing stack. Need to work on proportions though..
    50 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: