With competition and, consequently, user options at an all-time high, QA teams everywhere (esp. those with large distributed user populations) are increasingly looking at testing the performance of their apps at varying bandwidth/network speeds to ensure that ALL users have a consistent experience. This is also an important metric for cellular operators to ensure their customers are receiving a consistent level of service across their coverage area and when they are roaming on other networks.

When testing mobile apps  we are typically limited to running tests on our 100 MBPS wifi network and/or the cellular network which typically ends up being high speed LTE in Downtown San Francisco.  But that i
sn’t a realistic situation for our customers to always be in when using these apps. How will the app function when using slow data when there’s poor connection? Previously, there was no way to test this unless testers went out into the woods to run QA with poor reception.

Now, both iOS and Android come with some built in options to throttle bandwidth wherein you can switch network speed on Android phones in the setting (http://www.csmonitor.com/Technology/2012/0403/32-essential-Android-tips-and-tricks/Switch-between-3G-and-4G-networks) or turn off LTE in iOS (http://www.igeeksblog.com/how-to-use-2g-on-iphone-in-ios-8/) but that presents 2 problems:

  1. The options are limited (e.g. iOS only allows you turn LTE on/off)
  2. Sometimes customer test environments aren’t publically available which leads to an added layer of complexity (VPN/tunneling, authorizations, authentication, etc.) which impedes the automation process  

We (our customers) are increasingly facing this problem & as a result we found this amazing technology to simulate other connection speeds.  We need a way to test applications operating on less-than-stellar network environments to account for features such as when a function should time out, how many times it should try to send data or simply how long it takes to load a view on a lower speed network.

Facebook to the rescue!

Facebook developed Augmented Traffic Control (ATC) and had been using it to simulate network connections since 2013, where they were testing their own apps, until recently when they made the code available on GitHub to open-source the effort.

What it Does:

The Facebook team created the first version of ATC for a hackathon in 2013, which was focused on actually building a working 2G network in order to test making calls, transmitting data, and sending/receiving messages. The project quickly evolved into working with Wi-Fi to simulate networks from there, allowing for more flexibility.

Facebook's Augmented Traffic Control

The framework of Facebook’s Augmented Traffic Control

Benefits:

Now that Facebook has made the code available on GitHub this has expanded the availability of the tool and allows for better testing for all applications. By testing apps running on slow connections this lets testers prepare for how apps should behave when trying to download files with strained networks.

Below is the ATC dashboard:

11057200_345253649006207_376414183_n
We’ve actively started using this as a stand alone uatility and are looking to increase usage and even integrate into our Awetest platform to allow users to run their automated tests across a variety of device-bandwidth combinations.  Below is a video demonstrating the use of Awetest to run an automated test via ATC: