![]() Special shout out to cloud-based emulator providers like BrowserStack and SauceLabs that offer further options that are not available or practical through OOTB simulators. On iOS, you really only have access to mobile Safari. On Android, you have access to the Android Browser, the Chromium Content Shell and Firefox. Unfortunately, the list of browsers available is limited because you can’t install apps as you would normally on a physical device. ![]() Useful for identifying real mobile browser bugs and for getting a better sense for the page layout within the chrome of the device. With actual device simulators, you’re able to test in a full mobile device environment in the native stock browser. Level 3: iOS/Android simulator with stock browsers Pros - Great for initial checks on basic mobile functionality, constraining to more realistic device screen sizes.Ĭons - While better than simple browser resizing, this method still fails to reveal browser/device bugs and overall performance issues. They also have advanced options to throttle connection speeds and simulate mobile device sensors like Geolocation and Device orientation. Chrome’s Dev Tools Device Toolbar and Firefox's Responsive Design Mode are great options here, useful for deeper dives when special consideration is needed for mobile features like touch events. Level 2: Desktop browser mobile emulators Pros - Quickest and easiest, readily available all the time.Ĭons - Not indicative of the mobile user experience, browser bugs, or touch events. When you’re still working out your breakpoints and how page components will react to different screen sizes, it’s nice to see how it stacks across them all. Resizing a desktop browser down to mobile sizes is useful as a real-time sanity check during initial development. Level 1: Resizing a standard desktop browser So let's talk about the four levels of mobile browser testing and how each can fit into your workflow. There’s no timeline short enough, no site simple enough, and no budget small enough to completely cut testing out of the process altogether. ![]() This sets the clearest constraints that we need to work within.ĭepending on the answers to the questions above, I concede that compromises may be necessary, but you will still need to do some mobile browser testing. Who is your user?ĭo you have any analytics or insight into your audience and browsing behavior? Ideally, what are your priority devices? What’s the timeline and budget? Is this going to be a one-off promotional project that will disappear in a couple months? An evergreen application critical to business success? What’s the scale and complexity?Ī small promotional site or a large multi-site system? It’s also a good idea to factor in the inherent complexity of a CMS if one will be used. But first, you need a general understanding of the project. Planning out your testing strategy is crucial. We have sophisticated build tools, automated testing, design systems, and an unending onslaught of acronym-named projects at our disposal, but there’s no replacing manual testing. So how do we manage the growing complexity of development and testing within the constraints of time and budget? In this article, I’m going to share some tips that will help you embrace the constraints of your projects while testing in mobile browsers. If there’s one item that doesn't change from project to project, it’s timelines and budgets.
0 Comments
Leave a Reply. |