While there are many cases in which test automation makes sense, some test scenarios should never be automated using technology like Selenium WebDriver in the browser.
Here are ten examples, along with my explanations for why automation isn’t a good idea in each of them. I’ll also give you an alternate approach for each.
1. CAPTCHA
“Completely Automated Public Turing Test to Tell Computers and Humans Apart,” or CAPTCHA, is an acronym for “Completely Automated Public Turing Test to Tell Computers and Humans Apart.” It exists solely to avoid automation; thus, it isn’t worth attempting. Otherwise, it will fail to be CAPTCHA since it will be unable to distinguish between humans and machines.
There are two main methods for avoiding CAPTCHA checks during testing. The following are the details:
- In your test environment, turn off CAPTCHAs. This could be a simple setting in the software that’s being tested. This could also be a URL parameter set by the test.
- To allow tests to overcome the CAPTCHA, add a hook.
2. Visual testing
Checking how a page renders and appears to the end-user is known as visual automated testing. This is really useful for testing on a variety of devices and screen resolutions. Many of us attempt this by using code to check for the presence of dozens, if not hundreds, of components on a single page. For this, WebDriver is not the right tool.
3. Two-factor authentication
Two-factor authentication is another circumstance that you shouldn’t automate through UI (or 2FA). This is where a one-time password is generated and distributed through SMS or email using “authenticator” mobile apps like Google Authenticator or Microsoft Authenticator.
It’s a big problem to automate it in Selenium, but that doesn’t mean it’s impossible. While it is possible to automate it, it is an additional layer to add and is not as secure. As a result, it’s advisable to avoid automating it entirely.
The following are the three ways to get around 2FA checks:
In the test environment, disable 2FA for specific users so that you may use their credentials in the script.
In your test environment, turn off 2FA.
If you log in from a certain IP address, disable 2FA. (You may avoid this by configuring the test machine IPs this way.)
4. File downloads
Because the API doesn’t expose download status, automating file downloads through the UI isn’t ideal. Downloading files isn’t a need for simulating user interaction with the online platform.
As a result, you might consider completing this workaround: use Selenium to find the URL, as well as any required cookies, and feed it to an HTTP request library like REST Assured (Java), fetch (JavaScript), or libcurl (cross-platform).
5. HTTP response codes
HTTP status codes are the standard response codes that website servers use on the Internet. When a web page or other resource fails to load properly, the codes assist in determining the source of the problem. Checking the status code is not a very relevant feature of a test’s failure in automated functional testing; the procedures that came before it is more important.
API testing should be kept at this layer. WebDriver isn’t a tool for testing APIs. As a result, libraries like REST Assured (Java), fetch (JavaScript), and RestSharp can be used (.NET)
6. Gmail, email, and Facebook logins
Gmail, email, and Facebook logins are other instances where UI should not be used to automate. Using WebDriver to log into these types of sites is not recommended. It’s against the terms of service, as well as slow and unreliable.
Longer tests are, on average, more unstable and unreliable, putting you in danger of the test failing. Tests lasting more than 2 minutes are twice as likely to fail, according to a study of over 2 billion tests.
Instead, use the APIs provided by email providers or, in the case of Facebook, the developer tools service, which provides an API for generating test accounts. (The Gmail API can be found here.)
Using an API may appear to be extra labor, but it will pay off in terms of speed, dependability, and stability. It’s also doubtful that the API will change. Web pages and HTML locators, on the other hand, change frequently, necessitating the updating of your test framework.
7. Performance testing
Selenium and WebDriver performance testing isn’t recommended because it’s not optimized for the job and you’re unlikely to get good results. WebDriver tests are vulnerable to a variety of external and internal factors beyond your control.
Browser startup time, HTTP server response time, a third-party server response time that hosts JavaScript or CSS, and the WebDriver implementation’s instrumentation penalty, to mention a few. Your findings will differ as a result of this. You’ll get a slower performance test that covers both the backend and the frontend.
Instead, for front-end performance, use a free tool like Google Lighthouse. Then, using a free tool like Apache JMeter, do a separate load or stress test.
You must be able to examine overall performance independent of environmental differences, detect poor code practices, and break down the performance of specific resources in order to figure out what has to be improved (i.e., CSS or JavaScript).
8. Link spidering
I don’t recommend utilizing WebDriver to crawl across links (link spidering). You can accomplish it, but WebDriver isn’t the best tool for the job because it takes a long time to set up. Just getting to the page and traversing through the Document Object Model can take up to a minute, depending on how your test is designed.
Furthermore, it is a waste of time to write the logic for browsing pages and catching links.
There are far simpler solutions than utilizing WebDriver. A short Google search yields the following two free tools:
- brokenlinkcheck.com, which found all the broken links on my site in a matter of minutes
9. Video streaming
Although video streaming is growing increasingly common, you may not want to automate it with UI. Selenium will almost never be able to recognize video controllers. To some extent, JavaScript Executor and flex-ui-selenium will work, although they are not completely dependable.
Instead, utilize StreamTest, a free application that measures the quality of the end user’s experience. You can also include monitoring.
10. Crash recovery
Recovery testing is a type of software testing that examines a program’s capacity to recover from failures like software and hardware crashes. You might want to put your app’s crash recovery to the test. It’s preferable to test it by hand. It’s not that Selenium can’t be used to test it; it just isn’t practical or beneficial.
Data is obtained from several stages of development, such as the design and operating stages, for dependability testing. Due to constraints such as cost and time constraints, the experiments are limited.
Use alternative tests for these situations
These are the top ten circumstances that you should avoid automating using UI. You can use them as a reference when you’re working and attempting to figure out the ideal technique for developing coding, and testing.
Although various solutions exist, it’s always a good idea to think about why these particular aspects shouldn’t be automated in the first place.
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html