Compatibility For Mobile Web Apps

Introduction

One major problem with writing a good mobile web app, is that it needs to run over ALL of the devices out there. While there a plenty of hacks to get your mobile site to only load/respond on certain device, it’s generally frowned upon, and not best practice. There are multiple ways to set your mobile web app, whether you want a responsive, non-responsive, or separate mobile and desktop sites, the end consumer shouldn’t have to do anything different. They may notice a difference user experience, but this should be the planned intent. This of course, make automated testing difficult.

Test Design

When developing automated tests for the web, there are a bunch of different strategies, but for first timers, I suggest starting with Selenium IDE. Selenium IDE is a complete integrated development environment (IDE) for Selenium tests, and it is implemented as a Firefox Add-On. It allows recording, editing, and debugging tests. Selenium’s own language provides commands for performing actions in a browser (click a link, select an option), and for retrieving data from the resulting pages.

There are plenty of sites and posts out there detailing how to write a good Selenium IDE test, so I’ll leave it up to them. After designing your test, run it several times, and ensure it works properly. It’s not easy as I made it sound, so drop your questions in the comments. So far, all we’ve done is implemented a successful automated web test, and I promised some mobile web app testing. So, let’s get into that. In conjunction with the IDE tests, lets try using the Firefox’s User Agent Switcher. User-agents simulate multiple mobile browser types with little or no cost, with this particular one being free. It will allow our browser to claim it is another device, and so running our web tests will be more similar to running them on mobile tests. Use your User Agent switcher to change to an iPad, Android, or FireOS device, and re-run your test. Did it still pass? What didn’t work that worked before? Resize your browser, and run your tests again. Make the screen smaller to better simulate a smaller handheld device. Again, did your tests still pass? Usually objects will move around, you may need to redefine your locators. Depending on the design of the application, there may even be a different workflow. Is it possible to redesign your tests to be agnostic of these browser types? Keep manipulating your tests until they can pass on multiple device types (keep changing the User Agent Switcher), and multiple screen size (keep changing the size of your browser). Once you get that completed, it’s time to move from Simulation to Emulation.

Into the Cloud

Once we’ve cheaply and satisfactorily tested out your mobile web test on different ‘browsers’ it’s time to see how that simulation holds up against emulators. Tools like SauceLabs and TestingBot have cheap, robust infrastructure already setup, so that you can worry more about testing, than about keeping a clean machine. It’s not too difficult getting your tests to run on SauceLabs,but the first time can be kind of tricky. Interesting in learning how? Checkout the course that I teach here (or email me and ask for more details). So, once we get our tests running in SauceLabs, we can easily expand out our test cases using data parameters. It means you can run your same test on multiple combinations of systems…Sauce offers almost 500 different ones. This allows for some fantastic (and relatively cheap) compatibility testing.