A4Q Selenium Tester Examen de práctica #5 — 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 entre driver.close() y driver.quit() en Selenium WebDriver?
close() cierra la ventana actual; quit() finaliza la sesión y cierra todas las ventanas.
Correcto: quit() también libera el proceso del driver, mientras close() mantiene la sesión si quedan otras ventanas.
Son idénticos; ambos finalizan la sesión de WebDriver.
Incorrecto: close() no finaliza la sesión si hay otras ventanas abiertas.
close() finaliza la sesión; quit() cierra una ventana.
Incorrecto: los roles están invertidos.
quit() solo borra cookies; close() borra la caché.
Incorrecto: ninguno de los métodos trata de cookies ni caché.
close() cierra solo la ventana/pestaña actual; quit() finaliza toda la sesión de WebDriver y cierra todas las ventanas.
¿Qué ocurre cuando findElement() no encuentra un elemento coincidente?
Lanza una NoSuchElementException.
Correcto: es el comportamiento definido cuando falla la búsqueda de un único elemento.
Devuelve null.
Incorrecto: WebDriver lanza una excepción en lugar de devolver null.
Devuelve una lista vacía.
Incorrecto: ese es el comportamiento de findElements(), no de findElement().
Espera indefinidamente hasta que el elemento aparezca.
Incorrecto: sin espera explícita/implícita falla de inmediato.
findElement() lanza inmediatamente NoSuchElementException; findElements() devuelve una lista vacía.
Una etiqueta de precio se renderiza como: <span id="total" data-amount="49.90">€49.90</span>. La prueba debe leer el valor numérico 49.90 (no el texto formateado). ¿Qué llamada devuelve exactamente 49.90?
element.getAttribute("data-amount")
Correcto: lee el atributo data-amount con el valor sin formato 49.90.
element.getText()
Incorrecto: devuelve el texto visible '€49.90' con el símbolo de moneda.
element.getAttribute("value")
Incorrecto: un span no tiene atributo value, devuelve null.
element.getTagName()
Incorrecto: devuelve 'span', el nombre de la etiqueta.
getText() devuelve el visible '€49.90'. El valor puro está en el atributo data-amount, leído con getAttribute("data-amount").
¿Mediante qué protocolo estandarizado se comunica Selenium 4 con los navegadores?
El protocolo W3C WebDriver.
Correcto: Selenium 4 abandonó el JSON Wire Protocol por el estándar W3C.
El antiguo JSON Wire Protocol.
Incorrecto: ese protocolo era de Selenium 3 y fue eliminado en Selenium 4.
FTP.
Incorrecto: FTP es un protocolo de transferencia de archivos, ajeno a la automatización.
SMTP.
Incorrecto: SMTP es un protocolo de correo electrónico.
Selenium 4 cumple totalmente con W3C WebDriver; el antiguo JSON Wire Protocol fue eliminado.
Una clase de prueba ejecuta 12 métodos. Cada método necesita una sesión de navegador nueva y aislada, y no debe quedar ninguna ventana abierta al terminar, aunque una prueba falle. ¿Dónde instanciar y dónde liberar el driver?
Crear el driver en @BeforeEach y llamar quit() en @AfterEach.
Correcto: la preparación por método da aislamiento; el cierre tras cada prueba garantiza limpieza aun con fallos.
Crear una vez en @BeforeAll y cerrar en @AfterAll.
Incorrecto: una sesión compartida entre 12 pruebas rompe el aislamiento (fuga de estado).
Crear en @BeforeEach pero llamar quit() solo al final del cuerpo de cada prueba.
Incorrecto: si una prueba falla antes de esa línea, quit() no se ejecuta y quedan ventanas abiertas.
Confiar en que la JVM cierre el navegador al salir.
Incorrecto: el proceso del navegador/driver no se limpia solo y quedan procesos huérfanos.
El aislamiento por prueba exige crear el driver en @BeforeEach y llamar quit() en @AfterEach, que se ejecuta incluso tras fallos.
Quiere contar cuántos elementos <li> tiene una lista, y el conteo puede ser legítimamente cero. ¿Qué método usar?
findElements(...).size()
Correcto: devuelve 0 si no hay coincidencias en lugar de lanzar, ideal para contar.
findElement(...) en un bucle hasta que falle.
Incorrecto: depender de una excepción para un conteo cero normal es frágil y lento.
getPageSource().length()
Incorrecto: mide la longitud del HTML, no el número de elementos.
getTitle().length()
Incorrecto: no relacionado — devuelve la longitud del título de la página.
findElements() devuelve una lista que puede estar vacía (tamaño 0) sin lanzar excepción, permitiendo contar incluso cero.
¿Qué afirmación sobre driver.getWindowHandle() y driver.getWindowHandles() es correcta?
getWindowHandle() devuelve un String; getWindowHandles() devuelve un Set de Strings.
Correcto: el singular da el handle actual y el plural todos como Set.
Ambos devuelven una List en orden garantizado.
Incorrecto: getWindowHandles() devuelve un Set sin orden, no una List.
getWindowHandle() abre una ventana nueva.
Incorrecto: solo devuelve el handle actual; no abre nada.
getWindowHandles() cambia el foco a la última ventana.
Incorrecto: solo devuelve handles; el cambio requiere switchTo().window(handle).
getWindowHandle() (singular) devuelve el handle de la ventana actual como String; getWindowHandles() (plural) devuelve un Set de todos los handles abiertos.
¿Qué DOS capacidades se introdujeron o estandarizaron en Selenium 4? (Seleccione DOS)
Localizadores relativos (friendly) como above(), below(), toLeftOf().
Correcto: los localizadores relativos son una función de Selenium 4.
Acceso nativo al Chrome DevTools Protocol (CDP).
Correcto: Selenium 4 expone CDP para red, geolocalización y consola.
Grabar pruebas como vídeo por defecto.
Incorrecto: WebDriver no graba vídeo; requiere herramientas externas.
Generación automática de localizadores a partir de capturas.
Incorrecto: no existe tal función en Selenium 4.
Selenium 4 añadió localizadores relativos (friendly) y acceso nativo al Chrome DevTools Protocol, y adoptó el estándar W3C.
¿Qué selector CSS coincide con un elemento con id "submit-btn"?
#submit-btn
Correcto: '#' selecciona por id.
.submit-btn
Incorrecto: '.' selecciona por clase, no por id.
submit-btn
Incorrecto: un token simple selecciona por etiqueta; no existe la etiqueta <submit-btn>.
*submit-btn
Incorrecto: no es sintaxis CSS válida para un id.
En CSS, '#' apunta a un id, por lo que #submit-btn coincide con id="submit-btn". '.' apunta a una clase.
Dado: <input class="form-control" name="email" type="email"> y varios otros inputs comparten class="form-control". Necesita un localizador que identifique de forma única el campo de correo. ¿Cuál es el mejor?
css=input[name='email']
Correcto: el atributo name es único y da una coincidencia estable y precisa.
css=.form-control
Incorrecto: esa clase es compartida y coincide con varios inputs, no solo el correo.
css=input
Incorrecto: coincide con todos los inputs de la página.
css=input.email
Incorrecto: no existe la clase 'email'; 'email' es el valor de name, no una clase.
La clase está compartida, no es única. El atributo name 'email' es único, por lo que css=input[name='email'] lo apunta de forma fiable.
Una página tiene un enlace <a href="/logout">Log out</a>. Hay varios enlaces, pero solo este tiene el texto exacto 'Log out'. ¿Qué XPath lo selecciona por su texto visible?
//a[text()='Log out']
Correcto: coincide con el enlace cuyo texto es 'Log out'.
//a[@text='Log out']
Incorrecto: no existe el atributo 'text'; el texto visible es un nodo de texto.
//a[@href='Log out']
Incorrecto: eso compara el valor de href '/logout', no el texto.
//text()='Log out'
Incorrecto: no es una expresión XPath válida que seleccione un elemento.
//a[text()='Log out'] coincide con un <a> cuyo nodo de texto es exactamente 'Log out'. normalize-space() serviría si hubiera espacios.
¿Qué selector CSS coincide con un <a> cuyo atributo href termina en '.pdf'?
a[href$='.pdf']
Correcto: '$=' significa 'termina con'.
a[href^='.pdf']
Incorrecto: '^=' significa 'empieza con', no termina con.
a[href*='.pdf']
'*=' significa 'contiene' en cualquier lugar, también coincide con '.pdf.html' — no es 'termina con'.
a[href='.pdf']
Incorrecto: exige que href sea exactamente '.pdf'.
El operador '$=' en CSS coincide con un valor de atributo que termina con la subcadena: a[href$='.pdf'].
Elemento: <button class="btn primary" data-test="save">Save</button>. ¿Qué DOS localizadores coinciden correcta y únicamente con este botón (los valores data-test son únicos)? (Seleccione DOS)
css=button[data-test='save']
Correcto: data-test es único y estable, un localizador ideal.
//button[text()='Save']
Correcto: coincide con el botón por su texto exacto 'Save'.
css=.btn
Incorrecto: 'btn' es una clase genérica compartida y coincidirá con muchos botones.
css=#save
Incorrecto: el botón no tiene id, '#save' no coincide con nada.
css=button[data-test='save'] usa el atributo único data-test; //button[text()='Save'] coincide con su texto exacto. css=.btn es compartido; la forma con id es inválida porque no hay id.
En Selenium 4 quiere encontrar el input situado justo encima de una etiqueta con id 'password'. ¿Qué expresión de localizador relativo es correcta?
with(By.tagName("input")).above(By.id("password"))
Correcto: es la API de localizadores relativos de Selenium 4 para 'above'.
By.above("input", "password")
Incorrecto: By no tiene método 'above'; los relativos usan with().
By.cssSelector("input:above(#password)")
Incorrecto: ':above' no es una pseudoclase CSS válida.
with(By.id("password")).below(By.tagName("input"))
Incorrecto: invierte la relación y se ancla en el elemento equivocado.
Los localizadores relativos de Selenium 4 usan With.tagName(...).above(...). Así with(By.tagName("input")).above(By.id("password")).
Una fila de tabla: <tr><td>ACME Ltd</td><td><button class="del">Delete</button></td></tr>. Debe pulsar el botón Delete de la fila cuya primera celda es 'ACME Ltd'. ¿Qué XPath es correcto?
//td[text()='ACME Ltd']/ancestor::tr//button[text()='Delete']
Correcto: se ancla en la celda identificadora y encuentra el botón Delete de esa misma fila.
//button[text()='Delete']
Incorrecto: coincide con todos los botones Delete, no con la fila específica.
//td[text()='ACME Ltd']//button
Incorrecto: el botón no es descendiente de la primera celda, sino de una celda hermana.
//tr[text()='ACME Ltd']//button
Incorrecto: el texto 'ACME Ltd' pertenece al <td>, no directamente al <tr>.
Anclar en el texto único de la celda, subir a la fila y bajar al botón: //td[text()='ACME Ltd']/ancestor::tr//button[text()='Delete'].
¿Qué DOS prácticas hacen los localizadores más robustos ante cambios de UI? (Seleccione DOS)
Preferir atributos estables y dedicados como id o data-test.
Correcto: los anclajes de prueba dedicados rara vez cambian con estilo o diseño.
Mantener los localizadores cortos y relativos a un ancestro estable.
Correcto: los localizadores poco profundos y relativos toleran mejor la reestructuración del DOM.
Usar XPath absoluto completo desde /html/body.
Incorrecto: las rutas absolutas se rompen en cuanto cambia un elemento intermedio.
Depender de índices posicionales como (//div)[7].
Incorrecto: los localizadores por índice se rompen al añadir o reordenar elementos.
Anclajes estables y dedicados (id, data-test) y localizadores cortos y poco profundos resisten cambios. XPath absoluto largo y posiciones por índice son frágiles.
¿Cuál es la idea central del Page Object Model (POM)?
Encapsular los localizadores y acciones de cada página en una clase dedicada.
Correcto: centraliza los localizadores y expone el comportamiento como métodos, mejorando el mantenimiento.
Guardar todos los datos de prueba en un solo objeto.
Incorrecto: eso describe un patrón de datos/fixtures, no POM.
Escribir cada prueba en un solo método largo.
Incorrecto: es lo opuesto a la estructura modular que promueve POM.
Reemplazar WebDriver por un mock en cada prueba.
Incorrecto: POM es un patrón de diseño, no una estrategia de mocking.
POM encapsula los localizadores e interacciones de una página en una clase dedicada, de modo que las pruebas llaman métodos significativos en vez de duplicar código.
Según la buena práctica de POM, ¿dónde deben ubicarse normalmente las aserciones?
En los métodos de prueba, no dentro de los page objects.
Correcto: mantener las aserciones en las pruebas hace que los page objects sean reutilizables.
Dentro de cada método del page object.
Incorrecto: incrustar aserciones acopla los page objects a expectativas concretas y daña la reutilización.
En el constructor de WebDriver.
Incorrecto: la inicialización del driver no tiene que ver con las aserciones.
En el HTML de la página bajo prueba.
Incorrecto: las aserciones son código de prueba, no parte del marcado.
Las aserciones van en los métodos de prueba, no en los page objects. Estos modelan estructura/acciones y devuelven datos/estado que la prueba verifica.
En un POM bien diseñado, una LoginPage tiene un método login(user, pass) que envía credenciales válidas y llega al panel. ¿Qué debería devolver login() para que la prueba continúe con fluidez?
Un objeto DashboardPage que representa la página resultante.
Correcto: devolver el siguiente page object permite encadenar pasos con fluidez y seguridad de tipos.
Un booleano 'true' si hay algún elemento presente.
Incorrecto: un booleano descarta el contexto de navegación y obliga a relocalizar todo.
La instancia cruda de WebDriver.
Incorrecto: exponer el driver rompe la encapsulación que POM debe aportar.
void (nada).
Incorrecto: no devolver nada tras cambiar de página obliga a reinstanciar manualmente la siguiente.
Una acción de navegación que lleva a otra página debe devolver el siguiente page object (p. ej. DashboardPage), permitiendo encadenar interacciones con seguridad de tipos.
En la variante PageFactory de POM, ¿qué hace la anotación @FindBy?
Declara el localizador para resolver un campo WebElement.
Correcto: @FindBy asocia un localizador a un campo, resuelto de forma perezosa por PageFactory.
Ejecuta una aserción sobre el elemento.
Incorrecto: solo declara cómo encontrar el elemento, no qué afirmar.
Inicia el navegador.
Incorrecto: no tiene relación con iniciar una sesión del driver.
Toma una captura del elemento.
Incorrecto: las capturas no tienen relación con @FindBy.
@FindBy declara el localizador de un campo WebElement; PageFactory.initElements(...) crea proxies perezosos que resuelven el localizador al usar el campo.
Un localizador del botón 'Checkout' se usa en 15 pruebas. La id del botón cambia. Con un Page Object Model bien aplicado, ¿cuántos lugares debe actualizar?
Uno — el localizador en el page object.
Correcto: centralizar el localizador hace que una sola edición arregle las 15 pruebas.
Quince — uno por prueba.
Incorrecto: esa duplicación es justo lo que POM elimina.
Treinta — el localizador más su aserción en cada prueba.
Incorrecto: las aserciones son aparte y el localizador sigue centralizado.
Ninguno — Selenium auto-repara localizadores.
Incorrecto: Selenium no tiene auto-reparación de localizadores.
POM centraliza cada localizador en una clase de página, por lo que un cambio se corrige en un solo lugar sin importar cuántas pruebas lo usen.
¿Qué DOS elementos pertenecen a una clase page object? (Seleccione DOS)
Localizadores de elementos de esa página.
Correcto: los localizadores son el contenido principal de un page object.
Métodos de acción como search() o login().
Correcto: los métodos de comportamiento exponen las interacciones a las pruebas.
Las aserciones de éxito/fallo de cada prueba.
Incorrecto: las aserciones van en las pruebas, manteniendo reutilizables los page objects.
La configuración de planificación del runner.
Incorrecto: la configuración del runner es infraestructura, no modelado de página.
Un page object contiene los localizadores de elementos y métodos de acción/servicio (p. ej. login, search). Las aserciones y la planificación de la suite no van ahí.
¿Cuál es la diferencia clave entre una espera implícita y una explícita?
La implícita es global; la explícita apunta a una condición concreta.
Correcto: la implícita aplica en todo; la explícita espera una condición definida.
La implícita pausa siempre un número fijo de segundos sin importar el estado.
Incorrecto: eso describe Thread.sleep; la implícita sondea y retorna al encontrar.
La explícita es global; la implícita apunta a un elemento.
Incorrecto: los roles están invertidos.
Son iguales y pueden mezclarse sin efectos secundarios.
Incorrecto: difieren, y mezclarlas puede causar timeouts impredecibles.
Una espera implícita es un timeout global aplicado a cada búsqueda; una espera explícita apunta a una condición concreta de un elemento concreto.
Tras pulsar 'Load more', los resultados se inyectan por AJAX y un contenedor con id 'results' se vuelve visible tras un retardo variable. Debe esperar a que sea visible. ¿Cuál es la espera explícita correcta en Selenium 4?
new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.visibilityOfElementLocated(By.id("results")))
Correcto: espera hasta 10 s a presencia y visibilidad antes de retornar.
Thread.sleep(10000)
Incorrecto: un sleep fijo es lento o frágil y no verifica la condición.
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)) y luego getText()
Incorrecto: la espera implícita cubre presencia pero no visibilidad; leer un contenedor oculto puede fallar.
driver.findElement(By.id("results")).getText() de inmediato
Incorrecto: sin espera lanza NoSuchElementException mientras AJAX aún carga.
Usar WebDriverWait con Duration y ExpectedConditions.visibilityOfElementLocated(By.id("results")) para esperar presencia y visibilidad.
¿Por qué se desaconseja Thread.sleep() como mecanismo de sincronización en pruebas Selenium?
Siempre espera todo el tiempo fijo, haciendo las pruebas lentas o frágiles según el valor.
Correcto: ignora el estado real, desperdicia tiempo o falla de forma intermitente.
No está soportado por el lenguaje Java.
Incorrecto: Thread.sleep es Java estándar; el problema es el comportamiento, no la disponibilidad.
Cierra la sesión del navegador.
Incorrecto: dormir no afecta la sesión de WebDriver.
Sondea el DOM cada 500 ms como una espera explícita.
Incorrecto: no sondea; solo bloquea durante la duración fija.
Thread.sleep pausa una duración fija sin importar la disponibilidad: lento si es larga y frágil si es corta.
Un botón 'Submit' está en el DOM pero permanece deshabilitado hasta que el formulario es válido. Pulsarlo antes no hace nada. ¿Qué ExpectedCondition debe esperar antes de click()?
ExpectedConditions.elementToBeClickable(...)
Correcto: exige visible Y habilitado, acorde al botón deshabilitado hasta ser válido.
ExpectedConditions.presenceOfElementLocated(...)
Incorrecto: presencia solo verifica que esté en el DOM; el botón existe pero está deshabilitado.
ExpectedConditions.titleContains(...)
Incorrecto: verifica el título de la página, ajeno al estado del botón.
ExpectedConditions.alertIsPresent()
Incorrecto: no hay ninguna alerta en este escenario.
elementToBeClickable espera a que el elemento sea visible Y esté habilitado, justo la condición para un botón que se habilita solo con el formulario válido.
¿Qué permite configurar un FluentWait que una llamada simple al constructor de WebDriverWait no enfatiza?
El intervalo de sondeo y qué excepciones ignorar durante el sondeo.
Correcto: FluentWait expone pollingEvery(...) e ignoring(...) junto al timeout.
La cadena user-agent del navegador.
Incorrecto: el user-agent es una opción del navegador, no parte de una espera.
La resolución de pantalla de la máquina de prueba.
Incorrecto: no se relaciona con la lógica de espera.
El número de hilos paralelos de la suite.
Incorrecto: el paralelismo se configura en el runner, no en una espera.
FluentWait permite fijar el intervalo de sondeo e ignorar tipos de excepción durante el sondeo, además del timeout global.
¿Qué DOS son ExpectedConditions válidas de la librería de soporte de Selenium? (Seleccione DOS)
visibilityOfElementLocated(By)
Correcto: condición estándar que espera presencia y visibilidad.
textToBePresentInElement(element, text)
Correcto: condición estándar que espera un texto concreto en un elemento.
elementHasNiceColor(By)
Incorrecto: no existe tal condición en Selenium.
pageIsBeautiful()
Incorrecto: inventada; no forma parte de la API ExpectedConditions.
visibilityOfElementLocated y textToBePresentInElement son ExpectedConditions estándar. 'elementHasNiceColor' y 'pageIsBeautiful' son inventadas.
¿Qué par de llamadas carga una URL en la ventana actual del navegador?
driver.get(url) y driver.navigate().to(url)
Correcto: ambos navegan a la URL dada en la ventana actual.
driver.open(url) y driver.load(url)
Incorrecto: ni open() ni load() existen en WebDriver.
driver.goTo(url) y driver.visit(url)
Incorrecto: esos nombres no forman parte de la API de WebDriver.
driver.getUrl(url) y driver.setUrl(url)
Incorrecto: getCurrentUrl() lee la URL sin argumento; setUrl() no existe.
Tanto driver.get(url) como driver.navigate().to(url) cargan una página; get() es la forma abreviada y navigate() añade historial (back()/forward()).
¿Qué llamada regresa a la página anterior del historial del navegador?
driver.navigate().back()
Correcto: navega una entrada atrás en el historial.
driver.back()
Incorrecto: back() está en el objeto Navigation, no directamente en driver.
driver.navigate().refresh()
Incorrecto: refresh() recarga la página actual, no retrocede.
driver.navigate().forward()
Incorrecto: forward() avanza, no retrocede.
driver.navigate().back() retrocede un paso en el historial, como el botón Atrás.
Un formulario de pago está dentro de un <iframe id="pay">. Tras rellenar y enviar sus campos, debe pulsar un botón 'Continue' que está en el documento PRINCIPAL, fuera del iframe. ¿Qué debe hacer antes de localizar 'Continue'?
Llamar driver.switchTo().defaultContent() para volver al documento principal.
Correcto: restablece el foco al documento superior para poder localizar elementos de la página principal.
Llamar de nuevo driver.switchTo().frame("pay").
Incorrecto: eso te mantiene dentro del iframe, donde 'Continue' no existe.
Recargar la página con navigate().refresh().
Incorrecto: recargar descarta el estado del formulario y no resuelve el contexto del frame.
Nada — los elementos del documento principal siempre son accesibles desde un iframe.
Incorrecto: con el foco en el iframe, los elementos del documento superior no están en contexto.
Con el foco dentro del iframe, el documento principal queda fuera de contexto. Hay que volver con driver.switchTo().defaultContent().
Aparece un diálogo confirm() de JavaScript. ¿Cómo lo acepta (OK) en Selenium?
driver.switchTo().alert().accept()
Correcto: cambia al alert y pulsa OK.
driver.findElement(By.id("ok")).click()
Incorrecto: los diálogos nativos no forman parte del DOM y no se localizan con By.
driver.switchTo().alert().dismiss()
Incorrecto: dismiss() cancela (pulsa Cancelar), no acepta.
driver.navigate().refresh()
Incorrecto: recargar no interactúa con el diálogo.
Cambiar al alert y aceptarlo: driver.switchTo().alert().accept(). dismiss() lo cancelaría.
Pulsar 'View invoice' abre la factura en una NUEVA pestaña. Debe leer texto en ella, cerrarla y volver a la pestaña original. ¿Qué secuencia es correcta?
Guardar el handle actual, switchTo().window(newHandle), leer, close(), luego switchTo().window(originalHandle).
Correcto: hay que cambiar explícitamente a la nueva pestaña y volver tras cerrarla.
Solo llamar getText() — WebDriver sigue la nueva pestaña automáticamente.
Incorrecto: el foco permanece en la pestaña original hasta switchTo().window(...).
Llamar driver.navigate().forward() para llegar a la nueva pestaña.
Incorrecto: forward() se mueve en el historial de una pestaña, no entre pestañas.
Llamar driver.quit() y reabrir la página original.
Incorrecto: quit() finaliza toda la sesión y pierde el estado.
Guardar el handle original, encontrar el nuevo en getWindowHandles(), switchTo().window(newHandle), leer/cerrar, luego switchTo().window(originalHandle).
Un submenú aparece solo al pasar el ratón sobre un elemento del menú superior. ¿Qué API de Selenium modela este hover-luego-clic?
La clase Actions, p. ej. new Actions(driver).moveToElement(menu).click(submenu).perform()
Correcto: Actions modela secuencias de puntero avanzadas como hover-luego-clic.
driver.get() en la URL del submenú.
Incorrecto: el submenú no es una URL aparte; aparece por el estado hover.
driver.switchTo().frame(menu)
Incorrecto: cambiar de frame no tiene que ver con el hover del menú.
driver.manage().window().fullscreen()
Incorrecto: fullscreen cambia el tamaño de la ventana, no el hover.
La clase Actions construye secuencias compuestas; moveToElement(menu).click(submenu).perform() realiza el hover y el clic.
¿Qué es una prueba automatizada 'flaky' (inestable)?
Una prueba que a veces pasa y a veces falla sin cambio de código ni entorno.
Correcto: resultados no deterministas sin cambio real es la definición.
Una prueba que siempre falla.
Incorrecto: una prueba que siempre falla es determinista e indica un defecto real.
Una prueba con más de 100 pasos.
Incorrecto: la longitud por sí sola no hace flaky una prueba.
Una prueba escrita en un lenguaje de scripting.
Incorrecto: el lenguaje no tiene relación con la inestabilidad.
Una prueba flaky da resultados distintos (pasa/falla) con el mismo código y entorno sin cambio real, minando la confianza en la suite.
¿Cuál es la causa más común de pruebas Selenium inestables?
Problemas de tiempo/sincronización — actuar antes de que los elementos estén listos.
Correcto: las condiciones de carrera entre prueba y render son la causa principal; las esperas explícitas lo resuelven.
Usar muy pocos comentarios en el código.
Incorrecto: los comentarios no afectan el comportamiento en ejecución.
Nombrar los métodos de prueba en inglés.
Incorrecto: el idioma de los nombres es irrelevante para la estabilidad.
Compilar las pruebas en vez de interpretarlas.
Incorrecto: compilar vs. interpretar no causa inestabilidad.
Problemas de tiempo/sincronización — interactuar con elementos aún no listos — son la causa principal, resuelta con esperas explícitas.
Una prueba guarda un WebElement en una variable, luego la página re-renderiza una lista por AJAX, y la siguiente acción sobre esa variable lanza StaleElementReferenceException. ¿Cuál es la solución correcta?
Re-localizar el elemento tras la actualización del DOM en lugar de reutilizar la referencia stale.
Correcto: el nodo antiguo fue reemplazado; un findElement nuevo (tras espera) resuelve el nodo actual.
Envolver la acción en try/catch e ignorar la excepción.
Incorrecto: tragar la excepción oculta el fallo y la acción sigue sin ocurrir.
Aumentar la espera implícita a 60 segundos.
Incorrecto: una espera implícita mayor no refresca una referencia ya stale.
Reiniciar el navegador antes de cada acción.
Incorrecto: reiniciar es drástico, lento e innecesario; basta con re-localizar.
Una referencia stale apunta a un nodo del DOM reemplazado. La solución es re-localizar el elemento tras el cambio del DOM (idealmente tras una espera explícita).
¿Por qué cada prueba automatizada debe ser independiente de las demás?
Para que se ejecuten en cualquier orden o en paralelo y un fallo no se propague.
Correcto: la independencia permite paralelismo y aísla fallos para un diagnóstico claro.
Para que la suite sea más lenta y fácil de observar.
Incorrecto: la independencia favorece la velocidad por paralelismo.
Para que las pruebas compartan siempre una sesión de navegador.
Incorrecto: la independencia suele implicar lo contrario — sesiones/estado aislados.
Para poder eliminar todas las aserciones.
Incorrecto: la independencia no tiene que ver con eliminar aserciones.
Las pruebas independientes se ejecutan en cualquier orden y en paralelo, y un fallo en una no se propaga a otras, mejorando fiabilidad y diagnóstico.
¿Qué DOS prácticas reducen la inestabilidad en una suite Selenium sobre un servidor CI? (Seleccione DOS)
Usar esperas explícitas para la condición exacta en vez de sleeps fijos.
Correcto: las esperas por condición se adaptan al tiempo variable del CI y reducen la inestabilidad.
Que cada prueba cree y limpie sus propios datos aislados.
Correcto: los datos autocontenidos evitan interferencias entre pruebas, sobre todo en CI paralelo.
Insertar Thread.sleep(5000) antes de cada interacción.
Incorrecto: los sleeps fijos son lentos y siguen siendo frágiles si el servidor es más lento.
Hacer que las pruebas dependan de los datos que dejó la prueba anterior.
Incorrecto: depender del orden es una fuente clásica de inestabilidad, sobre todo en paralelo.
Usar esperas explícitas para condiciones y que cada prueba prepare sus datos aislados reducen la inestabilidad. Los sleeps fijos y depender del orden la aumentan.
Capturar automáticamente una captura de pantalla cuando una prueba falla ayuda sobre todo a qué?
Diagnosticar por qué falló mostrando el estado de la UI en ese momento.
Correcto: la captura es un artefacto de diagnóstico del estado de fallo, muy útil en CI.
Hacer que la prueba se ejecute más rápido.
Incorrecto: tomar una captura añade un pequeño coste; no acelera la ejecución.
Evitar que ocurra el fallo.
Incorrecto: una captura registra el fallo; no puede evitarlo.
Reparar automáticamente el localizador roto.
Incorrecto: las capturas no modifican ni reparan el código de prueba.
Una captura de fallo registra el estado de la UI en el momento del fallo, acelerando la depuración, sobre todo en CI headless.