12 scenarios that should not be automated using Selenium
Selenium is a versatile web automation tool that supports multiple browsers, OS and programming languages. However, 100% test automation coverage cannot be obtained using Selenium. There are certain testing scenarios where it is not optimum to use Selenium as a stand-alone tool for automation. This post focuses on highlighting those test scenarios.
Captcha stands for ‘Completely Automated Public Turing test to tell Computers and Humans Apart.’ It is a widely used tool to verify whether the end user is a human or a bot. Theoretically speaking, captchas can be automated if we are able to decode the image using OCR, Optical Character Recognition. To do that we need to write complex algorithms to sort out the image pattern. Captchas are so dynamic that it is tricky and not a good practice to conduct captcha verification using Selenium. The accepted practice while running automation test scenarios for Captcha is to disable the captcha or make it optional in test environments so that skipping it does not fail the automation test.
Selenium does not provide APIs to read barcodes or QR codes. There are some third-party APIs available that can be used to handle barcode/QR codes but using Selenium it is not advisable to do so. Test experts feel there is little real-time purpose to automating these scenarios and verifying it manually could be more efficient.
Two Factor Authentication
Two Factor Authentication mechanisms such as One Time Password validation and push notifications are widely used in web applications today. OTP can be received on email or on mobile numbers, One way suggested is to use Twilio to receive push notifications. It is a platform to set up automated mailing lists, receive response messages, and get verification codes. We need to create a whole project setup along with the required dependencies to integrate this API with Selenium. If you want to avoid this complex process, it is a common practice to disable 2FA in lower-level test environments when initial automation tests are run.
Audio/Video clips/Virtual keyboards
It is not possible to test virtual keyboards using Selenium. For instances where there are virtual keyboards displayed on the UI, those cannot be automated using Selenium WebDriver. Selenium also does not provide a dedicated API to automate streaming videos from social channels, other platforms or even audio clips. There are certain workarounds like trying to test these remotely by passing the URL in StreamTest but the results are not very encouraging. While a lot is happening in the field of AI to verify and validate the quality of video content but it is not feasible to automate audio video clips using Selenium WebDriver.
Windows app testing
Selenium WebDriver is an open-source automation tool for testing web applications. It cannot be used for testing Windows-based applications like paint, or calculator. Other applications like WinAppDriver have been developed which work well on some of the native built-in apps of Windows 10 applications. However, it requires a C# codebase environment to run the first-level automation test scenarios, before configuring it on a CI/CD platform. Popular tools such as Sikuli and AutoIT are also used to test applications of some Windows native components. This practice, in general, is not very helpful and hence not recommended for extensive usage.
Mobile Native Apps/ Mac Apps testing
Selenium automation testing is not suited for testing native mobile applications. Appium is widely used to conduct testing on mobile applications. Just as Selenium cannot be used for testing Windows-based applications, for Mac-based applications also it is not feasible to run Selenium automation tests. However, Appium has a feature of a mac driver which can be integrated with certain Selenium test frameworks to support some basic level of automation on Mac applications.
Social Media application automation
Flash/flex objects /Embed testing
It is a testing type for checking flash-based videos, games, and movies to see if they are functioning as per defined specifications. Selenium provides locators like ID, Class, Name, LinkText, partial link text, and XPath to identify web elements on HTML DOM. But in flash testing, the XPath fails to locate the flash object. This is because Flash files are animated or interactive content for web pages. Flash files are closed files, loaded in containers on a webpage. These containers are embedded in <object/> or <embed/> tags in HTML. Selenium does not provide a method to interact with Flash objects. We have to use ActionScript and a class called External Interface in order to use Selenium to do Flash testing. It is not straight forward and using it will depend upon the ROI of executing it manually compared to automating the feature.
Selenium automates browsers. It does not generate virtual users or generate threads to efficiently conduct performance testing. Selenium standalone is not optimized to check the performance features of an application. There are other tools like JMeter which are much more efficiently designed to do performance testing. Similarly, Selenium does not provide any kind of API for security testing, like, SQL injection or cross-reference testing, or any authentication procedures. So, such scenarios should be avoided. Security testing is of paramount importance in today’s times and most companies have a team of experts using specifically designed security testing tools like JSky, Owasp Zap and Burp suite to conduct comprehensive in-depth security testing of their applications.
Application crawling/link spidering is done to crawl through thousands of web pages links to identify broken links or map the flow of applications. E.g., on any eCommerce platform, we can find that one dropdown will have multiple links which will further branch out into several other links each with its own clickable hyperlinks. It is not possible to use Selenium to efficiently test such kinds of link spiders or crawling links. It is possible to test a given web page and check the hyperlinks on that page using Selenium on a limited basis. But not on a large scale for applications with thousands of links branching out from multiple nodes. There are other widely available tools in the market like Link Validators which can be used based on the requirements.
We can capture screenshots using Selenium but there are cases where we have to visually test whether graphs or some images are visible or not. It is difficult to ascertain such visual images using Selenium and we should avoid doing visual testing using Selenium. It is challenging to accurately test various resolutions or pixel sizes, or screen sizes for making bitmap comparisons. There are other better tools/APIs like the Screenshot API available for efficient visual automation testing.
Large file download
Selenium does not provide a feature where it shows us the bar of progress showing how much download is done, what file size is left to be downloaded, and whether 100% download is completed. Selenium can be used to write automation tests to perform the action of downloading a file to the local system but it cannot validate the progress. The way we test it now is by comparing the number of items in the downloaded folder before and after the download process. It is not a complete and efficient way of handling file download automation.
100% test automation using Selenium is a myth, as there are certain features that can be checked with greater accuracy either manually or by using other APIs. Any kind of non-web-based event cannot be automated using Selenium. Automation is required for the optimum utilization of time, money and resources. Rather than focusing on automating every scenario, it is far more valuable to identify relevant user stories, write production-level gherkins, prioritise what tests need to be automated, and design continuation integration and deployment build in order to create a viable development lifecycle.