Testing Mobile Games and Apps

Testing Mobile Games and Apps
When you are constantly creating and developing new mobile apps and games for brands you need a flexible process to ensure that you create and build as efficiently as possible in order to keep costs down and hit deadlines.

Testing is performed throughout the process but predominately at the end of development and inevitably any slippage in design, development, feedback, etc. will eat into testing as deadlines are often immovable.

This puts pressure on the QA team who are responsible for testing across a wide range of devices and operating systems under varying conditions and without requiring an expensive and impractical level of QA resource we need to find ways of overcoming these obstacles.

This is how we test our mobile games and apps before releasing them to brands.

Firstly we acknowledge that the initial testing phase of mobile apps and games is under very sterile conditions, using constant Wi-Fi connections, available devices and various emulators. In the real world there are over 7000 unique types of devices, slow connections, fluctuating connections, dead signal zones and a myriad different ways that consumers may interact with your mobile app.

Automation is impractical with constantly new apps and the endless permutations and tight deadlines so for us the solution is to get our apps in the hands of as many users as possible during as much of the development process as we are able to (keeping in mind NDA’s and the like).

UX/UI Critiques
Get users playing with the app as soon as we have an early working build. The initial wireframes and user interface plans and designs may need tweaking when used on a real device.

Everyone on the team plays
Everyone whether involved in the project uses the app or plays with the game especially non-technical staff. This gives practical feedback on bugs, tutorials and a good insight into how different people interact with the app.

Internal beta version
We then update everyone’s early version with a series of beta versions, the initial ones are often still full of bugs but this is part of the process.

External Beta
This is the first version we release to the client and it’s often a tricky one as we need to explain that there are still bugs (we often list them) but we do require their feedback from a business point of view and for them to test it as a potential target audience.

Crowdsourced beta testers
We have a group of users who have signed up as “beta testers” with us, this gives them access to an early version of the app which they can then test and play with and provide valuable feedback. As this is a random section of the public that have signed up to our beta testing program the feedback is varied with some good insights and sometimes not much feedback depending on the app and if it has taken their interest.

Tracking can be used during the testing phase but is also essential once the app has been launched. Understanding the metrics is key and analysis is needed to find out where users are getting stuck and what parts of the app do they tend to use the most and which the least and why.

Crash analytics is also a part of this and there are specific tools that you can use that will provide data for every crash experienced, however these are normally only used on more complex apps.

Engaging your users
Once the app is launched ensure that you engage your users and that they are aware of the support email and website for your app. Encourage them as much as possible to report any issues directly to you and ensure that you respond to each email as this can help to create a community around your app and will help with your 5 star rating.

All in all each app is different and requires different levels of testing depending on complexity and budgets and as with all forms of testing this is essentially a risk based approach and is not fool proof there is always the risk of bugs slipping through or appearing on arbitrary devices or when interacting with conflicting software.