Team Hierarchies and Communication

For every project, there should be one person in charge of coordinating the various teams. Similarly, there should be one person who coordinates each team and reports to the project leader. This forms a chain of command that can easily be followed when problems within the various teams arise.

This is important for the situations in which one team needs help from one of the other teams; with this sort of chain of command, the leader from one team can talk to both the project leader and the leader of the team they would like help from.

If the team in question isn't too busy, this isn't a problem, and the team lead can agree to help. However, in those stressful crunch times near the end of a project cycle, it's possible that time is too tight to be able to help freely.

In situations like these, it will be up to the project leader to determine if the need is great enough to require the help of the other team or not.

This is why there also needs to be good communication between the teams; when one team is ahead of schedule, it allows teams that need extra help to know where to go to request help first. It also helps the entire team know how they are progressing overall, which allows the team leads and the project leader to be able to better manage the effort overall.

Weekly (or even daily) reports can be very effective in this effort, but even a simple verbal communication between leads on a regular basis can help immensely. A little bit of communication can go a long way to help keep things on track and running smoothly.

Matching the Right Testers to the Right Teams

Needless to say, some people are more competent at certain tasks than others. An effort should be made to match people to the skills they show the highest proficiency in. It can take time to figure out where a person's talents lie, but the effort is almost always worthwhile.

A person who is good at completing games should be assigned to game play, specifically game completion if possible. In this way, that person's talents will help to complete tasks related to checking the overall playability as well as the endings of a game.

Likewise, if someone is good with language and grammar, they should be used for checking the text in the game to make sure it reads as it should. Someone who is talented at noticing problems with graphics should check graphics and animations, and so on. In this way, a team can play to their strengths, and the tasks assigned to them can be accomplished more efficiently.

Weaving it all together

So, now that the general concepts have been put forward, how does it all come together? The first goal would be to set up an appropriate distribution of testing techniques.

A good starting point would be 40% test cases, 30% ad-hoc testing, and the final 30% should alternate until their strengths are determined.

The easiest way to deal with the third group is to assign them any low-priority test cases, as these will be the least detrimental if few members of the group are suited to such tasks. In each of those groups, half should be assigned to white-box testing and half should be assigned black-box testing.

Over the first week or two, it should be possible to determine which testers are best suited to which tasks. After this has been determined, the testers should be separated into the appropriate teams for the necessary testing tasks.

At this point, testing should be redistributed to about 60% test cases and 40% ad-hoc testing, as test cases tend to be more time-consuming, which usually translates to more manpower. Once the teams are formed, test plans should be written for each team explaining how they should go about their tasks and at what pace.

It's important to note that the first week or two is recommended for determining the strengths of unknown testers. If a tester is already known to be competent at certain tasks, it's easy enough to start them in the appropriate team.

Otherwise, it's more valuable in the long run to figure out where a tester would be best appropriated before giving them their final assignment.

Finally, a few words of advice specifically for developers. Documentation for various mechanics and functions can always be helpful. The more information that a testing team receives, the better they'll be able to test the software.

Also, if there's supposed to be any spoken text in a game, try to get the text edited first. In this way, there will be fewer errors in the audio, and the text will not have to be changed to match those errors.

Lastly, ask for the opinions of your testers every once in a while; they may have some opinions that would enhance your software in a way you hadn't considered before. We all want our projects to succeed, and with a little teamwork, we can ship a title with as few errors and as much polish as possible.

---

Photos by choking sun, used under Creative Commons license.