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.
“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.
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.
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.
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.
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
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://mammoth-ai.com/testing-services/
Also Read: https://www.guru99.com/software-testing.html