24 Selenium Testing Scenarios You Shouldn’t Automate

Short answer: Selenium’s official documentation discourages eight categories of browser automation: CAPTCHA challenges, file downloads, HTTP response codes, Gmail/email/Facebook logins, dependent tests, performance testing, link spidering, and two-factor authentication. This guide turns those categories into 24 practical examples—three under each. The examples are an editorial checklist, not a 24-item list published by Selenium.

Use Selenium when a real browser interaction is essential to the behavior you need to verify. For a lower-level requirement, choose a unit test, an HTTP-level check, a focused integration test, or manual testing when that is the sensible short-term option. Selenium describes its test-practice recommendations as contextual guidelines, not universal laws. Selenium: Discouraged behaviors · Selenium: Overview of Test Automation · Selenium: Test Practices

How to use this 24-scenario checklist

For each candidate test, ask whether the requirement depends on a real browser, whether a cheaper test level can answer it, and whether the test can remain independent and short. The situations below explain why Selenium is a poor fit and point toward a more direct way to check the requirement. Those alternatives are practical recommendations; Selenium’s official page names the discouraged categories but does not prescribe a specific replacement for every application.

1. CAPTCHA challenges

A CAPTCHA is designed to distinguish people from automation. Making a browser test solve it turns a product test into an attempt to defeat an anti-automation control. Selenium lists CAPTCHA as a discouraged behavior.

Automating a public signup CAPTCHA. A test that tries to solve a CAPTCHA on the live signup page is brittle and crosses the purpose of the challenge. Coordinate with product and security teams on a controlled test-environment approach if signup behavior needs coverage.
Retrying a CAPTCHA until the provider accepts it. Repeated attempts can trigger rate limits or risk controls, and success depends on an external challenge. Test your application’s response to a controlled verification result instead.
Testing CAPTCHA appearance across every browser run. Challenge rendering can vary by provider, risk score, and environment. Keep the verification integration in a controlled test and reserve a focused human check for the actual challenge experience when needed.

2. File downloads

Selenium’s discouraged list includes file downloads. If the requirement is that a file was generated correctly or an endpoint returned the expected bytes, a browser download flow often adds setup and state without providing the best evidence.

Checking CSV contents after clicking Export. Prefer a direct test of the export-generation logic or endpoint and assert the returned content, headers, and representative rows. Use a browser test only if the user-visible export control itself is the requirement.
Verifying a PDF’s pages and text through a downloaded browser file. Test the document-generation output through the application’s generation path and inspect the resulting file with an appropriate parser. A browser test can separately establish that the download action is available.
Testing a large download’s transfer behavior in WebDriver. Browser startup, download preferences, filesystem access, and network conditions can obscure the behavior you intended to measure. Use a direct transfer-level check for response and payload behavior; use a browser test for a concise user workflow if that interaction matters.

3. HTTP response codes

Selenium discourages using browser automation to check HTTP response codes. When the requirement is about the transport response, observe the HTTP request directly; browser page state is indirect evidence.

Checking that an API returns 401 without credentials. Send an HTTP request without credentials and assert its status and response shape. A browser interaction is unnecessary unless you are also checking how the interface presents the unauthorized state.
Checking that a missing route returns 404. Request the route directly and assert the status. Keep a separate browser test only if the rendered not-found experience is important to users.
Checking redirect status and destination. Use an HTTP-level test to inspect redirect responses and their location. A Selenium test can verify that a user lands on the intended page, but it is a less direct way to test the response code itself.

4. Gmail, email, and Facebook logins

Selenium groups Gmail, email, and Facebook logins as discouraged behaviors. Depending on a live third-party login introduces external availability, policy, and interface changes into tests of your own application.

Signing into Gmail to find a password-reset email. Test your application’s reset request and token behavior through controlled test interfaces. If email delivery is part of the requirement, verify delivery through an environment designed for test messages rather than a live consumer inbox.
Logging into Facebook to exercise social sign-in on every run. Test your application’s callback and account-linking behavior with controlled identity-provider responses. Keep any necessary provider certification or compatibility checks separate from the routine application suite.
Using a live email account as the only way to create test users. This makes test setup dependent on an external login flow and shared account state. Use isolated test data and a controlled setup path, then test the application behavior that matters.

5. Dependent tests

A test should not need another test to run first or leave behind state. Selenium discourages test dependency and encourages independent tests. Dependencies make order, retries, and failure diagnosis harder.

Test B assumes Test A created its account. Each test should arrange the data it needs or use an appropriate isolated fixture. A failure then points to the scenario under test, not an earlier setup step.
A checkout test relies on a previous test’s cart. Create the cart state for the checkout test itself through a controlled setup path. Keep the browser actions focused on the checkout behavior the test is meant to establish.
A test suite depends on a specific run order or shared browser session. Make tests safe to run individually, in a different order, or after a retry. Avoid shared mutable data that one test can change for another.

6. Performance testing

Selenium discourages performance testing with WebDriver. Browser startup, WebDriver instrumentation, network conditions, and third-party resources can affect measurements independently of the application behavior you want to understand. Choose a performance method that measures the specific question directly.

Using browser-test duration as the page-speed score. A functional test’s elapsed time includes automation and environment overhead. Measure the intended page or resource behavior with a method suited to that metric, and use browser automation to verify user-visible functionality.
Launching many WebDriver sessions to simulate production load. Browser sessions consume resources and add sources of variability. Use a load-testing approach designed around the system’s expected traffic and the service behavior being measured.
Comparing response-time regressions across shared CI workers. Shared infrastructure and changing external conditions can swamp small differences. Run performance checks in a controlled setup and interpret them separately from functional browser-test pass/fail results.

7. Link spidering

Selenium lists link spidering as discouraged. Crawling every link is a site-inventory or link-validation task, not usually a user workflow. Keep Selenium tests focused on a specific behavior that requires a browser.

Opening every internal link to inventory the site. Use a crawler or a link inventory derived from the site structure. A small browser test can still verify a key navigation path a user depends on.
Visiting every page to find broken links. A link checker or HTTP-level validation is more direct for discovering broken destinations. Follow up with browser coverage for important rendered navigation behaviors.
Recursively exploring every outgoing link from a page. Unbounded exploration can leave your intended site, hit external services, or grow unpredictably. Define the crawl scope and use tooling designed for discovery; reserve Selenium for bounded interactions.

8. Two-factor authentication

Selenium discourages automating two-factor authentication. A routine end-to-end test that depends on a live second-factor challenge or delivery channel is fragile and can involve real security controls. If your application’s authentication behavior is in scope, agree on a controlled test setup with security stakeholders; do not weaken protections in production.

Waiting for a real SMS code during every test run. Delivery delays, phone-number state, and provider availability can make the result unstable. Test the application’s challenge handling with a controlled test mechanism agreed on by the security team.
Reading a live authenticator app to obtain a changing code. This couples the test to a live credential and synchronization state. Use an isolated test identity and security-approved test configuration for the behavior under test.
Automating a real email-based second-factor challenge in a shared account. Shared inbox state and message timing can cause collisions across runs. Isolate identities and test channels, and cover the security flow deliberately rather than relying on a production account.

Choose the right test level

Selenium’s overview recommends first asking whether a browser is needed at all. Functional browser tests can cover important behavior from a user’s perspective, but they cost more to run and typically need supporting infrastructure. Selenium’s concise pattern is to set up data, perform a discrete set of actions, and evaluate the result; most tests should keep those steps short.

Question	Likely fit	Reason
Is the rule a calculation or data transformation?	Unit test	It can isolate the rule without browser setup.
Is the requirement about a status code, response header, or payload?	HTTP-level test	It observes the response directly.
Does the outcome depend on a real user interaction across rendered UI?	Focused Selenium test	A browser is part of the behavior being verified.
Will the interface change substantially soon, or is a deadline too close to build automation?	Consider manual testing short term	Selenium notes that manual testing can be more effective in these conditions.

These are decision aids, not rigid rules. Compare browser necessity, runtime and infrastructure cost, sensitivity to UI or external-service changes, failure diagnosis, and the time required to build and maintain the test. Selenium’s example cautions against a single long workflow that creates an account, configures an item, checks out, pays, and gives feedback: long tests take longer, can hit rendering-timing problems, and make failures harder to diagnose. Split workflows into short tests with one clear reason to exist.

When Selenium is still the right tool

A user-critical behavior genuinely depends on the browser and rendered interface.
The test has isolated data, a discrete action, and a clear evaluation.
A lower-level check cannot establish the user-visible behavior you care about.
The test is stable enough to maintain and its failure points to a useful diagnosis.

Selenium’s guidance is contextual. Do not remove useful browser coverage simply because a scenario resembles one of the eight categories; identify what you need to prove and whether a more direct check can prove it with less cost and ambiguity.

Or skip the browser setup

If your task is to capture a website screenshot as visual evidence or a page artifact, ScreenshotNeo is a website screenshot API and MCP server for developers. It is an alternative for capture work, not a replacement for a Selenium test of interactive behavior. The API accepts one GET request with a URL and returns PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Before capture, it accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The Free plan includes 1,000 shots per month without a card; paid plans start at $5 for 3,000 shots, with every feature on every plan.

Troubleshooting: why a Selenium test is a poor fit

Symptom	Likely cause	Better next step
CAPTCHA blocks the test	The test is trying to automate an anti-automation challenge.	Coordinate a controlled test-environment flow with product and security teams.
A downloaded file is missing or the test hangs	Download preferences, browser behavior, filesystem access, or external timing are part of the test.	Validate generation or response directly; keep browser coverage for the user-facing trigger if needed.
The test reports the wrong HTTP status	The browser-level observation is indirect or follows redirects.	Assert the response with an HTTP-level test.
Login tests fail when a provider changes	The test depends on a live third-party login flow.	Control provider responses and focus routine tests on your application’s own behavior.
Failures depend on execution order	Tests share state or rely on setup performed by another test.	Make data setup independent and ensure tests can run alone and in any order.
Performance results vary between runs	WebDriver, browser startup, workers, network, or third-party resources affect the measurement.	Measure performance with a method and environment suited to the target metric.
A link crawl runs too long or leaves the site	Recursive discovery has no bounded scope or includes external destinations.	Use a scoped crawler or link checker; keep browser tests to defined user paths.
Two-factor tests time out or collide	Live code delivery, shared inboxes, or shared identities create timing and state dependencies.	Use isolated identities and a security-approved controlled test setup.
A long end-to-end test fails with little diagnostic value	Many actions and state transitions are bundled into one test.	Separate it into short, independent tests with one reason to exist each.

FAQ

Does Selenium publish an official list of 24 scenarios?

No. Its official discouraged-behaviors page lists eight categories. The 24 scenarios here are practical examples grouped under those categories.

Should teams never automate CAPTCHA or two-factor flows?

Not as an unconditional rule. Selenium marks these behaviors discouraged; teams should decide how to cover their own authentication flow using a controlled approach designed with relevant security stakeholders.

Should every UI check be a Selenium test?

No. Use a browser when browser interaction is essential to the requirement. For lower-level rules or transport behavior, a more direct test can be simpler to run and diagnose.

When is manual testing reasonable?

Selenium’s overview names a substantially changing interface and a pressing deadline without existing automation as situations where manual testing may be more effective in the short term.