Interpretar resultados de evaluación QA: leer test data como engineer

La trampa de métricas

Métricas son outputs, no señales. Lee el pattern atrás.

Qué medir en test case design

1. Profundidad de cobertura (no breadth)

5 cases con 3-4 pasos bien razonados es mejor que 20 vagos.

Red flag: "Test que el botón existe." Buena: "Test que bulk import valida formato antes de procesar. CSV con headers inválidos."

2. Juicio de priorización

Críticos, high, low? Pueden distinguir "podría romperse" vs "queremos verificar"?

3. Awareness ambiental

Mencionan setup? Preguntan por data?

Qué medir en código de automation

1. Robustez de selectores

Brittle: By.cssSelector("body > div > div > button") Robust: By.cssSelector("[aria-label='Import CSV']")

2. Wait strategy

• Sin waits: -3
• Implicit only: -1
• Explicit waits: 0

3. Calidad de assertions

Weak: assert(getByText("Success")) — solo UI. Strong: assert mensaje + estado underlying.

4. Estructura y maintainability

Page objects, fixtures, helpers. DRY = +1.

5. Cobertura vs over-assertion

Promedio assertions por test: >4 = over-assert. <1 = no testing enough.

Qué medir en live interviews

1. Claridad de pensamiento

"3 horas a 1 hora." Preguntan clarifying primero?

2. Articulación de trade-offs

"Foco en critical journeys, sacrificamos edge cases. Risk: missed bugs. Acceptable con monitoring."

3. Evidencia de experiencia

"En última empresa, 50 UI tests a 4 horas. Cortamos a 15 críticos. Incidents no aumentaron."

Qué ignorar

• Líneas de código
• Velocidad de ejecución
• Patrones fancy
• Preferencia de lenguaje

Framework de scoring

3 across categorías = strong hire.

El pattern que buscas

• Test case design strong
• Code quality decent
• Juicio bueno en interview
• Algo excepcional

Esa persona aprenderá, crecerá, y mantendrá test suites por años.