A4Q Selenium Tester Examen de práctica #6 — Preguntas y respuestas
Todas las preguntas de este examen de práctica, con la respuesta correcta marcada y una justificación escrita para cada opción a continuación — para leer y repasar, no una prueba cronometrada.
¿Cuál es la diferencia clave entre una espera implícita y una espera explícita en Selenium WebDriver?
La espera implícita se aplica globalmente a todas las búsquedas, mientras que la explícita espera una condición concreta en un elemento concreto.
Correcto: la implícita se fija una vez en el driver y afecta a cada findElement; la explícita (WebDriverWait) espera una ExpectedCondition.
La espera implícita pausa el hilo un tiempo fijo, mientras que la explícita nunca sondea.
Incorrecto: eso describe Thread.sleep. Ambas esperas sondean el DOM repetidamente hasta el timeout.
La espera explícita es global, mientras que la implícita apunta a un solo elemento.
Incorrecto: invierte ambas — la global es la espera implícita.
No hay diferencia funcional; ambos términos son sinónimos.
Incorrecto: se comportan distinto y no conviene mezclarlas.
La espera implícita es un tiempo de sondeo global para cada búsqueda de elemento; la explícita apunta a una condición en un elemento.
Un test envía un formulario de búsqueda. Los resultados se cargan por AJAX y se inyectan en un contenedor: tras la respuesta el DOM contiene un div que coincide con el selector CSS div.results li.item, pero antes de la respuesta el contenedor está vacío. El equipo recibe NoSuchElementException al comprobar el primer resultado justo después de pulsar Buscar. ¿Qué fragmento hace que el test espere los resultados de forma más fiable?
new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.visibilityOfElementLocated(By.cssSelector("div.results li.item")));
Correcto: sondea hasta que el primer resultado está presente y visible, sincronizando con el render AJAX.
Thread.sleep(10000); luego driver.findElement(By.cssSelector("div.results li.item"));
Incorrecto: un sleep fijo es lento y aún así inestable — falla si la respuesta tarda y malgasta tiempo si es rápida.
driver.findElement(By.cssSelector("div.results li.item")); llamado justo tras el clic.
Incorrecto: eso es precisamente lo que lanza NoSuchElementException porque el elemento aún no existe.
driver.manage().timeouts().pageLoadTimeout(Duration.ofSeconds(10));
Incorrecto: el pageLoadTimeout rige navegaciones completas, no una actualización AJAX del DOM.
La solución correcta espera con un WebDriverWait explícito y ExpectedConditions a que el elemento concreto sea visible; no un sleep fijo ni un findElement directo.
¿Por qué usar Thread.sleep() para la sincronización se considera una mala práctica en pruebas Selenium?
Siempre pausa toda la duración fija: si es larga ralentiza, si es corta vuelve inestable la prueba.
Correcto: no se adapta al tiempo real de carga, a diferencia de una espera explícita con sondeo.
Está obsoleto y se ha eliminado de Java moderno.
Incorrecto: Thread.sleep es un método válido de Java; el problema es de comportamiento, no de obsolescencia.
Solo funciona en Firefox.
Incorrecto: es independiente del navegador — solo pausa el hilo de la prueba.
Lanza NoSuchElementException por diseño.
Incorrecto: sleep no localiza elementos, así que no lanza esa excepción.
Thread.sleep siempre espera toda la duración fija sin importar si el elemento ya está listo, haciendo las pruebas lentas e inestables.
Una página de pago muestra el botón Realizar pedido como <button id="placeOrder" disabled>Place order</button>. JavaScript quita el atributo disabled solo tras validar todos los campos obligatorios. Un test rellena los campos y hace clic, pero de forma intermitente recibe ElementClickInterceptedException / un clic sin efecto porque el botón sigue deshabilitado. ¿Qué condición de espera explícita sincroniza mejor el clic?
ExpectedConditions.elementToBeClickable(By.id("placeOrder"))
Correcto: espera a que el botón sea visible y esté habilitado (no disabled), así el clic surte efecto.
ExpectedConditions.presenceOfElementLocated(By.id("placeOrder"))
Incorrecto: el botón ya está en el DOM desde el inicio, así que presence se cumple de inmediato aunque siga deshabilitado.
ExpectedConditions.visibilityOfElementLocated(By.id("placeOrder"))
Incorrecto: el botón deshabilitado ya es visible; visibility no comprueba el estado habilitado.
ExpectedConditions.titleContains("Checkout")
Incorrecto: el título de la página no tiene relación con que el botón se habilite.
elementToBeClickable espera hasta que el elemento sea visible Y esté habilitado, que es justo la condición que aquí falta.
¿Por qué la documentación de Selenium advierte contra combinar esperas implícitas y explícitas en el mismo test?
Los dos timeouts pueden interactuar y sumarse de forma impredecible, causando esperas mucho más largas de lo esperado.
Correcto: el riesgo documentado son tiempos de espera impredecibles y acumulados.
Las esperas explícitas dejan de funcionar del todo si se fija una implícita.
Incorrecto: las explícitas siguen funcionando; el problema es el tiempo impredecible, no un fallo total.
Las esperas implícitas lanzan un error de compilación si existe una explícita.
Incorrecto: no hay conflicto en compilación; ambas son llamadas válidas de la API.
Combinarlas hace que el navegador se ejecute en modo headless automáticamente.
Incorrecto: las esperas no tienen relación con el modo headless.
Mezclarlas puede sumar timeouts de forma impredecible, generando tiempos de espera difíciles de razonar.
Un banner de confirmación existe en el DOM al cargar la página como <div id="banner" style="display:none">Saved</div> y solo se muestra (cambia display) tras completar un guardado. Un test debe comprobar que el banner realmente aparece al usuario. presenceOfElementLocated(By.id("banner")) pasa incluso antes de guardar. ¿Qué condición espera correctamente a que el banner sea visible?
ExpectedConditions.visibilityOfElementLocated(By.id("banner"))
Correcto: visibility exige que el elemento se muestre y tenga tamaño, acorde con lo que ve el usuario.
ExpectedConditions.presenceOfElementLocated(By.id("banner"))
Incorrecto: ya es cierto al cargar porque el div oculto está en el DOM — no espera a que se muestre.
ExpectedConditions.invisibilityOfElementLocated(By.id("banner"))
Incorrecto: eso espera a que desaparezca — lo contrario de lo requerido.
ExpectedConditions.numberOfElementsToBe(By.id("banner"), 1)
Incorrecto: el conteo ya es 1 mientras sigue oculto, así que no confirma visibilidad.
presence solo comprueba que el elemento está en el DOM; visibility exige además que se muestre (sin display:none y con tamaño > 0).
¿Cuáles de las siguientes son ExpectedConditions reales de Selenium para esperas explícitas? (Elija dos.)
textToBePresentInElement
Correcto: una condición real que espera un texto dado dentro de un elemento.
alertIsPresent
Correcto: una condición real que espera hasta que hay un alert de JavaScript.
elementToBeColored
Incorrecto: no existe tal ExpectedCondition en Selenium.
pageToBeFastEnough
Incorrecto: no es una ExpectedCondition real.
textToBePresentInElement y alertIsPresent son ExpectedConditions reales; las otras dos son inventadas.
Se configura un FluentWait en Java como new FluentWait<>(driver).withTimeout(...).pollingEvery(...).ignoring(...). ¿Qué dos afirmaciones sobre FluentWait son correctas? (Elija dos.)
Puede definir con pollingEvery con qué frecuencia se sondea la condición.
Correcto: el intervalo de sondeo es configurable explícitamente en FluentWait.
Puede indicar tipos de excepción a ignorar durante el sondeo, como NoSuchElementException.
Correcto: ignoring() enumera excepciones que no deben terminar la espera antes de tiempo.
FluentWait garantiza que el elemento siempre se encontrará dentro del timeout.
Incorrecto: si la condición nunca se cumple, lanza una TimeoutException.
FluentWait solo puede usarse con Firefox.
Incorrecto: es independiente del navegador, como todas las esperas de WebDriver.
FluentWait permite fijar el intervalo de sondeo y los tipos de excepción a ignorar durante el sondeo; es una generalización de WebDriverWait.
En la automatización de pruebas, ¿qué describe mejor un test flaky (inestable)?
Un test que pasa y falla de forma intermitente sobre el mismo código y entorno sin cambios.
Correcto: resultados no deterministas sin cambio de código es la definición de flakiness.
Un test que siempre falla tras un cambio de código.
Incorrecto: un test que falla siempre es determinista, no flaky.
Un test que tarda más de un minuto en ejecutarse.
Incorrecto: la lentitud no es lo mismo que resultados no deterministas.
Un test escrito sin aserciones.
Incorrecto: la falta de aserciones es otro defecto, no flakiness.
Un test flaky da resultados distintos (pasa/falla) sobre el mismo código sin ningún cambio en él.
Un test recorre una lista de filas; en cada fila lee una celda, hace clic en un enlace Editar que recarga la tabla por AJAX y luego continúa el bucle. Con frecuencia lanza StaleElementReferenceException en la segunda iteración. ¿Cuál es la causa raíz y la solución correcta?
Las referencias guardadas quedan desprendidas tras la recarga AJAX; re-localizar los elementos (p. ej. volver a ejecutar findElements) tras cada recarga en vez de reutilizar referencias viejas.
Correcto: las referencias stale apuntan a nodos ya no adjuntos al DOM; volver a buscarlos lo resuelve.
El localizador es incorrecto; cambiar cada By.id por By.xpath.
Incorrecto: el localizador funciona en la primera iteración — el problema es la staleness tras la recarga, no la estrategia de localización.
Añadir una espera implícita grande; eso elimina la StaleElementReferenceException.
Incorrecto: una espera implícita no refresca referencias ya capturadas, la staleness persiste.
Ejecutar el navegador en modo headless.
Incorrecto: el modo headless no cambia el desprendimiento de nodos del DOM.
Tras la recarga AJAX, las referencias WebElement guardadas apuntan a nodos DOM desprendidos; deben re-localizarse dentro del bucle tras cada recarga.
¿Qué práctica mejora más la estabilidad de una suite que debe ejecutarse repetidamente en una pipeline de CI?
Hacer cada test independiente y autocontenido, creando y limpiando sus propios datos.
Correcto: la independencia elimina fallos de orden y de estado compartido, la mayor ganancia de estabilidad en CI.
Aumentar cada Thread.sleep a al menos 30 segundos.
Incorrecto: sleeps fijos más largos ralentizan la suite y no eliminan la no determinación subyacente.
Hacer que todos los tests compartan una sesión de navegador y un dataset para ahorrar tiempo.
Incorrecto: el estado compartido entre tests es una causa principal de flakiness dependiente del orden.
Capturar y silenciar toda excepción para que los tests nunca reporten fallos.
Incorrecto: ocultar fallos hace los tests inútiles, no estables.
Tests independientes y autocontenidos que crean y limpian sus propios datos evitan dependencias de orden y flakiness por estado compartido.
Un equipo observa que unos pocos tests fallan solo cuando el grid de CI está muy cargado y los agentes responden despacio, pero siempre pasan en local. ¿Cuál es la causa más probable?
Las suposiciones de tiempo que se cumplen en local se rompen cuando el grid cargado renderiza páginas más despacio de lo que permiten las esperas.
Correcto: el tiempo dependiente del entorno es un flake clásico; la solución son esperas explícitas robustas, no retardos fijos.
El código fuente de la aplicación es distinto en el grid que en local.
Incorrecto: normalmente se despliega el mismo build; la diferencia es tiempo/carga, no el código.
WebDriver no puede ejecutarse en máquinas cargadas en absoluto.
Incorrecto: WebDriver funciona bajo carga; solo expone suposiciones de tiempo frágiles.
Las aserciones son demasiado estrictas y deberían eliminarse.
Incorrecto: quitar aserciones oculta el problema; la causa es el tiempo, no las comprobaciones.
Suposiciones de tiempo fijas (sleeps fijos o esperas demasiado cortas) se rompen en entornos más lentos y cargados — un flake de tiempo dependiente del entorno.
¿Qué enfoque de localizadores mejora más la estabilidad a largo plazo de las pruebas de UI frente a un front end que cambia con frecuencia?
Preferir atributos estables y dedicados como data-test o un id fijo antes que XPath absolutos y clases de estilo.
Correcto: los ganchos de prueba dedicados sobreviven a cambios de maquetación y estilo, reduciendo roturas de localizadores.
Usar siempre XPath absoluto desde la raíz html, p. ej. /html/body/div[3]/div[2]/table/tr[4]/td[2].
Incorrecto: el XPath absoluto es extremadamente frágil — cualquier cambio estructural lo rompe.
Localizar elementos por su clase de framework autogenerada como css-1a2b3c.
Incorrecto: las clases de framework con hash cambian en cada build y son localizadores inestables.
Localizar cada elemento por sus coordenadas de píxel exactas.
Incorrecto: las coordenadas no son una estrategia de localización de WebDriver y se rompen con cualquier cambio de maquetación.
Anclas estables y expresivas como atributos data-test dedicados son mucho menos frágiles que XPath absolutos o clases CSS autogeneradas.
¿Cuáles dos de las siguientes son causas comunes de tests Selenium flaky? (Elija dos.)
Condiciones de carrera por interactuar con elementos antes de que estén listos (faltan esperas explícitas).
Correcto: actuar antes de que la UI esté lista es una fuente principal de flakiness.
Tests que dependen de datos compartidos o residuales de tests anteriores.
Correcto: el estado compartido/residual crea resultados no deterministas dependientes del orden.
Usar un Page Object Model para estructurar los tests.
Incorrecto: el POM mejora la mantenibilidad y suele reducir, no causar, la flakiness.
Añadir mensajes descriptivos en las aserciones.
Incorrecto: los mensajes de aserción ayudan a depurar y no afectan al determinismo.
Las condiciones de carrera por falta de sincronización y la dependencia de estado compartido o residual son dos causas clásicas de flakiness.
Un equipo quiere reducir la flakiness sin ocultar defectos reales. ¿Qué dos medidas son apropiadas? (Elija dos.)
Reemplazar las llamadas fijas a Thread.sleep por condiciones explícitas WebDriverWait.
Correcto: sincronizar con condiciones reales elimina la flakiness por carrera sin enmascarar defectos.
Poner en cuarentena los tests marcados como flaky e investigar su causa raíz antes de reactivarlos.
Correcto: aislar y diagnosticar los tests flaky mantiene la señal fiable mientras se corrige la causa.
Reintentar automáticamente cada test fallido hasta 10 veces y reportar éxito si algún intento pasa.
Incorrecto: los reintentos ciegos enmascaran defectos intermitentes reales y dejan pasar bugs.
Eliminar las aserciones de los tests flaky para que ya no puedan fallar.
Incorrecto: borrar aserciones hace el test inútil y oculta defectos por completo.
Reemplazar sleeps fijos por esperas explícitas y poner en cuarentena/investigar los tests flaky es correcto; reintentar hasta pasar y borrar aserciones ocultan defectos.
¿Qué método de WebDriver recarga la página actual, equivalente a pulsar el botón de actualizar del navegador?
driver.navigate().refresh()
Correcto: refresh() recarga la página actual.
driver.navigate().back()
Incorrecto: back() va a la entrada anterior del historial, no recarga.
driver.get("about:blank")
Incorrecto: eso navega a una página en blanco, no recarga la actual.
driver.close()
Incorrecto: close() cierra la ventana/pestaña actual; no actualiza.
driver.navigate().refresh() recarga la URL actual; los otros métodos navigate se mueven por el historial o a una nueva URL.
Una página incrusta un formulario de pago dentro de <iframe id="payframe" src="...">. Un test hace driver.switchTo().frame("payframe"), escribe el número de tarjeta y envía. Después debe pulsar un botón Continuar que está en la página principal (fuera del iframe), pero findElement lanza NoSuchElementException. ¿Qué debe hacer primero el test?
Llamar a driver.switchTo().defaultContent() para devolver el foco al documento principal antes de localizar el botón Continuar.
Correcto: tras trabajar en un iframe hay que volver al documento superior para acceder a elementos de la página principal.
Llamar a driver.switchTo().frame("payframe") por segunda vez.
Incorrecto: volver a entrar en el mismo frame mantiene el foco dentro del iframe, no en la página principal.
Añadir driver.manage().window().maximize().
Incorrecto: el tamaño de ventana no tiene relación con el contexto del frame.
Aumentar la espera implícita a 30 segundos.
Incorrecto: el elemento es inalcanzable por el contexto del frame, no por tiempo — esperar más seguirá fallando.
WebDriver permanece enfocado en el iframe hasta que se vuelve al documento de nivel superior con switchTo().defaultContent().
Al pulsar un botón Eliminar se abre un diálogo de confirmación nativo de JavaScript (window.confirm) que dice "Delete this item?". El test debe aceptarlo para continuar. ¿Qué secuencia es correcta?
driver.switchTo().alert().accept();
Correcto: cambiar al alert y llamar a accept() confirma el diálogo nativo.
driver.findElement(By.xpath("//button[text()='OK']")).click();
Incorrecto: un diálogo confirm nativo no es parte del DOM, así que no puede localizarse con findElement.
driver.switchTo().alert().dismiss();
Incorrecto: dismiss() cancela el diálogo (Cancelar), lo que no continuaría con la eliminación.
driver.navigate().refresh();
Incorrecto: recargar la página descarta el diálogo y la acción de eliminar.
Hay que cambiar al alert y llamar a accept(); un findElement normal no puede interactuar con diálogos nativos del navegador.
Una página de producto tiene un desplegable <select id="qty"><option value="1">1</option><option value="2">2</option><option value="3">3</option></select>. El test debe elegir la opción con texto visible "2". ¿Qué código Selenium la selecciona correctamente?
new Select(driver.findElement(By.id("qty"))).selectByVisibleText("2");
Correcto: Select.selectByVisibleText es la API prevista para desplegables select estándar.
driver.findElement(By.id("qty")).sendKeys("2");
Incorrecto: sendKeys sobre un select es poco fiable y no es la forma estándar de elegir una opción por texto.
driver.findElement(By.id("qty")).click();
Incorrecto: un solo clic solo abre el desplegable; no selecciona la opción "2".
new Select(driver.findElement(By.id("qty"))).deselectAll();
Incorrecto: deselectAll borra selecciones y solo funciona en multi-select; no elige "2".
La clase de soporte Select ofrece selectByVisibleText para elementos select estándar de HTML.
¿Cuál es la diferencia entre driver.close() y driver.quit() en Selenium WebDriver?
close() cierra solo la ventana actual, mientras que quit() cierra todas las ventanas y termina la sesión.
Correcto: es la distinción documentada entre ambos.
close() termina la sesión, mientras que quit() cierra solo la ventana actual.
Incorrecto: invierte ambos métodos.
Son idénticos e intercambiables.
Incorrecto: difieren en alcance — una ventana frente a toda la sesión.
close() borra cookies, mientras que quit() recarga la página.
Incorrecto: ninguno de los métodos trata de cookies ni de recargar.
close() cierra solo la ventana/pestaña actual; quit() cierra todas las ventanas y termina la sesión de WebDriver.
Un test pasa el cursor sobre un menú Products para desplegar un submenú y luego hace clic en el enlace Laptops que solo aparece al hacer hover. Un clic directo sobre el enlace oculto falla. ¿Qué enfoque de Selenium realiza correctamente el hover y luego el clic?
new Actions(driver).moveToElement(productsMenu).click(laptopsLink).perform();
Correcto: Actions.moveToElement hace hover y despliega el submenú, luego click apunta al enlace ya visible; perform() lo ejecuta.
laptopsLink.click(); llamado directamente sin ningún hover.
Incorrecto: el enlace no es interactuable hasta que el hover lo revela, así que el clic directo falla.
driver.navigate().to(productsMenu.getText());
Incorrecto: usa mal navigate con el texto del menú como URL y no hace hover ni clic.
new Select(productsMenu).selectByVisibleText("Laptops");
Incorrecto: Select solo funciona en elementos <select>, no en un menú de navegación con hover.
La clase Actions encadena moveToElement (hover) y click para interactuar con menús que aparecen al pasar el cursor.
Al hacer clic en un enlace Report se abre una nueva pestaña del navegador. El test debe leer un valor en la nueva pestaña y luego volver a la original. ¿Qué dos pasos se requieren? (Elija dos.)
Capturar driver.getWindowHandles() y cambiar al nuevo handle con driver.switchTo().window(newHandle).
Correcto: enumerar handles y cambiar por handle es la forma estándar de trabajar en la nueva pestaña.
Guardar antes el handle original y volver a él con driver.switchTo().window(originalHandle).
Correcto: conservar el handle original permite regresar a la primera pestaña tras leer la nueva.
Llamar a driver.switchTo().frame(1) para alcanzar la nueva pestaña.
Incorrecto: frame() cambia entre iframes dentro de un documento, no entre pestañas del navegador.
Usar driver.navigate().forward() para pasar a la nueva pestaña.
Incorrecto: forward() se mueve por el historial de la pestaña actual; no cambia de pestaña.
Se capturan los window handles y se usa switchTo().window(handle) para moverse entre pestañas; getWindowHandles devuelve todos los handles abiertos.
¿Cuál es el propósito principal del patrón Page Object Model (POM) en la automatización con Selenium?
Encapsular los localizadores e interacciones de una página en una clase dedicada, mejorando el mantenimiento y la reutilización.
Correcto: centralizar localizadores/acciones por página es el beneficio central del POM.
Hacer que el navegador vaya más rápido cacheando páginas.
Incorrecto: POM es un patrón de diseño para estructura, no un mecanismo de rendimiento/caché.
Eliminar la necesidad de cualquier localizador.
Incorrecto: POM sigue usando localizadores — solo los organiza dentro de clases de página.
Generar datos de prueba automáticamente.
Incorrecto: la generación de datos de prueba no tiene relación con el patrón POM.
POM encapsula los localizadores e interacciones de una página en una clase para que los tests sean legibles y los cambios de localizador se hagan en un solo lugar.
En un Page Object, un método login se escribe así: public DashboardPage login(String user, String pass) { type(userField, user); type(passField, pass); click(submitBtn); return new DashboardPage(driver); }. ¿Por qué el método devuelve un nuevo DashboardPage en lugar de void?
Porque un login exitoso lleva al dashboard; devolver ese page object modela la navegación y permite encadenar las siguientes acciones.
Correcto: devolver el page object resultante es la forma idiomática del POM de representar transiciones de página.
Porque un método en Java siempre debe devolver un objeto.
Incorrecto: los métodos de Java pueden devolver void; el tipo de retorno aquí es una decisión de diseño deliberada.
Porque devolver DashboardPage hace el login más rápido.
Incorrecto: el tipo de retorno no afecta a la velocidad de ejecución.
Porque evita la necesidad de localizadores en el dashboard.
Incorrecto: el DashboardPage sigue definiendo sus propios localizadores; devolverlo no los elimina.
Devolver el siguiente page object modela el resultado de la navegación y permite flujos de test legibles y encadenables entre páginas.
¿Qué afirmación refleja mejor una buena separación de responsabilidades al usar el Page Object Model?
Los page objects exponen acciones y estado de la página, mientras que las aserciones viven en los métodos de test.
Correcto: mantener las aserciones en los tests y el comportamiento en los page objects es la separación recomendada.
Toda aserción debe colocarse dentro de los métodos del page object.
Incorrecto: incrustar aserciones en los page objects los acopla a tests concretos y reduce la reutilización.
La instancia de WebDriver debe crearse dentro de cada método del page object.
Incorrecto: el driver normalmente se comparte/inyecta, no se recrea por método.
Los localizadores deben codificarse directamente en cada método de test, no en el page object.
Incorrecto: eso anula el POM — los localizadores deben centralizarse en el page object.
Las aserciones pertenecen a los tests; los page objects exponen acciones y estado, pero no deben contener las aserciones del test.
Un rediseño de UI cambia el id del botón de login de loginBtn a signInBtn. En una suite POM bien estructurada con 30 tests que inician sesión, ¿cuántos lugares deben actualizarse?
Uno — la única definición del localizador en la clase LoginPage.
Correcto: los localizadores centralizados significan que un cambio cubre los 30 tests.
Treinta — uno por cada test que inicia sesión.
Incorrecto: esa es la situación que POM evita; localizadores duplicados serían el anti-patrón.
Ninguno — Selenium actualiza los localizadores automáticamente.
Incorrecto: Selenium no auto-corrige localizadores; la definición debe cambiarse manualmente.
Dos — el localizador más la configuración del driver del navegador.
Incorrecto: la configuración del driver no tiene relación con un cambio de id de localizador.
Con POM el localizador se define una sola vez en la clase LoginPage, así que solo cambia esa única definición.
¿Qué relación entre los datos de prueba y los page objects se recomienda en un framework Selenium mantenible?
Los métodos del page object aceptan datos como parámetros desde los tests, manteniéndolos reutilizables.
Correcto: pasar los datos mantiene los page objects genéricos y reutilizables entre escenarios.
Cada page object debe codificar un usuario y contraseña específicos.
Incorrecto: codificar datos ata el page object a un escenario y perjudica la reutilización.
Los datos de prueba deben almacenarse dentro de la instancia de WebDriver.
Incorrecto: la instancia de WebDriver no es un almacén de datos para valores de prueba.
Los page objects deben generar datos aleatorios y nunca aceptar parámetros.
Incorrecto: forzar datos aleatorios elimina el control sobre las condiciones de prueba y la reproducibilidad.
Los page objects deben parametrizarse con datos que pasan los tests, manteniéndose reutilizables en lugar de atados a valores fijos.
¿Cuáles dos son beneficios reales de aplicar el Page Object Model? (Elija dos.)
Menor duplicación de código porque los localizadores y acciones se definen una vez por página.
Correcto: la centralización reduce la duplicación entre tests.
Mejor mantenibilidad, ya que los cambios de UI se gestionan en una clase de página.
Correcto: actualizar en un solo punto los localizadores es un beneficio clave de mantenimiento.
Elimina la necesidad de cualquier espera explícita.
Incorrecto: la sincronización sigue siendo necesaria; POM no reemplaza las esperas.
Garantiza que los tests nunca puedan ser flaky.
Incorrecto: POM mejora la estructura pero no elimina la flakiness de tiempo o entorno.
POM reduce la duplicación de código y mejora el mantenimiento al centralizar localizadores; no elimina las esperas ni garantiza cero flakiness.
Dado el markup <input type="email" name="email" data-test="signup-email" class="form-control ng-untouched">, ¿qué localizador es la opción más robusta para un test que debe sobrevivir a cambios de estilo y de estado del framework?
By.cssSelector("[data-test='signup-email']")
Correcto: un atributo data-test dedicado es estable ante cambios de estilo y de estado del framework.
By.cssSelector(".form-control.ng-untouched")
Incorrecto: ng-untouched es una clase de estado transitorio del framework que cambia al interactuar y rompe el localizador.
By.xpath("/html/body/div[2]/form/div[1]/input")
Incorrecto: un XPath absoluto es extremadamente frágil y se rompe ante cualquier cambio estructural.
By.className("form-control")
Incorrecto: form-control es una clase genérica compartida que probablemente coincide con muchos inputs, no es única.
El atributo dedicado data-test es estable; los valores de class contienen ruido de framework/estado (ng-untouched) que cambia en tiempo de ejecución.
Una fila de tabla es <tr><td>SKU-9921</td><td>In stock</td><td><button>Reorder</button></td></tr> entre muchas filas. El test debe pulsar el botón Reorder de la fila cuya primera celda tiene el texto SKU-9921. ¿Qué XPath selecciona ese botón correctamente?
//td[text()='SKU-9921']/ancestor::tr//button
Correcto: se ancla en la celda SKU, sube a su fila y selecciona el botón dentro de esa misma fila.
//button[text()='Reorder']
Incorrecto: coincide con todos los botones Reorder de la tabla, no con el asociado a SKU-9921.
//td[text()='SKU-9921']/button
Incorrecto: el botón no es hijo directo de la celda SKU; está en una celda hermana de la misma fila.
//tr[1]//button
Incorrecto: apunta por posición a la primera fila, que puede no ser la fila SKU-9921.
Se localiza el td por su texto exacto, se sube al ancestor tr y luego se encuentra el button dentro de esa fila.
El DOM tiene <a href="/logout" class="nav-link"> Log out </a> con espacios antes y después del texto. ¿Qué XPath coincide de forma fiable con el enlace por su texto visible pese a los espacios que lo rodean?
//a[normalize-space()='Log out']
Correcto: normalize-space() elimina los espacios circundantes para que el texto coincida limpiamente.
//a[text()='Log out']
Incorrecto: el nodo de texto exacto incluye los espacios inicial/final, así que un match estricto falla.
//a[@class='nav-link'][1]
Incorrecto: depende de la clase y la posición, no del texto visible, y puede coincidir con otro enlace.
//a[contains(@href,'Log out')]
Incorrecto: busca 'Log out' en el atributo href (/logout), que no lo contiene.
normalize-space() recorta y colapsa los espacios, así que 'Log out' coincide aun con espacios alrededor; un text()='Log out' estricto fallaría.
¿Qué selector CSS coincide con un input cuyo valor del atributo id termina con el sufijo _email, por ejemplo user_email o admin_email?
input[id$='_email']
Correcto: $= es el operador de atributo 'termina con' en CSS.
input[id^='_email']
Incorrecto: ^= significa 'empieza con', coincidiría con ids que comienzan por _email.
input[id*='_email']
Incorrecto: *= significa 'contiene', más amplio que el 'termina con' requerido.
input[id='_email']
Incorrecto: exige que el id sea exactamente _email, no coincide con user_email ni admin_email.
El selector de atributo CSS [id$='_email'] coincide con valores que terminan en la subcadena dada.
¿Por qué id y name suelen preferirse como estrategias de localización frente a XPath cuando hay un id estable disponible?
Un id/name estable es simple, inequívoco y menos frágil que una expresión XPath compleja.
Correcto: un buen id es el localizador más directo y robusto cuando existe.
XPath no puede localizar elementos por id en absoluto.
Incorrecto: XPath puede coincidir con @id; el punto es la simplicidad y robustez, no la capacidad.
Los localizadores por id esperan automáticamente a que el elemento cargue.
Incorrecto: ninguna estrategia de localización añade espera por sí misma; la sincronización es aparte.
Los localizadores por name solo funcionan en modo headless.
Incorrecto: las estrategias de localización son independientes del modo headless.
Las búsquedas por id/name son simples, rápidas y menos frágiles; los XPath complejos son más frágiles y pueden ser más lentos.
Dado <button data-test="save" class="btn primary" type="submit">Save</button>, ¿qué dos localizadores coincidirían correctamente con este botón? (Elija dos.)
By.cssSelector("button[data-test='save']")
Correcto: el atributo data-test está presente e identifica el botón de forma única.
By.cssSelector("button.btn.primary")
Correcto: el selector de clase compuesta coincide con un elemento que lleva las clases btn y primary.
By.id("save")
Incorrecto: el botón no tiene atributo id, solo data-test='save', así que By.id no coincide.
By.name("save")
Incorrecto: el elemento no tiene atributo name, así que By.name falla.
El selector de atributo data-test y el selector de clase compuesta coinciden ambos; los selectores por id y name no, porque el elemento no tiene ninguno.
¿Qué hace el método driver.get(String url) en Selenium WebDriver?
Carga la URL dada en la ventana actual del navegador y espera a que la página cargue.
Correcto: get() abre la URL y bloquea hasta que termina la carga de la página.
Devuelve el cuerpo de la respuesta HTTP como String.
Incorrecto: get() devuelve void y controla el navegador; no devuelve el cuerpo de la respuesta.
Obtiene el valor de un campo de formulario.
Incorrecto: leer el valor de un campo usa getAttribute o getText, no driver.get.
Cierra la sesión actual del navegador.
Incorrecto: cerrar la sesión es quit(); get() abre una URL.
get() navega el navegador a la URL dada y espera a que se complete la carga de la página.
Un elemento es <input id="promo" value="WELCOME10">. Durante el test un usuario escribe SUMMER encima, pero el atributo visible del DOM sigue mostrando value="WELCOME10" en el código fuente. El test necesita el texto actual que el usuario ve en el campo. ¿Qué llamada devuelve SUMMER?
element.getAttribute("value")
Correcto: getAttribute("value") refleja la propiedad value actual y devuelve el SUMMER escrito.
element.getText()
Incorrecto: getText() devuelve el texto interno visible, que está vacío en un <input>.
element.getTagName()
Incorrecto: getTagName() devuelve 'input', no el valor del campo.
element.getCssValue("value")
Incorrecto: getCssValue lee propiedades CSS, no el value del input.
getAttribute("value") devuelve la propiedad value actual (SUMMER), mientras que el atributo HTML estático puede seguir siendo WELCOME10; getText() devuelve vacío para inputs.
En tests Selenium basados en JUnit, ¿por qué es buena práctica instanciar el WebDriver en un método @BeforeEach y llamar a driver.quit() en un método @AfterEach?
Da a cada test una sesión de navegador limpia y aislada y libera el driver de forma fiable después.
Correcto: un setup nuevo y un teardown garantizado por test maximizan el aislamiento y la estabilidad.
Hace que los tests se ejecuten en paralelo automáticamente.
Incorrecto: el paralelismo lo configura el runner de tests, no el setup/teardown por test por sí solo.
Elimina la necesidad de cualquier localizador.
Incorrecto: los métodos de ciclo de vida no afectan a cómo se localizan los elementos.
Garantiza que la aplicación no tiene defectos.
Incorrecto: el setup/teardown organiza los tests; no puede garantizar una aplicación sin defectos.
El setup/teardown por test da a cada test una sesión de navegador limpia y aislada y libera el driver, mejorando la independencia y la estabilidad.
¿Qué excepción lanza Selenium cuando findElement no puede localizar ningún elemento que coincida con el localizador dado?
NoSuchElementException
Correcto: es la excepción lanzada por findElement cuando nada coincide.
TimeoutException
Incorrecto: TimeoutException la lanza una espera cuya condición nunca se cumple, no un findElement simple.
StaleElementReferenceException
Incorrecto: esa ocurre cuando un elemento hallado antes ya no está adjunto al DOM, no cuando no se encuentra nada.
ElementClickInterceptedException
Incorrecto: esa se lanza cuando otro elemento intercepta un clic, no por una búsqueda fallida.
findElement lanza NoSuchElementException cuando no se encuentra ningún elemento coincidente.
¿Cuál es la diferencia entre findElement y findElements en Selenium WebDriver?
findElement devuelve el primer elemento coincidente o lanza si no hay ninguno; findElements devuelve una lista, vacía si nada coincide.
Correcto: es la diferencia de comportamiento documentada entre ambos.
Ambos lanzan NoSuchElementException cuando nada coincide.
Incorrecto: findElements devuelve una lista vacía en lugar de lanzar.
findElements devuelve solo el último elemento coincidente.
Incorrecto: findElements devuelve todas las coincidencias como lista, no solo la última.
findElement solo funciona con XPath, findElements solo con CSS.
Incorrecto: ambos aceptan cualquier estrategia de localización By.
findElement devuelve la primera coincidencia o lanza NoSuchElementException; findElements devuelve una lista que está vacía cuando no hay coincidencias.
¿Qué dos afirmaciones sobre Selenium WebDriver son correctas? (Elija dos.)
Automatiza navegadores reales a través de su soporte de automatización nativo.
Correcto: WebDriver controla navegadores reales mediante sus interfaces de automatización.
Ofrece bindings oficiales de lenguajes como Java, Python, C# y JavaScript.
Correcto: WebDriver ofrece varios bindings oficiales, haciéndolo independiente del lenguaje.
Es en sí un framework de pruebas unitarias que reemplaza a JUnit o TestNG.
Incorrecto: WebDriver controla el navegador; aún se necesita un runner como JUnit o TestNG.
Requiere que se fije una espera implícita o no puede encontrar ningún elemento.
Incorrecto: WebDriver encuentra elementos sin ninguna espera implícita; la espera solo añade tolerancia de sondeo.
WebDriver controla navegadores reales mediante sus interfaces de automatización y es independiente del lenguaje gracias a los bindings oficiales; no es un runner de tests ni necesita una espera implícita para funcionar.