One of our web applications is designed to present one User Interface when viewed from a desktop system, and a different User Interface when viewed from a mobile device or tablet. That way, the UI can be more tailored to the capabilities of the device being used. copyrightjoestrazzere
In order to accomplish that trick, we use WURFL to detect the device type from the User Agent String, and tell the web application about the device being used. When WURFL tells us that it's a mobile device or tablet, a redirect occurs - into the mobile-optimized UI.
When testing this application, we used a wide variety of mobile devices. We used desktops, phones, and tablets. But the vast majority of functional testing was performed using just a desktop system and a few tricks. Those tricks allowed us to "fake out" the web application, and make it think that the requests were actually coming from a phone or a tablet.
WURFL (Wireless Universal Resource FiLe) is an API and database that uses the User Agent String sent with every web request to determine characteristics about the requesting environment. Properly used by the web application, the API can divide the requests into desktop requests versus phone/tablet requests.
Normally, your browser presents the web application with a User Agent String that reflects the characteristics of your actual device, operating systems, browser, etc.
For example Chrome on Windows 8 might present this for a User Agent String:
Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36
While Safari on an iPad might present this:
Mozilla/5.0 (iPad; CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko ) Version/5.1 Mobile/9B176 Safari/7534.48.3
Thus if you could tell your browser to use a "Safari-in-iPad" User Agent String, the web application would think you were actually coming from an iPad, and redirect you to the Mobile UI. This is exactly what we did.
We used two different ways to fake the User Agent String. Primarily, we used Firefox and the User Agent Switcher from Chris Pendrick. We also used Chrome and the command line switch --user-agent.
By faking the application out, we tested both the desktop and the mobile UI from the same browser on the same desktop machine. This saved us a lot of time, and made it far simpler to automate as well.
Sometimes faking it is easier, and more efficient as well.
User Agent String:
http://en.wikipedia.org/wiki/User_agent
WURFL:
http://en.wikipedia.org/wiki/WURFL
For Firefox:
User Agent Switcher
Chris Pederick
For Chrome:
Override User Agent
http://peter.sh/experiments/chromium-command-line-switches/#user-agent
This article originally appeared in my blog: All Things Quality
This article originally appeared in my blog: All Things Quality
|
My name is Joe Strazzere and I'm currently a Director of Quality Assurance. I like to lead, to test, and occasionally to write about leading and testing. Find me at http://AllThingsQuality.com/. |
Faking is great, and can be used to test layout and rendering issues specific to different device/browser types.
ReplyDeleteBut do you still have to do some manual testing or automated testing that specifically targets things like a mobile device browser without the faking? I assume faking can't test for things like mobile swipes, touch, and gestures that an actual device or simulator can provide.
Thanks, man9ar00! Yes, you still need to perform some testing on actual devices. As you indicate, swipes, multi-touches, getstures, low-battery conditions, etc - all must still be tested on at least some specific devices. Out application doesn't use any swipes, multi-touches, or gestures, however. So perhaps we can use faked agent strings for a higher percentage of our testing than most. As always - there's no one best way. Everyone needs to analyze their own requirements, and use their best judgement as to their test approaches. Context is everything!
ReplyDelete