Cómo realizar pruebas web con Selenium paso a paso

En cualquier proyecto de desarrollo serio ya nadie se plantea si hacer pruebas o no: se da por hecho que habrá tests unitarios, de integración, funcionales, de regresión, de estrés y un largo etcétera. Lo que realmente marca la diferencia es cómo se diseñan esas pruebas y qué herramientas se eligen para automatizarlas. Si el enfoque es bueno, el impacto en la calidad del producto final y en su mantenimiento a largo plazo es enorme.

Dentro de ese abanico, las pruebas sobre aplicaciones web se han convertido en un terreno clave. Ahí es donde entra en juego Selenium, probablemente el framework de automatización web más extendido del mundo. Con él puedes simular casi cualquier interacción de un usuario real en un navegador y convertirla en un test reproducible, estable y ejecutable en cualquier entorno.

Qué son las pruebas funcionales y por qué son tan importantes

Cuando hablamos de pruebas funcionales nos referimos a aquellas que intentan responder a una pregunta muy concreta: ¿la aplicación hace lo que el usuario necesita y espera? En este tipo de pruebas cada funcionalidad se contrasta con sus requisitos asociados, normalmente definidos en un documento de especificación de requisitos de software (SRS).

El objetivo central es asegurar que las características críticas para el negocio, la usabilidad básica y la experiencia de usuario están alineadas con lo que se prometió. No se trata solo de que el código no lance errores, sino de comprobar que el flujo completo que seguirá un usuario funciona de forma fluida, clara y sin comportamientos raros.

En la práctica, las pruebas funcionales se suelen centrar en tres frentes: por un lado, validar las funciones principales de la aplicación (alta de usuarios, compra, búsqueda, reservas, etc.); por otro, comprobar una navegación mínima aceptable (que el usuario pueda moverse con soltura por las pantallas); y, por último, revisar aspectos de accesibilidad y usabilidad básica que condicionan el uso real del producto.

Si estas pruebas fallan o se omiten, el problema no es solo técnico: lo que se resiente es la satisfacción del usuario final y, en consecuencia, los objetivos de negocio vinculados al producto. De ahí que tenga todo el sentido invertir tiempo en automatizarlas con herramientas potentes como Selenium.

Tipos de pruebas funcionales a nivel de sistema

Dentro de las pruebas funcionales enfocadas al comportamiento global de la aplicación y a la interfaz web, hay tres tipos que suelen repetirse una y otra vez y que encajan como un guante con Selenium.

El primer grupo son las pruebas Smoke (Smoke Testing). Son tests muy básicos que se ejecutan cada vez que se genera una nueva build del sistema para comprobar que las rutas esenciales del usuario no están rotas. No buscan una cobertura exhaustiva sino validar que el producto es, al menos, “testeable” sin explotar por los aires.

En segundo lugar, tenemos las pruebas de regresión. Su misión es confirmar que, después de introducir cambios (nuevas funcionalidades, refactors, correcciones de bugs, hotfix urgentes), los comportamientos ya existentes siguen funcionando como siempre. Son pruebas más lentas y extensas, y es aquí donde la automatización con Selenium marca una diferencia brutal en términos de tiempo y fiabilidad.

El tercer tipo son las pruebas de integración a nivel de sistema. Se centran en validar que los distintos módulos (front, back, servicios externos, pasarelas de pago, etc.) cooperan correctamente. Cada vez que se suma una funcionalidad que toca a varias piezas, es clave comprobar que no se rompe nada alrededor. Selenium, al trabajar a nivel de navegador, es ideal para validar estas integraciones desde el punto de vista del usuario.

Qué es Selenium y cómo ha evolucionado

Selenium es un conjunto de herramientas de código abierto para automatizar navegadores web. A través de una API común permite escribir scripts de prueba en diferentes lenguajes de programación como Java, C#, Python, JavaScript, Ruby, PHP o Kotlin, y ejecutarlos sobre navegadores como Chrome, Firefox, Edge, Safari u otros basados en Chromium, en sistemas operativos como Windows, Linux o macOS.

Su historia arranca en 2004 en ThoughtWorks, cuando Jason Huggins necesitaba un framework para probar una aplicación interna de tiempos y gastos. Lo que comenzó como una utilidad interna derivó, tras varias iteraciones y aportaciones de perfiles como Paul Hammant, Dan Fabulich, Nelson Sproul, Pat Lightbody, Shinya Kasatani o Simon Stewart, en un ecosistema completo formado por Selenium IDE, Selenium WebDriver y Selenium Grid.

El nombre también tiene su punto curioso: surgió de una broma en la que se mencionaba que la intoxicación por mercurio (en referencia a otra herramienta de testing de la época) se podía “curar” tomando suplementos de selenio. La coña se quedó y terminó siendo la marca del proyecto.

Con el tiempo, Selenium Remote Control (Selenium RC), conocido como Selenium 1, se fusionó con WebDriver (Selenium 2.0) y terminó siendo declarado obsoleto en favor de WebDriver. Más tarde llegó Selenium 3, que consolidó el estándar W3C, y actualmente Selenium 4 incorpora novedades muy prácticas como los “Relative Locators” y mejoras específicas para navegadores Chromium y Firefox.

Las herramientas que componen el ecosistema Selenium

Cuando hablamos de Selenium no hablamos de una única pieza, sino de un pequeño ecosistema donde cada componente resuelve una necesidad concreta dentro de la automatización de pruebas funcionales web.

Selenium IDE

Selenium IDE es un entorno de desarrollo integrado en forma de extensión para Firefox y Chrome. Permite grabar, reproducir, editar y depurar pruebas sin escribir código, apoyándose en un lenguaje propio conocido como Selanese, que define comandos del tipo “haz clic aquí”, “verifica este texto”, “rellena este campo”, etc.

Es especialmente útil cuando se empieza sin mucha experiencia en programación o automatización, para crear casos sencillos o suites básicas que luego se pueden exportar a Selenium WebDriver en distintos lenguajes de programación. También resulta práctico para probar rápidamente scripts sobre Firefox y Chrome o para disparar pequeños fragmentos de JavaScript con runScript.

Selenium WebDriver

WebDriver es el corazón del sistema y la pieza que de verdad se utiliza en proyectos serios. Es un conjunto de APIs que controlan el navegador a nivel de sistema operativo, interactúan con el DOM y permiten automatizar cualquier acción que un usuario podría realizar: navegar, hacer clic, escribir, subir ficheros, leer mensajes de error, etc.

Para usarlo, se descarga el driver específico del navegador (como ChromeDriver para Chrome/Chromium), se configura su ruta y se instancia el WebDriver en el lenguaje elegido. Por ejemplo, en Java con Chrome:

System.setProperty(«webdriver.chrome.driver», «path/to/driver»); WebDriver driver = new ChromeDriver();

A partir de ahí, se puede navegar a una URL con get(), obtener datos del navegador como el título, la URL actual o el identificador de ventana, y localizar elementos en la página para interactuar con ellos. Además, WebDriver se integra muy bien con librerías como JUnit, TestNG, Cucumber u otras, y con herramientas de construcción como Maven.

Selenium Grid

Selenium Grid resuelve el problema de la escala. Es un servidor que permite ejecutar pruebas en paralelo sobre múltiples navegadores y sistemas operativos a través de un hub central que coordina varios nodos remotos.

Desde el hub se envían las solicitudes de ejecución y se encarga de distribuirlas entre los nodos disponibles, reduciendo drásticamente el tiempo de ejecución total de la suite. Es especialmente útil cuando se necesitan pruebas de compatibilidad (cross-browser y cross-platform) o cuando se quiere disparar una regresión grande en poco tiempo, incluso apoyándose en entornos en la nube como los que ofrecen proveedores tipo LambdaTest.

Localizadores de elementos en Selenium: la base de todo

Uno de los pilares para que tus pruebas con Selenium sean estables es cómo localizas los elementos del DOM. WebDriver ofrece mecanismos simples y avanzados de localización a través de la clase By, cada uno con ventajas e inconvenientes.

Entre los localizadores simples tenemos By.id() (por atributo id), By.name() (por atributo name), By.tagName() (por el nombre del tag, como input), By.className() (por clase CSS) y los específicos para enlaces By.linkText() y By.partialLinkText(), que usan el texto visible del link.

Si la estructura de la página es más compleja, entran en juego los localizadores avanzados como By.cssSelector(), que permite utilizar selectores CSS muy precisos, y By.xpath(), que da una potencia enorme para navegar el HTML y localizar elementos “rebeldes”. Además, en Selenium 4 encontramos los Relative Locators, que permiten localizar elementos en base a su posición relativa a otros, con una sintaxis muy cercana a cómo hablamos los humanos.

Un ejemplo típico de Relative Locators en Java sería algo como: RelativeLocator.with(By.tagName(«input»)).above(By.id(«password»)), que buscaría el input situado por encima del campo con id “password”. Estas estrategias ayudan mucho cuando no puedes construir un selector claro sobre un elemento aislado.

La buena práctica aquí es clara: intenta siempre localizadores únicos, estables y lo menos frágiles posible. Un XPath absoluto del estilo /html/body/div[25]/div[2]/div/span/section[2]/div/h2/p se romperá en cuanto cambie un poco el HTML. Mejor un XPath relativo basado en atributos o en el texto relevante del elemento, o incluso mejor, IDs o data-test-id bien definidos desde el desarrollo.

Habilidades web y de programación necesarias para usar Selenium con soltura

Para sacarle jugo a Selenium no basta con copiar y pegar ejemplos. Te vendrá muy bien tener cierta familiaridad con HTML y CSS, y sentirte cómodo abriendo el inspector de elementos del navegador para entender cómo se traduce la fuente de la página en lo que ves en pantalla.

También es fundamental manejarte con las herramientas de desarrollo del navegador (Chrome DevTools, Firefox DevTools, etc.) y con conceptos como XPath o selectores CSS. Vas a pasar mucho tiempo inspeccionando elementos, probando localizadores y comprobando qué identifica de forma única aquello que quieres automatizar.

En el lado de la programación, si tu objetivo es dedicarte a la ingeniería de automatización de pruebas, tendrás que asumir que escribir código forma parte del trabajo. La buena noticia es que el tipo de código que se escribe con Selenium es acotado y muy orientado a acciones concretas (navegar, localizar, hacer clic, validar). Es una excelente puerta de entrada si vienes de un perfil más funcional.

Dependiendo del lenguaje que elijas (Java, Python, C#, JavaScript, etc.) te interesará aprender también el framework de pruebas de referencia del ecosistema: por ejemplo, JUnit o TestNG en Java, pytest o unittest en Python, NUnit en C#, o Jest/Mocha en el mundo JavaScript. Estos frameworks aportan la estructura de los casos de prueba, las aserciones y la integración con herramientas externas.

Configurar tu entorno de Selenium paso a paso

Un montaje bastante habitual en proyectos Java es usar un proyecto Maven con dependencias a Selenium WebDriver, JUnit 5 (o TestNG) y, si se va a trabajar en BDD, Cucumber. Maven se encarga de resolver e integrar todas las dependencias y simplifica el build, los tests y el despliegue.

Además de las librerías, hay que descargar el WebDriver del navegador objetivo. En el caso de Chrome, sería ChromeDriver, que debe estar accesible para el sistema (por ejemplo en el PATH o indicando su ruta con System.setProperty). Una vez hecho esto, instancias el driver y ya puedes lanzar el navegador directamente desde tu código.

Con el driver creado, la primera orden típica es navegar a una página: driver.get(«https://rahulshettyacademy.com/seleniumPractise/#/»);. A partir de ahí puedes pedir información al navegador (título, URL actual, identificador de ventana) o empezar a localizar elementos con By y a interactuar con ellos.

Para que los tests se cierren de forma limpia, es importante recordar las llamadas a driver.close() o driver.quit() al final de la prueba, liberando la sesión y los recursos asociados al navegador.

Esperas implícitas, esperas explícitas y AJAX

Un error clásico al empezar es que tus scripts de Selenium vayan “demasiado rápido” y traten de interactuar con elementos que aún no han sido creados o renderizados. Es cuando aparecen mensajes como element not found o interacciones que a mano siempre funcionan pero en automático fallan de forma intermitente.

La tentación inicial suele ser tirar de Thread.sleep() y meter pausas fijas aquí y allá, pero es una mala práctica que hace las pruebas frágiles y lentas. En su lugar, Selenium ofrece esperas implícitas y esperas explícitas para sincronizarse con la aplicación.

Las esperas implícitas se configuran sobre el WebDriver y le dicen cuánto tiempo máximo debe seguir intentando localizar un elemento antes de darlo por no encontrado. Por ejemplo, en Java: driver.manage().timeouts().implicitlyWait(Duration.ofMillis(500));. Es una solución rápida, pero poco granular.

Las esperas explícitas, por su parte, permiten esperar a que se cumpla una condición concreta sobre un elemento: que sea visible, que sea clicable, que exista en el DOM, etc. Por ejemplo, en Java se puede escribir algo del estilo: WebElement orderBtn = new WebDriverWait(driver, Duration.ofSeconds(2)).until(ExpectedConditions.visibilityOfElementLocated(By.xpath(«//button[contains(text(),’Place Order’)]»)));.

En aplicaciones modernas con fuertes dosis de AJAX y uso intensivo de librerías como jQuery, a veces interesa ir un paso más allá e inspeccionar el estado de las llamadas asíncronas. Selenium WebDriver permite ejecutar JavaScript arbitrario en el contexto de la página, por lo que es posible, por ejemplo, lanzar un script que compruebe si jQuery ha terminado todas sus peticiones y solo entonces continuar con la prueba, implementando estrategias de “Smart Waiting” más robustas.

De scripts sueltos a framework profesional: Page Object Model y BDD

Al principio es habitual meter todo el código de prueba en un único método: apertura de navegador, navegación, localizadores, acciones, aserciones… Funciona para un demo, pero se convierte en una pesadilla en cuanto quieres mantener decenas o cientos de casos de prueba.

La respuesta a ese caos es el patrón Page Object Model (POM). La idea es sencilla pero muy potente: separar la lógica de tus pruebas (qué quieres comprobar) de la lógica de interacción con cada página (cómo se hace técnicamente). Para ello, se crea una clase por página de la aplicación (LoginPage, LandingPage, CheckoutPage, etc.).

En cada Page Object se guardan los selectores de los elementos relevantes y se escriben métodos de alto nivel que representan acciones de usuario: login(username, password), searchItem(nombre), addToCart(), checkoutItems(), etc. Tus tests, en lugar de contener XPaths y CSS duros, llaman a esos métodos, con lo que el código resulta mucho más legible y mantenible.

Si el diseño de la página cambia, lo normal es que solo tengas que tocar los localizadores en el Page Object correspondiente. En suites grandes de regresión esto ahorra una cantidad de tiempo brutal en mantenimiento. Además, se puede combinar POM con el patrón Page Factory para simplificar aún más la definición de elementos.

En entornos donde se trabaja con metodología ágil y enfoque BDD (Behaviour Driven Development), es muy frecuente integrar Selenium con Cucumber. Cucumber permite describir escenarios de negocio en lenguaje Gherkin, muy cercano al lenguaje natural, y luego vincular cada línea (“Given”, “When”, “Then”) con métodos Java o del lenguaje elegido, conocidos como Step Definitions.

Estos Step Definitions no deberían contener la lógica de Selenium directamente, sino apoyarse en los Page Objects. Así, un paso tipo When user searched with Shortname <Name> and extracted actual name of product invocará métodos de la LandingPage para buscar y obtener el nombre del producto, dejando los selectores encapsulados en esa clase.

Integración con frameworks de pruebas y ejemplos prácticos

Un patrón muy utilizado es combinar Selenium WebDriver con JUnit 5 en Java. Cada método anotado con @Test puede abrir el navegador, ejecutar un flujo de usuario concreto y luego usar aserciones para validar los resultados esperados.

Por ejemplo, en un test de compra podrías: navegar a la página, lanzar una búsqueda de “Broco”, incrementar la cantidad con el botón “+”, leer el valor del input de cantidad y comprobar que es 2, y adicionalmente validar que el título de la página coincide con el esperado. Todo ello orquestado desde JUnit y con el WebDriver por debajo llevando a cabo las acciones.

Además de JUnit, muchos equipos prefieren TestNG por sus capacidades avanzadas de agrupación de pruebas, dependencias y ejecución paralela. Para reporting visual, soluciones como ExtentReports o Allure permiten generar informes detallados con capturas de pantalla, históricos de ejecuciones y métricas que facilitan el análisis de fallos.

Cuando se combina Selenium con Cucumber, se obtienen varias ventajas: descripción clara de escenarios en Gherkin, separación limpia entre pasos de negocio y lógica técnica, y una organización más mantenible del código de pruebas. Todo ello se integra sin problemas en entornos Maven/Gradle y en pipelines de CI/CD.

Gestión del cambio y automatización estable

Uno de los mayores retos en automatización web es lo mucho que cambia la interfaz de usuario a lo largo del tiempo. Como ingeniero de automatización te tocará lidiar con falsas alarmas de fallo debidas no a bugs reales, sino a cambios en la aplicación o en la infraestructura.

Los problemas típicos se pueden agrupar en cuatro categorías: errores en la propia prueba (bugs de automatización), fallos del entorno (servidores caídos, datos inconsistentes), cambios inocuos en la UI que rompen los selectores, y cambios inesperados que sí son defectos reales. Distinguir entre unos y otros forma parte del día a día.

Para minimizar el impacto de los cambios, es clave usar estrategias de localización robustas (IDs estables, atributos data-test, XPaths relativos bien pensados) y patrones como Page Object Model, que concentran los selectores en pocos puntos del código.

Las esperas también influyen en la estabilidad: configuraciones demasiado agresivas o mal ajustadas pueden generar intermitencias. Estrategias como las esperas explícitas bien diseñadas o las esperas inteligentes para AJAX ayudan a reducir los falsos negativos y a hacer que las pruebas sean más resilientes frente a picos de latencia o pequeñas variaciones en los tiempos de carga.

En el ecosistema también empiezan a aparecer herramientas que se integran con Selenium para ofrecer capacidades de autorreparación de pruebas y selección inteligente. Algunas soluciones comerciales aplican heurísticas e IA para detectar si un fallo viene de un localizador roto o de un problema real, proponen nuevos localizadores sobre la marcha e incluso permiten ejecutar solo las pruebas afectadas por un cambio de código concreto, acortando los ciclos de feedback.

Qué tipo de pruebas puedes automatizar con Selenium y cuándo merece la pena

Selenium brilla especialmente en cuatro frentes: pruebas de interfaz de usuario (UI) funcionales, regresión, compatibilidad y end-to-end. En todas ellas el objetivo es simular el recorrido de un usuario real por la aplicación web.

En el ámbito funcional, Selenium se encarga de controlar de forma remota el navegador, localizar elementos de la interfaz (inputs, botones, menús desplegables, enlaces) y simular acciones como rellenar campos, seleccionar opciones, hacer clic o validar mensajes. Es perfecto para casos como el registro de usuarios, login, procesos de compra, búsquedas o cualquier flujo clave de negocio.

Las pruebas de regresión son donde la automatización demuestra más retorno: en lugar de repetir manualmente los mismos flujos cada vez que hay una versión nueva, se lanza la suite de Selenium y se obtiene una validación rápida de que no se han introducido efectos secundarios indeseados.

En compatibilidad, el soporte de Selenium para múltiples navegadores y sistemas operativos permite garantizar que la aplicación se comporta bien en distintas combinaciones de navegador, sistema y resolución. Y en pruebas end-to-end, se pueden encadenar flujos completos que van desde la búsqueda de un producto hasta el pago y la confirmación final.

Un ejemplo típico de escenario que conviene automatizar sería el alta de usuario: acceder a la URL de registro, introducir datos inválidos para comprobar que las validaciones funcionan, verificar mensajes de error, introducir datos válidos, confirmar el registro y comprobar que se muestra una pantalla de bienvenida personalizada. Hacer esto a mano en todas las combinaciones de navegador y sistema puede llevar días; con Selenium, una vez construido, se lanza tantas veces como se necesite.

Ventajas, limitaciones y alternativas modernas a Selenium

El principal punto fuerte de Selenium es su versatilidad y capacidad de integración. Es gratuito, no requiere licencias, soporta múltiples lenguajes, navegadores y plataformas, y se lleva bien con un montón de frameworks y herramientas de terceros. Permite la reutilización de código de pruebas en distintos entornos y goza de una comunidad enorme y muy activa.

Además, gracias a Selenium Grid se puede ejecutar pruebas en paralelo, reduciendo tiempos de regresión, y personalizar completamente los informes y flujos de integración continua con herramientas como Jenkins, GitLab CI o GitHub Actions.

Entre las desventajas hay que mencionar que, por sí solo, Selenium no cubre aplicaciones de escritorio o móviles nativas, para las que se necesitan soluciones adicionales como Appium. Tampoco incluye de serie un motor de reporting avanzado: hay que integrarlo con otras librerías para generar informes bonitos. Y exige un mínimo de conocimientos de programación, lo que puede ser una barrera para testers puramente manuales.

En los últimos años han surgido alternativas como Cypress, Playwright o Katalon. Cypress es muy popular para aplicaciones web modernas, con una curva de entrada suave, pero se ejecuta principalmente en el contexto del navegador y no tiene el mismo enfoque cross-browser que Selenium. Playwright, de Microsoft, ofrece una API moderna y soporte fuerte para múltiples navegadores con muy buena estabilidad. Katalon, por su parte, aporta una capa más amigable y herramientas visuales sobre distintos motores de automatización.

Aun así, para proyectos empresariales complejos donde se necesita gran flexibilidad, soporte para muchos lenguajes, integración con infraestructuras diversas y ejecución masiva en paralelo, Selenium sigue siendo una apuesta muy sólida y difícil de sustituir por completo.

En conjunto, dominar Selenium te permite automatizar desde los flujos más básicos hasta suites de regresión enormes, integrarlas en pipelines de CI/CD y elevar considerablemente el nivel de calidad de cualquier aplicación web, a la vez que reduces tiempos de prueba y liberación y liberas al equipo QA para tareas de mayor valor añadido.