Interpretando los resultados de evaluaciones QA: Leyendo datos de pruebas como un ingeniero

La trampa de las métricas

Cuando ejecutas una evaluación QA, obtienes datos. Líneas de código escritas. Casos de prueba por hora. Número de aserciones. Porcentaje de cobertura. Tasa de falsos positivos. Tu instinto es optimizar estas métricas.

Eso es una trampa.

Las métricas son resultados, no señales. Un candidato que escribe pruebas de alta cobertura en 90 minutos puede ser bueno en pruebas de velocidad. Un candidato que escribe 3 pruebas sólidas en 2,5 horas puede ser mejor construyendo código mantenible. Las métricas brutas no te dicen cuál es cuál.

Necesitas leer el patrón detrás de las métricas.

Qué medir en el diseño de casos de prueba

Si estás calificando un envío de caso de prueba escrito, no solo cuentes los casos. Califica sobre estos:

1. Profundidad de cobertura (no amplitud)

Un candidato que escribe 5 casos de prueba, cada uno con 3-4 pasos bien razonados y aserciones claras, es más fuerte que uno que escribe 20 casos vagos.

Busca:

• ¿Prueban el camino feliz, caso de error, caso límite y transiciones de estado?
• ¿Se enfocan en el comportamiento o en detalles de implementación?
• ¿Reconocen las restricciones ("asumiendo que la BD tiene 100k usuarios, probamos con 50k")?

Señal de alerta: "Probar que el botón existe". Eso no es un caso de prueba. Es un paso en una prueba.

Buena señal: "Probar que la importación masiva valida el formato del archivo antes de procesar. Proporcionar un CSV con encabezados inválidos y verificar que el mensaje de error guía al usuario para corregirlo".

2. Criterio en la priorización

¿Etiquetan las pruebas como críticas, altas, bajas? ¿Distinguen entre "cosas que podrían romperse" y "cosas que queremos verificar"?

Un candidato que escribe 12 casos, marca 3-4 como críticos y explica por qué está mostrando criterio. Un candidato con 12 casos de igual prioridad está sobrestimando la importancia o no está pensando en ello.

Qué buscar: "Esta prueba es de alta prioridad porque toca el procesamiento de pagos". o "Esta es de baja prioridad porque es una validación cosmética".

3. Conciencia del entorno

¿Mencionan la configuración? ¿Preguntan sobre datos? ¿Consideran requisitos previos?

Débil: "Probar la función de exportación".

Fuerte: "Asumiendo que el usuario tiene 500 registros para exportar, verifica que el CSV contenga todas las filas con mapeo de campo correcto. Nota: Necesitaremos datos similares a producción o un script de inicio para esto".

Qué medir en código de automatización

Cuando recibas código, no solo mires si pasa o falla. Ejecútalo, léelo y califica sobre:

1. Robustez de selectores

¿Qué tan bien se mantienen sus selectores cuando cambia la interfaz?

Selector frágil:

driver.findElement(By.cssSelector("body > div > div > div > button")).click();

Esto se rompe con cualquier cambio de diseño. Están recién empezando en automatización o cortando esquinas.

Selector robusto:

driver.findElement(By.cssSelector("[aria-label='Import CSV']")).click();

Esto prueba accesibilidad y se mantiene estable durante refactorizaciones.

Puntuación: ¿Pueden sus selectores sobrevivir cambios menores de interfaz? Si no, es -2 en una escala de 10.

2. Estrategia de espera

¿Usan esperas explícitas, esperas implícitas, o (lo peor) ninguna?

Sin esperas:

driver.findElement(By.id("submit")).click();
driver.findElement(By.id("success-message")).getText(); // Condición de carrera

Esperas implícitas (OK, no excelente):

driver.manage().setTimeouts({implicit: 10000});

Esperas explícitas (lo mejor):

WebDriverWait(driver, 10).until(EC.presence_of_element_located((By.id, "success-message")));

Si usan esperas explícitas, entienden asincronía. Si no, tendrán pruebas inestables en producción.

Puntuación: Sin esperas = -3. Solo implícitas = -1. Explícitas = 0.

3. Calidad de aserciones

¿Afirman comportamiento o solo DOM?

Aserciones débiles:

assert(screen.getByText("Success"));

Esto prueba que apareció un mensaje, no que la operación fue exitosa.

Aserciones fuertes:

expect(await screen.findByText("5 rows imported successfully")).toBeInTheDocument();
expect(await screen.findByDisplayValue("import_status = completed")).toBeInTheDocument();

Esto prueba tanto el mensaje como el estado subyacente.

Puntuación: Aserciones que prueban comportamiento real = +2. Aserciones que solo prueban UI = 0. Aserciones faltantes = -2.

4. Estructura del código y mantenibilidad

¿Es el código DRY? ¿Usan objetos de página, fixtures o funciones auxiliares?

Sin estructura:

test("import csv", async () => {
  await page.goto(...);
  await page.fill('#email', '[email protected]');
  await page.fill('#password', 'password');
  await page.click('#login');
  // ... 40 líneas más para una sola prueba
});

Estructurado:

const page = new ImportPage();
test("import csv with invalid headers", async () => {
  await page.login();
  await page.uploadCsv('invalid.csv');
  await page.expectError('Invalid CSV format');
});

El segundo es mucho más mantenible. Si el login cambia, arreglas un lugar, no tres.

Puntuación: Duplicación significativa o números mágicos = -2. Estructura razonable = 0. DRY fuerte con ayudantes = +1.

5. Cobertura vs. sobre-aserción

¿Probaron el alcance correcto o lo probaron todo?

Una prueba que afirma 15 cosas es frágil. Falla si algo cambia, haciendo difícil depurar. Una prueba que afirma 2-3 comportamientos clave es enfocada.

Cuenta aserciones por prueba. Si el promedio es >4, están sobre-asertando. Si <1, no están probando lo suficiente.

Qué medir en entrevistas en vivo

Esto es más difícil de cuantificar, pero escucha esto:

1. Claridad del pensamiento

Cuando preguntas "Tu suite de regresión toma 3 horas, redúcela a 1 hora", ¿saltan a soluciones o hacen preguntas primero?

Pobre: "Ejecutar menos pruebas".

Bueno: "¿Con qué frecuencia desplegamos? ¿Cuál es la prueba más lenta? ¿Cuáles son nuestras características más críticas?" Están estrechando el problema antes de proponer soluciones.

Puntuación: ¿Hacen 2-3 preguntas aclaratorias antes de proponer soluciones? Si es sí, +2 en criterio.

2. Articulación de compensaciones

¿Pueden explicar qué se sacrifica?

Pobre: "Solo saltaremos las pruebas más lentas".

Bueno: "Si nos enfocamos en los viajes críticos del usuario—iniciar sesión, comprar, exportar—reducimos el tiempo de 3 horas a 45 minutos. Sacrificamos cobertura en casos límite y herramientas internas. El riesgo es perder bugs raros. Aceptable si tenemos monitoreo y un proceso de hotfix rápido".

El segundo muestra que entienden el costo de cada decisión.

Puntuación: ¿Pueden articular qué podría romperse por su compensación? +3 en criterio.

3. Evidencia de experiencia

¿Hacen referencia a situaciones reales o conocimiento teórico?

Teórico: "En un mundo ideal, tendríamos cobertura de pruebas integral".

De experiencia: "En mi última empresa, teníamos 50 pruebas de UI que tomaban 4 horas. Las redujimos a 15 críticas—20 minutos—e incidentes no aumentaron porque nuestro entorno de staging era bueno. Así que sugeriría invertir en eso aquí".

La experiencia real es más valiosa que la teoría. No porque la teoría sea mala, sino porque muestra qué funcionó en la práctica.

Puntuación: ¿Hacen referencia a una situación real de su trasfondo? +2.

Qué ignorar

• Líneas de código escritas: Más código ≠ mejor ingeniero. Código conciso que funciona es más fuerte.
• Velocidad de ejecución: Una prueba lenta que es confiable es mejor que una prueba rápida que es inestable.
• Patrones sofisticados: Si usan un patrón de diseño sofisticado pero no es necesario, eso es sobre-ingeniería, no habilidad.
• Preferencia de lenguaje: No importa si usan Python o JavaScript para utilidades de prueba. Lo que importa es legibilidad.

Juntándolo todo: Un marco de puntuación

Crea una rúbrica simple:

Puntúa cada candidato en cada categoría. Un 3 en todas las categorías es una contratación fuerte. Una mezcla de 2s y 3s está bien (todos tenemos debilidades). Un 1 en cualquier lugar es una señal de alerta.

Suma tus puntuaciones. No obsesiones con el número. Úsalo para comparar candidatos consistentemente.

El patrón que buscas

El mejor resultado de evaluación QA se ve así:

• Diseño de caso de prueba fuerte (pensamiento claro)
• Calidad de código decente (experiencia práctica)
• Buen criterio en la entrevista (capacidad de decisión)
• Una cosa en la que son excepcionales (quizás selectores, quizás conocimiento de framework, quizás pensamiento de procesos)

Esa persona aprenderá, crecerá y mantendrá suites de pruebas durante años. Ese es la contratación.