In September last year, the sequel to the popular game Destiny was released. Somewhat predictably titled Destiny 2, it was a lot of fun. It would take a whole post to explain the game and its objective, but the headline is that it’s an online multiplayer game that relies on cooperation and teamwork to complete the missions. To that end, when you create your character you can choose to be one of three classes; Warlock, Hunter or Titan.
The Warlocks are very balanced with an ability to inflict a good amount of damage, either close or long range. They have wizard-like abilities, making them the perfect all-rounder.
The Hunter is more likely to be found hanging back supporting the group from a distance, providing covering fire and using their precision with a rifle to make life easier for those more central to the fray.
The Titan is the Hulk of the group. It jumps in often blindly, punches and shoots whatever is nearby, then gets killed for its efforts, being forced to lie impatiently and wait for one of the other players to revive them.
Initially we all just picked what we thought looked coolest. I was a Hunter because they had cool jackets, and my friends, Jessie and Scott, both chose Warlocks because they looked all magical and glowy. We were a bit rubbish. Not individually but as a group, we weren’t progressing as well as we had hoped, and the fights didn’t feel balanced. But it was only when all of these roles had been filled that the game started to make sense. Missions ran smoother, fights ended quicker, and everyone found their place in the group. The contrasting styles complement one another and everyone benefits.
The Tenuous Connection to Testing
There are very few similarities between software testing and the video game Destiny 2, you won’t be surprised to hear. However, one thing they do have in common is, when you have members on the team with different skills and approaches, it makes the team stronger.
If you had a team full of testers who prioritise just one thing, usability for example, and employ the same approach, such as exploratory testing, then the range of issues and information you discover will likely be quite narrow. However, If people have different specialisms, and different approaches to the testing, you’ll find a much broader range of experience that can be used and utilised by the development team, and maybe even the wider company.
You wouldn’t hire a development team comprised of developers with the exact same skills. You want different specialisms. You want front-end guys, back-end guys, database guys etc. The exact same thing is true for testers. You may not necessarily use the terms ‘front-end tester’ or ‘back-end tester’, but skill variations should be kept in mind when building an effective team. Everyone has different specialities, everyone had different strengths.
On top of things like technical backgrounds or general focus, there are also various types of testing. Below is a quick list that is no way definitive or complete:
Just by looking at this list, it’s obvious that you could not expect one solitary tester to excel at all of these. Good at a few, sure. Maybe adequate at most, fine. But you’re not going to find someone that’s good at all of them, so variety within your team is critical.
In conclusion, it’s unlikely that you’ll be able to hire one person for each speciality, and probably wouldn’t need to. You should however, be able to build a balanced team by attempting to touch on each testing aspect that you require when hiring, or training your team.