CS 415 - Agile Game Development

Agile Technology and Quality Assurance

Reference: Clinton Keith, Agile Game Development with Scrum, Chapters 10 and 13.

The Big Picture

Technology creation is the greatest area of risk for many video game projects. Video games compete on the basis of technical achievements as much as gameplay and visual quality. The following technical problems have the biggest impact on development in both traditional and agile projects.

Agile Engineering Disciplines

By design, Scrum lacks any engineering practices, but they can be adopted from Extreme Programming (XP), a more engineering-centric agile methodology.

Test-driven development (TDD) practices include writing a number of unit tests for every function created by the developer. Each unit test will exercise the function by passing in data and comparing what the function returns or changes with the expected (correct) output. Unit tests and their associated code are built in parallel. A continuous integration server (CIS) runs all the unit tests and it catches a majority of the problems usually caused by commits. When a submission breaks a unit test, the CIS informs all developers and makes it easy to identify the submission that broke the build. Otherwise, the changes are synchronized among all developers.

Refactoring calls for creating the bare minimum of functionality to respond to the current needs and expanding and generalizing the code later, if/when additional functionality is required. TDD requires "constant refactoring" and leads to higher quality code that more closely matches the final requirements (which may have evolved during the project).

Pair programming principle calls for two developers using a single workstation with one (driver) typing the code, the other one (observer) reviewing the code as it is typed. Driver and observer frequently swap the roles. Benefits of pair programming include:

Possible problems with pair programming include (but all of them are reasonably easy to avoid or resolve):

Agile Approach to Debugging

One of the biggest differences between an agile game development project and a traditional game development project is how bugs are addressed. In many traditional projects, finding and fixing bugs does not happen until the end when quality assurance (QA) focuses on the game. The resulting rush to fix defects usually leads to crunch. Agile methods add QA early in the project and address bugs as soon as they are discovered, thus significantly reducing the amount of time and risk during the alpha and beta portions of a project. When a bug is identified, either a task to fix it is added to the sprint backlog (when the bug is small enough to fix and it is related to the sprint goal) or a story to fix it is added to the product backlog (when the bug does not impact a sprint goal, cannot be solved by the team, or is too large to fix in the remaining time of the sprint).

Agile Quality Assurance (QA)

Black-box testing uses a player's perspective to test a game at the highest level. A tester is given a list of expected behaviors and the conditions or input for causing them. The tester then ensures that they occur. It's also meant to ensure the pacing and mechanics are fun and engaging.

White-box testing uses an internal perspective to test a game. The components of the game, from code to assets, are examined and tested for standards and functional compliance. This requires skill and experience in the discipline that created the code or asset to be tested.

Principles of testing in an agile process:

The role of QA in an agile team:

Play-testing is a practice where consumers are lured in to play a game in development and provide useful feedback about the gameplay experience.

Halo 3: How Microsoft Labs Invented a New Science of Play