It’s vital to outline exactly what you intend to automate from the get-go. This decision requires a high-level understanding of your game, engine, and the software you’re working with. From there you need to identify the modules and functions that are possible to automate.

High-impact areas worth considering include functional testing, regression testing, and your testing processes (see our blog post for help on what can be automated).

With these requirements in hand, it’s time to build a strategic system that can execute these demands. And that requires a robust and adaptable automation framework.

In more simplistic terms, automation frameworks take plain-language test cases written by manual testers and maps them to test scenarios using program code. The program code then carries out the actions described in by the test cases and publishes the results.

That being said, feature and design changes tend to be prevalent, so whatever framework you select must be as adaptable and modular as possible. This will allow you to update a test suite as quickly as possible when design changes do occur.

With a clear idea of the areas you’re planning to automate and a framework in mind, it’s time to turn your attention to the tools needed for the job. Both the framework you’re using and the individual automation scripts you’re planning to create need different tools depending on the platform and type of automation. Here’s a look at a few of the automation tools out there.

Now it’s time to create your automation scripts. Your testers need to meticulously document exactly what you’re trying to test so your engineers can turn those test cases into automated scripts.

A common first-time mistake is to record manual QA engineers actions and replay them during an automated run -- a seemingly simple idea with a simple implementation that allows the reuse of knowledge. However, experience shows that recorded tests rarely survive system changes. Logs, produced by recording software, are often unmanageable and need to be re-recorded for every system update, nullifying your entire effort.

This is where the hours spent writing test cases and converting them to automation scripts pays off. Hit the go button and set those automation scripts upon your game.

Running your automated tests on every new game build can verify if that build is ready for manual quality assurance within hours. And if the build is broken, you know before it’s released to a test team -- a huge time saver.

Once your automation initiative is up and running, there’s still a serious amount of upkeep required to keep everything running smoothly.

At a granular level, this means frequently checking the success rates of each automated test case as well as individual scripts when new changes are introduced. Version control is huge here, too. If you’re versioning after every update, you can quickly discover when scripts have broken, track down the cause, and modify accordingly.

Zooming out, your framework also needs ongoing maintenance to keep up with system changes and new requirements.

In-House Vs. Outsourced Automation

There it is, how to run an automation initiative. But before you start it’s important to know whether an in-house or outsourced approach is best for your game -- and there are definite benefits and downsides to both. Here what you should ask yourself going in:

• What’s my budget?
• What’s my timeframe?
• Do I have a long-term vision for how automation fits into my project?
• How does automation work for the type of game I’m building?

Sure, these questions will help you decide which option works best for your game. But it’s also important to understand the upside and downside of each option…