Prueba Selenium vs Cypress para contratación de QA automatizado

La pregunta de contratación que los equipos realmente hacen

"¿Deberíamos contratar para Selenium o Cypress?" es la pregunta equivocada. La pregunta correcta es: "¿Qué revela la elección del framework sobre la capacidad de ingeniería?"

Selenium y Cypress prueban cosas diferentes de maneras diferentes. En un contexto de contratación, esa diferencia importa. Un framework te mostrará si un candidato entiende la arquitectura de pruebas. El otro te mostrará si pueden escribir pruebas rápidas y frágiles que funcionan en una demostración y se rompen en la realidad.

Selenium: La prueba distribuida

Selenium se ejecuta en un proceso separado del navegador. Las pruebas son cliente-servidor. Hay latencia, hay trabajo asincrónico, hay complejidad del mundo real.

Lo que las pruebas de Selenium revelan en contratación:

• ¿Puede el candidato manejar operaciones asincrónicas (esperas, tiempos de espera, condiciones de carrera)?
• ¿Entienden el protocolo WebDriver y la comunicación del navegador?
• ¿Pueden depurar cuando una prueba es inestable — es la aplicación, la red, o la prueba misma?
• ¿Saben cómo estructurar páginas para testabilidad (identificación de elementos, gestión de estado)?

En evaluación: Un candidato que escribe pruebas robustas de Selenium — con esperas explícitas, selectores inteligentes, lógica de limpieza — te muestra que entiende las restricciones reales de la automatización del navegador. No están optimizando para velocidad. Están optimizando para confiabilidad.

La desventaja: Las pruebas de Selenium son más lentas de escribir, más lentas de depurar, y requieren más conocimiento de infraestructura. Un junior puede frustrarse rápidamente.

Cypress: La ilusión sincrónica

Cypress se ejecuta en el proceso, en el mismo contexto del navegador que la aplicación. Sin protocolo WebDriver. Sin latencia. Las pruebas se leen como JavaScript sencillo sincrónico.

Lo que las pruebas de Cypress revelan en contratación:

• ¿Puede el candidato escribir JavaScript limpio y legible?
• ¿Entienden las restricciones de su framework (sin tabulaciones cruzadas, sin múltiples dominios)?
• ¿Pueden depurar cuando las cosas fallan (y lo harán, diferente que Selenium)?
• ¿Están conscientes de las opiniones de Cypress y por qué existen?

En evaluación: Un candidato que conoce las limitaciones de Cypress y trabaja dentro de ellas te muestra que leyó la documentación y piensa sobre la elección de herramientas. Un candidato que intenta trabajar alrededor de las restricciones de Cypress (esperas raras, polling, recargas de página) te muestra que están luchando contra la herramienta en lugar de entenderla.

La ventaja: Las pruebas son más rápidas de escribir. La desventaja: Es fácil escribir pruebas que se ven bien pero en realidad son frágiles, porque Cypress esconde la complejidad asincrónica.

Lo que cada framework revela sobre el juicio

Aquí es donde la contratación se vuelve sutil.

Un candidato que dice "usaría Cypress porque las pruebas son más fáciles de escribir" te muestra que optimiza para velocidad de escritura. Probablemente está bien para una startup, probablemente malo para un monolito de 5 años.

Un candidato que dice "usaría Selenium porque es más realista" te muestra que piensan sobre restricciones de producción. Pero si eligen Selenium para un SPA simple, podrían estar sobre-ingenierizando.

El candidato que quieres es el que dice: "Depende de la aplicación. Cypress para esta herramienta interna, Selenium para el flujo de compra entre dominios, Playwright para todo lo demás el próximo trimestre."

Eso es juicio. Eso es quién encuentra bugs y mantiene suites de pruebas.

Qué framework usar en tu evaluación

Si estás contratando a alguien para mantener una suite Selenium heredada: Usa Selenium. Es como pedirle a un cirujano que use el bisturí que realmente usará en el quirófano.

Si estás contratando para un SPA moderno: Cypress está bien, pero haz preguntas de seguimiento sobre limitaciones. Si no mencionan "sin dominios cruzados", no están pensando críticamente.

Si no te importa cuál conozcan: Usa el que tu equipo conozca mejor, para que puedas calificar el diseño de pruebas, no la sintaxis. O usa Playwright — es la tercera opción que ha estado ganando conversaciones de contratación desde 2024 porque es honesto sobre qué hace.

El patrón de evaluación que funciona

La elección del framework importa menos que cómo lo usan.

Dale una especificación ("Prueba el flujo de compra") y déjalos elegir. Su elección revela conciencia del contexto. Su implementación revela disciplina.

Puntúa en estos:

• ¿Identifican el alcance correcto (qué probar, qué saltar)?
• ¿Escriben selectores que sobrevivirán cambios de UI?
• ¿Manejan las esperas explícitamente o dependen de magia implícita?
• ¿Tienen lógica de configuración/limpieza, o es cada prueba frágil y aislada?
• ¿Pueden articular por qué eligieron este enfoque en este framework?

Un candidato que escribe 3 pruebas robustas en Selenium es más fuerte que uno que escribe 10 pruebas frágiles en Cypress, incluso si Cypress es tu estándar. La disciplina importa más que la herramienta.

Contra-posición: Se trata del pensamiento de pruebas

Algunos equipos argumentan que el framework no importa en absoluto — que los buenos ingenieros de QA aprenden cualquier framework en una semana, y la contratación debe enfocarse en estrategia de pruebas, no sintaxis.

Esto es parcialmente cierto. Un fuerte solucionador de problemas se transfiere a través de frameworks rápidamente. Pero el conocimiento del framework sí revela pensamiento: cómo manejan lo asincrónico, cómo estructuran código, si han luchado contra restricciones del framework antes. Ese es un patrón que quieres ver.

El enfoque correcto: No filtres candidatos por framework. Pero sí evalúa cómo piensan dentro de un framework, y pregunta por qué eligieron el enfoque que eligieron.

Qué buscar en una evaluación de automatización de pruebas

Si estás usando una evaluación formal, busca plataformas que:

• Dejen que los candidatos elijan su framework (Selenium, Cypress, Playwright, WebDriver, etc.)
• Califiquen en cobertura de pruebas y calidad de código, no solo aprobado/reprobado
• Capturen el código que escriben para que puedas revisar su estructura y comentarios
• Reporten en tiempo de ejecución e inestabilidad, no solo si las pruebas se ejecutaron

El framework es un vehículo. La señal real es si lo conducen bien.