The usage of mobile devices is increasing day by day. It’s becoming hard to find people using desktops unless required by work. A decade ago, having a mobile-friendly website was optional, but now it’s mandatory for any business. Many industries have stopped supporting native desktop applications and only support mobile apps and browsers. If we look at internet traffic, desktop browser traffic has drastically reduced over the past decade. On average, 60% of overall traffic comes from mobile apps and mobile browsers. Previously, to access websites, a person had to be in front of a desktop or laptop. Now with mobile devices, you can search or buy anything online wherever you are. With more advanced technologies like QR codes, you just scan the code, and it opens the browser for the mentioned item, making it a seamless experience for the user.
WAP to RWD
During the initial phase, mobile devices used the WAP browser. WAP stands for Wireless Application Protocol, a standard for accessing information over mobile wireless networks. These browsers, like Opera Mini, were lightweight with minimal space and data requirements. Initially, mobile devices had tiny screens and slow internet speeds, so loading an entire graphic website was challenging. Developers needed to create separate WAP pages for mobile support. Later, Android and iOS entered the market with more space and higher internet speeds. These devices could use better internet browsers than WAP. However, screen size remained a challenge. Developers had to create separate web pages for mobile and desktop browsers. This was overcome by Responsive Web Design (RWD), which helps create web pages that render across different screen sizes and platforms. So, be it a desktop or mobile device, there is no need to develop separate pages; just one responsive design is enough.
Browser over App
Nowadays, most organizations offer mobile app services. So the question arises: why do people opt for mobile websites when there's an app? One reason is that if it's a one-time requirement, very few will bother searching for the app and installing it. Instead, they will use the mobile browser. Additionally, QR codes make it easy to access any product or service - just scan, and it opens the web page, allowing you to either purchase or simply get the information you're looking for.
Why Test Mobile Web
- Ensuring websites render uniformly across devices with different screen sizes and pixel densities. Rendering should be consistent across Android and iOS devices.
- Confirming there are no compatibility issues across OS versions. iOS limits backward compatibility for the OS; Android doesn't.
- Checking compatibility with different browsers like Chrome, Safari, and Samsung Internet.
- Testing the loading time of scripts and graphics. Pages should load quickly.
How to Test Mobile Web
- Functional Testing: Focuses on website functionality, ensuring the web application works as per requirements.
- Performance Testing: Tests the website's performance, including page loading time and behavior under variable internet speeds.
- Localization Testing: Checks how the website operates when the location or language changes, and if website contents adapt to the specific language.
- Real Devices: Testing websites on actual devices.
- Emulators: Testing web browsers on emulators using Android Studio or XCode locally.
- Mobile Emulation on Desktop Browsers: Popular browsers like Chrome, Firefox, and Safari provide mobile emulation in their dev tools options.
- Mobile Device Cloud: Many mobile cloud platforms, such as LambdaTest, BrowserStack, AWS Device Farm, and Perfecto, help test mobile browsers on real devices and emulators.
We can test mobile web applications using the above-mentioned testing methods via manual or automation testing.
Limitations of Manual Testing
Testing mobile websites differs from desktop websites. For desktop websites, we test on the current version and a few previous browser versions. But for mobile, we need to cover different mobile devices. We need to execute the same test cases on various mobiles to ensure functionality and rendering consistency across different browsers, platforms, and OS versions. If we execute scenarios manually, we need a vast collection of devices, which is practically challenging. Also, the time required to cover the enormous device list is not feasible in modern agile projects. Automation becomes the only viable solution to cover testing on all of the devices we need.
Mobile Web Automation
- Cloud Mobile Labs like BrowserStack, LambdaTest, AWS DeviceFarm
- Need to script: The automation team requires a solid knowledge of programming languages to work effectively with Appium. Only skilled individuals can create automation scripts, necessitating more team members with programming backgrounds.
- Code complexity: The main drawback of using scripts is regular maintenance. If we don't execute the scripts for a long time, changes in the DOM element or element locators may cause the script to fail. This may be manageable during the initial stages of the project, but as time progresses, the code becomes more complex, requiring significant time and effort for code maintenance.
- Execution: Appium does not provide emulators or device clouds, so we must rely on local devices, emulators, or third-party tools.
- Integrations: Appium does not provide inbuilt integrations with CI/CD or test management tools, so third-party integrations are necessary.
Cloud Mobile Labs
Having all the physical devices for testing is nearly impossible. Sometimes we need the same device with different OS versions, which also requires a vast infrastructure. Cloud Mobile Labs offer a solution to this limitation. In these labs, they provide real devices or emulators with various OS version combinations. The QA team can use any mobile testing tool and execute scenarios in these labs. Widely used cloud labs include BrowserStack, LambdaTest, and AWS DeviceFarm, which support manual and automation testing.
The major drawback of mobile cloud labs is that they don't have a framework. These tools are primarily for execution, so we must depend on other automation frameworks like Appium to create scripts. Execution can be done in these labs instead of running locally.
Perfecto differs from other cloud mobile labs by supporting the creation of automation scripts using the Quantum framework. Quantum is an open-source test automation framework that uses Selenium, Cucumber, Appium, and Java. Scripts are created using Gherkin language, which follows BDD syntax.
- The QA team needs more development-skilled resources since scripts are created using programming languages.
- The Perfecto environment is slow, with significant delays in device response times.
- Another drawback is that Perfecto restricts the use to one language, compared to Appium, which supports multiple languages.
- There's no monitoring for device errors: If a devices goes offline or there's an error, you have to discover it yourself
testRigor is a modern codeless automation tool widely used by tech companies. It's AI-driven and is packed with many exciting features, making the entire process as efficient as ever. testRigor supports testing for mobile browsers, web apps, mobile apps, and even native desktop apps. This means that anyone on the QA team can create precise lengthy end-to-end tests across multiple browsers and even platforms. Tests are written in plain English, and are as close to an actual user interacting with your application as possible. Large companies typically have to have multiple automation tools for different areas, but testRigor can often replace all of them. Tests are ultra-stable, and test maintenance takes very little time.Here's an example of a testRigor script:
open URL "https://www.google.com" click "Sign in" enter "[email protected]" into "Email or phone" click "Next" enter "my_password" into "Password" click "Next" check that page contains "I'm Feeling Lucky" enter "Let's check Google" into the textbox above "I'm Feeling Lucky"
We don't need to add any element locators such as ids or XPaths in the above example. Instead, we mention the text or position of the element - exactly how a real person would describe it. testRigor's integrated AI captures the different locators of the element, so there's no need to worry about changes in the DOM, as with most other tools on the market. testRigor supports recognizing text in images and verifying text messages or emails. It can be integrated with CI platforms such as Jenkins, CircleCI, Azure DevOps, infra providers like AWS, BrowserStack, LambdaTest, SauceLabs, test management tools like Jira, Zephyr, XRay, and enterprise communication tools like Slack and Microsoft Teams.
testRigor is not an open-source tool; it's a paid one. However, when comparing the costs, testRigor saves a significant amount starting from the first month. The QA team doesn't require SDETs or programmers; manual QA can efficiently create scripts. The speed of test creation is much higher, and test maintenance takes only about 1% of the time. When calculating ROI, using testRigor is more feasible than using any other open-source software.
Mobile devices have become an integral part of everyone's life. When releasing a mobile website, we must follow a proper testing strategy and ensure that the site is easy to navigate and supports any device. A minor issue or gap can cause customers to seek alternate solutions. Selecting the right tool plays a vital role. This article should help you choose the appropriate tools for your needs.