If you’re not the only tester in your company, then you’ve run into the question of who tests what – QA’s idea of Going Dutch. Before you distribute testing, however, you need to answer a more basic question: do you want your testers to be specialists, generalists or a bit of both?

Specialists: Because the Devil’s in the Details

Specialists will always have a more in-depth knowledge of a section of your product than a generalist of roughly equal experience. The difference will be far more pronounced if you have more than one product, or a very complex product. It’s more than an ability to think of the weirdest-sounding tests, those that seem like a waste of time to all other testers but that end up revealing the major bug; it’s an inherent sense of right and wrong.

Specialists can tell you that something is taking longer than normal without past performance results; they can tell you that something is missing because they know exactly what used to be there; and they can often tell, just from the way the developer explained a new feature, where to start looking for the most serious bugs.

The first problem with specialists is that they can neither help others, nor be helped themselves, if there is unusual pressure on some other testing element. The second is that they leave a huge gap when they quit, especially if they were the only tester with that speciality.

In other words, the trade off is between in-depth knowledge and crisis situations. One solution is to always have at least one generalist – someone who can lend support to an over-worked specialist, and cover for one who quits. Another is to give at least two specialities to each tester, so that there’s always backup.

If your products are stand-alone then specialities, one or more per tester, are enough. If, however, everything you do is connected, it’s vital to keep all of your testers at some generalist level. Don’t let them reach the situation where a new connection between two products, or two sections of the product, leaves them floundering. They should all know enough to deal with each other’s specialities at the interfacing level.

Generalists: Because Your Releases Are not All Equal

If you have a lot of products, but each release only contains a couple of them, specialising will leave some of your testers out of work for every release. Clearly, in this situation you need fast-adjusting generalists. You can also settle for a smaller number of testers – if any tester can test anything, you don’t need a large team for small releases. The same is true if you have one product of low to medium complexity and a limited testing budget.

The price you pay is in quality: generalists are good at everything, but never the best in anything. The benefit is a team that can take on any release with equal force.

You can go for a mixed team, with one or two testers specialising in what you think is most important or difficult, and the others remaining generalists. For example, security testing is best left for specialists, while functional tests can be performed by all generalists.

The Intermediate Approach: Test-Types Specialists

You can divide a team of generalists (or overlapping specialists) into test-type specialists, rather than product specialists. For example, if your products are all for mobile, it makes sense to leave compatibility testing to one tester, while another checks the background processing, and a third checks performance.

Carving up by testing-type can cause an issue when a tester leaves or is over-worked, but a good team should be able to handle it. They should all be familiar with all types of testing anyway, and they all know the whole product, so it’s a minor adjustment relative to the full-fledged specialising of the first section.

Summary

The balance in team testing is between expert knowledge and flexibility. The more complex your releases, the more you should lean towards expertise. As the releases move to being smaller, with a larger proportion of the release being stand-alone and new, so the balance moves towards flexibility.