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.
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?