Lo que evalúan los empleadores: tests cognitivos, verbales y numéricos
Llegar a una entrevista en una gran corporación puede suponer un desafío inesperado: te presentas preparado para demostrar tu dominio de las técnicas de prueba, microservicios y automatización, pero te entregan una hoja con acertijos lógicos de nivel escolar sobre manzanas o pruebas de comprensión lectora. Este contraste entre la experiencia profesional y las pruebas de selección abstractas suele tomar a los candidatos totalmente por sorpresa.
Surge una pregunta razonable: ¿para qué?
¿Por qué un empleador quiere evaluar algo que aparentemente no está relacionado directamente con tu trabajo? La respuesta es más compleja de lo que parece. Y si quieres construir una carrera en una gran empresa, necesitas entenderla.
Por qué las corporaciones no confían en títulos y portafolios
Las grandes empresas reciben miles de currículums al mes. Cualquier título se puede comprar, cualquier proyecto del portafolio se puede atribuir (o hacer en un equipo de veinte personas donde tu papel fue mínimo). Los profesionales de RRHH necesitan una herramienta objetiva que funcione igual para todos.
Pero la razón principal es más profunda.
En un estudio pequeño, trabajas con un stack tecnológico concreto. Llegas, ves, arreglas un error. En una corporación, te enfrentas a situaciones sin instrucciones predefinidas. Pueden darte una tarea que nadie ha resuelto antes. O descubres que la documentación se escribió hace quince años y los programadores que la escribieron ya no trabajan en la empresa.
La corporación no evalúa lo que sabes ahora. Evalúa si podrás entender lo que aún nadie sabe.
[EJEMPLO] En 2018, un gran sistema bancario migraba a una nueva plataforma de contabilidad de transacciones. Las pruebas antiguas no funcionaban, no había documentación nueva. Un tester que había superado con éxito las pruebas cognitivas en la contratación propuso construir un modelo de comportamiento del sistema utilizando la lógica de la ingeniería inversa. No conocía el código de la plataforma, pero su capacidad para identificar patrones y formular hipótesis funcionó mejor que el conocimiento de una herramienta específica. [FIN]
Ahora analicemos qué evalúa exactamente cada tipo de prueba y por qué esto afecta directamente tu carrera.
Tests cognitivos: cómo miden la "velocidad de tu procesador"
Cuando realizas un test cognitivo, te dan problemas de lógica, razonamiento espacial, análisis de patrones. No es una prueba de inteligencia en general, sino una prueba de velocidad de procesamiento de información en condiciones de incertidumbre.
Qué se evalúa realmente
Los tests cognitivos en las corporaciones están diseñados para simular situaciones laborales típicas:
- Te dan un conjunto de datos (por ejemplo, un gráfico de lanzamientos de versiones y la cantidad de errores en cada uno).
- Hay justo suficientes datos para que no puedas analizarlos todos por completo.
- Tienes tiempo limitado para resolverlo.
En esencia, es un modelo del trabajo de un tester en condiciones de "combate": el lanzamiento es mañana, los requisitos cambiaron tres veces, necesitas decidir rápidamente qué pruebas ejecutar para que nada se rompa, pero cumpliendo con el plazo.
Por qué "mejorar" estas habilidades afecta tu salario
La capacidad de encontrar rápidamente patrones en el caos es lo que diferencia a un tester de un ingeniero de pruebas. El primero espera requisitos claros. El segundo los crea por sí mismo.
[CONSEJO] Entrena tus habilidades cognitivas no con tests abstractos, sino con tareas laborales reales. Cada semana, proponte un objetivo: "Entender un módulo del sistema que no conozco y crear un mapa de su lógica". Esto desarrolla las mismas conexiones neuronales que los problemas abstractos con figuras y secuencias. [FIN]
Imagina que llegas a un proyecto donde el 90% del código es legado, escrito en un lenguaje obsoleto. No hay requisitos, la documentación son, en el mejor de los casos, comentarios en el código de hace diez años. Tu aparato cognitivo debe cambiar instantáneamente: identificar patrones de funcionamiento del sistema, encontrar errores por signos indirectos, extrapolar el comportamiento de módulos conocidos a los desconocidos.
Las personas que obtienen buenos resultados en tests cognitivos no son solo "más inteligentes". Se adaptan más rápido a los cambios de contexto. Y en una gran empresa, el contexto cambia semanalmente.
Tests verbales: la batalla por el significado
Un test verbal no es una prueba de gramática ni un dictado. Es una prueba de cómo trabajas con la información en condiciones de ruido cognitivo.
Cómo es la evaluación real
Te dan un texto de una página, por ejemplo, la descripción de una nueva normativa regulatoria o una política de seguridad. La tarea: leer y determinar cuál de las cinco conclusiones es lógicamente correcta, cuál es falsa y cuál no se deduce del texto.
¿Suena fácil? Solo que el texto está escrito de manera que cada palabra tiene peso legal. Y las opciones de respuesta están formuladas para comprobar si ves la diferencia entre "puede ser" y "es", entre "todos" y "la mayoría", entre "se recomienda" y "es obligatorio".
[EJEMPLO] Texto: "La compañía recomienda realizar pruebas de regresión antes de cada lanzamiento mayor, sin embargo, para versiones de parche se permite una verificación selectiva de la funcionalidad crítica".
Pregunta: ¿Se deduce del texto que las pruebas de regresión antes de un lanzamiento mayor son obligatorias?
Opciones: "Sí", "No", "No se puede determinar a partir del texto".
La respuesta correcta es "No se puede determinar". La palabra "recomienda" expresa un deseo, pero no un requisito. Sin embargo, muchos testers, acostumbrados al pensamiento algorítmico, eligen "Sí" porque creen que recomendar significa que hay que hacerlo. [FIN]
Por qué es crítico para QA
Tu trabajo no es solo encontrar un error. Tu trabajo es comunicarlo correctamente. Si escribes en un informe de error "La aplicación va lenta", el desarrollador no te entenderá. Si escribes "El tiempo de respuesta del formulario supera los 5 segundos con 1000 solicitudes simultáneas", ya es información procesable.
Las corporaciones son enormes máquinas de producir documentos. Pliegos de condiciones, especificaciones, políticas, informes. Cada día lees textos donde la ambigüedad puede costar millones.
El test verbal evalúa tu resistencia a esa ambigüedad. Filtra a las personas que "completan" el significado donde no existe.
[FÓRMULA] Crecimiento profesional en una corporación = capacidad para entender requisitos incompletos + habilidad para formularlos de manera que no puedan ser malinterpretados. [FIN]
Tests numéricos: las matemáticas de la toma de decisiones
Los tests numéricos no son "resuelve la ecuación". Es trabajar con datos en tiempo real.
Dónde está el truco
Te dan una tabla con datos: número de pedidos por mes, porcentaje de devoluciones, cantidad de errores de diferentes categorías. Y te preguntan: "¿Cómo cambió la proporción de errores críticos respecto al total en el segundo trimestre en comparación con el primero?"
Hay muchos datos en la tabla, algunos son redundantes. Necesitas encontrar exactamente los que se refieren a la pregunta. Y hacerlo rápido, porque el tiempo es limitado.
El error típico de los principiantes: intentan analizar todos los datos en lugar de encontrar la respuesta concreta. Detrás de esto hay miedo a perderse algo importante. Pero en una gran empresa, la capacidad de descartar lo superfluo a menudo es más importante que la capacidad de verlo todo.
[EJEMPLO] Imagina que eres responsable de probar el backend de un sistema de pagos. Te llegan datos: número de transacciones, tiempo medio de respuesta, porcentaje de errores, número de pagos cancelados, horas de carga pico. En una reunión con el gerente, te preguntan: "¿Qué proporción de errores corresponde a las tarjetas de un banco específico?" Si empiezas a hablar de las estadísticas generales de todos los errores, pierdes el tiempo del gerente. Si enseguida extraes los datos necesarios, demuestras que entiendes el contexto de la tarea. [FIN]
Los tests numéricos evalúan tu disposición para tomar decisiones empresariales basadas en datos. No solo "encontrar un error", sino "evaluar su impacto empresarial".
Cómo se relaciona con la carrera
Un tester que solo ve código se queda como ejecutor. Un tester que ve números se convierte en analista. Un analista que puede traducir números en estrategia se convierte en arquitecto de soluciones.
[CONSEJO] Antes de escribir un caso de prueba, intenta responder tres preguntas:
- ¿Qué pasará con el negocio si este error llega a producción?
- ¿A cuántos usuarios afectará?
- ¿Qué porcentaje de todos los escenarios de uso cubre esta prueba?
Si puedes responder estas preguntas, ya no eres solo un tester, eres el dueño de la calidad del producto. [FIN]
Cómo prepararse para los tests: un enfoque sistemático
Aquí está la trampa principal: la gente intenta prepararse para estos tests como para los exámenes. Memorizan fórmulas, resuelven decenas de ejemplos.
Esto no funcionará.
Estos tests no evalúan conocimientos, sino patrones neuronales. No se pueden aprender; solo se pueden entrenar en el contexto de tareas reales.
Estrategia de preparación
Primer paso: deja de dividir las tareas en "laborales" y "de entrenamiento". Cualquier análisis de requisitos, cualquier lectura de documentación, cualquier evaluación de un error es preparación.
Segundo paso: crea condiciones de tiempo limitado. Intenta leer una especificación en 10 minutos y anotar los tres escenarios de prueba principales. No te des más tiempo; que el cerebro se acostumbre a trabajar rápido.
Tercer paso: aprende a hacer preguntas. No "¿qué significa esto?", sino "¿qué interpretaciones de este texto son posibles?". Esto desarrolla ese pensamiento verbal que las corporaciones evalúan.
Herramientas específicas
Para desarrollar el pensamiento numérico, trabaja con paneles de control. No solo mires los gráficos, intenta predecir las cifras: "Si este mes lanzamos tres versiones, ¿cómo cambiará la cantidad de errores de regresión el próximo mes?"
Para habilidades cognitivas, ingeniería inversa de cualquier proceso. Analiza cómo funciona tu herramienta de automatización. No solo la uses; entiende la lógica con la que funciona.
[FÓRMULA] Nivel de tester = velocidad de análisis en condiciones de incertidumbre × calidad de la formulación verbal × habilidad para trabajar con datos. [FIN]
Trampas típicas en el camino del crecimiento
Incluso si superas los tests perfectamente, te esperan tres trampas que pueden frenar tu carrera.
La trampa del agotamiento
Las capacidades cognitivas no son un recurso infinito. La optimización y la búsqueda de patrones son procesos que consumen mucha energía. Las corporaciones en este sentido son como el deporte de alto rendimiento: puedes trabajar al límite durante seis meses, pero después de un año corres el riesgo de agotarte.
Señal: notas que te has vuelto más lento resolviendo tareas simples, te confundes en módulos familiares, te pierdes errores evidentes.
Solución: introduce "días de desaceleración". Una vez a la semana, un día sin análisis complejo. Solo rutina: documentación, comprobaciones de regresión simples, trabajo con instrucciones. No es pereza, es prevención del agotamiento cognitivo.
La trampa de la comunicación
Las habilidades verbales no son solo comprensión de textos. Es la capacidad de defender tu posición. En una corporación, las decisiones se toman en reuniones. Si no puedes explicar en 30 segundos por qué no se puede lanzar una versión, tu análisis técnico no vale nada.
Solución: practica el elevator pitch para errores. "¿Por qué este defecto es crítico? Da una razón en 10 segundos". Si no puedes, la formulación no es la correcta.
La trampa de la infraestructura
El miedo a la arquitectura corporativa compleja mata la iniciativa. Un tester ve cien microservicios, un pipeline CI/CD de treinta etapas, frameworks desconocidos y se queda paralizado.
Solución: el método del "elefante a pedazos". Toma solo un microservicio. Comprende su lógica. Restaura las pruebas para él. Hazlo con calidad. Luego pasa al siguiente.
[CONSEJO] Recuerda: el arquitecto de soluciones de prueba no es quien sabe todo. Es quien entiende que no necesita saberlo todo. Basta con ver el sistema como un mapa de nodos y entender dónde exactamente se necesita realizar las pruebas ahora. [FIN]
De tester a arquitecto: un plan paso a paso
Etapa 1. Pruebas manuales (0–1 año)
En esta etapa, tus habilidades cognitivas se perfeccionan con tareas concretas. Busca patrones en los errores. Aprende a formularlos para que el desarrollador entienda inmediatamente qué hacer. Trabaja con números: evalúa el porcentaje de cobertura de pruebas.
Etapa 2. Automatización (1–3 años)
Los tests numéricos se vuelven especialmente relevantes. Trabajas con métricas: rendimiento, cobertura, estabilidad de las pruebas. Las habilidades verbales pasan a un nuevo nivel: no escribes informes de errores, sino documentación técnica para el equipo.
Etapa 3. Arquitectura de soluciones de prueba (3–5 años)
Las habilidades cognitivas alcanzan el nivel de extrapolación. No solo sabes cómo funciona el sistema, sino que predices dónde se romperá el próximo año. No gestionas pruebas, gestionas procesos.
Etapa 4. Gestión de calidad (5+ años)
En este nivel, las pruebas son una abstracción para ti. Trabajas con personas, procesos y estrategia. Las habilidades verbales se vuelven clave: explicas al negocio por qué es necesario invertir en pruebas y te pones de acuerdo con los equipos sobre los estándares.
[FÓRMULA] Velocidad de crecimiento profesional = calidad de superación de tests cognitivos × disposición para aprender nueva comunicación × capacidad de ver el negocio en números. [FIN]
Cada etapa requiere un cambio en el modo de pensar. Los tests cognitivos, verbales y numéricos no son un obstáculo antes de la entrada. Son el mapa de tu crecimiento. Mientras aprendes a resolver estos problemas, aprendes a pensar como un arquitecto, no como un ejecutor.
Y cuando la próxima vez veas un test con manzanas y conclusiones lógicas, debes saber: detrás de él no hay un deseo de ponerte a prueba, sino un intento de entender si estás listo para el trabajo real en una gran empresa, donde no hay respuestas preparadas, sino solo preguntas que hay que resolver antes de que termine la semana.
