Thursday Thoughts


Involve Test Early and Often

Time for a bit of rambling ranting on a topic that I have perceived and grumbled about for a long time:

Why is test often integrated into the design and production of a product, particularly games, so late in the life cycle?

As games get larger and more complex, there becomes a lot more that could break and hence more work for test. While the software industry as a whole has been trying to move to embrace “agile development”, “scrum teams”, and other PM and Dev styles that integrate testing at the start, game studios seem to be stuck in more traditional methods. I find this ironic, since many of the computer/video game pioneers essentially ran their teams/companies in what today would be considered extreme agile development.

The idea is that a lot of what Test does involves documentation, and by this I don’t just mean a bunch of files that describe this or that, but the actual test cases, test suites, test “plans”, test procedures. These are the items that the testers use to do their job, and if a team is dropped into a project in the middle they have a lot of catch up work to do.

If Test is represent even at the earliest design meetings, they can start creating test cases for those designs, convert those to tests for prototypes, and so on and so on. Will a lot of that work be trashed? As often as game designs change, yes that is a possibility. Though instead of trashing, track those changes, use previous work to build upon the next so you don’t have to start from scratch each time.

Another benefit to Test being there early and often is understanding of the designer & programmer vision, timely knowledge of changes, and why a change was made. Often unintentionally test teams are end up segregated from the design and programming teams, its almost an US vs THEM feeling that can arise. When in it should be a “we are all in this boat together” environment. Have Test involved from the start, even if its just a single Test Lead, and actively keeping the team as a whole involved will do a lot to help foster a inclusive attitude.

As a production starts to ramp up and more testers are brought on board, I think they should be located right in the middle of the developers working on the features they are testing. Testers should “know” the people producing what they are testing, and the programmers/designers/artists should “know” the tester. The tester should be involved in all the meetings related to their features, and I would even go as far as to allow them a voice in those meetings. They might have experience that gives them insight into how something may or may not work, or a suggest on how to attack testing a proposed feature/function.

Again “scrum” , “agile”, and “test driven” development are just a few of the ways the larger software industry is working to improve the process of creating software, and a few studios are experimenting with similar setups. I think that’s great, but I know its hard to covert established processes to new ones overnight. So I suggest taking one baby step: Invite a dedicated tester to sit in on your design meetings, starting with the very first.

,

Leave a Reply

Your email address will not be published. Required fields are marked *