Qué automatizar y qué no

La pregunta que casi nadie hace

Cuando un equipo empieza a automatizar, la pregunta es "¿cómo automatizo esto?". La pregunta correcta es "¿esto se debe automatizar?". La diferencia entre las dos es la diferencia entre una suite que ayuda y una que estorba.

La pirámide, explicada como economía

| Nivel | Velocidad | Fragilidad | Confianza | Cuántos | |---|---|---|---|---| | Unitario | ms | Muy baja | Baja (una pieza) | Muchos | | Integración | segundos | Media | Media (piezas juntas) | Bastantes | | E2E | minutos | Alta | Alta (todo el flujo) | Pocos y críticos |

La pirámide no es una convención estética: es economía. Cada nivel tiene una relación entre la confianza que da y lo que cuesta. El e2e da la confianza más alta —prueba lo que el usuario vive— pero es lento, se rompe con cualquier cambio de UI y su diagnóstico es caro. Por eso se usa poco y bien.

El costo real de un test

Aquí está el error de cálculo que hunde suites. El costo de un test no es el tiempo de escribirlo:

Costo total = escribirlo
            + mantenerlo cada vez que la app cambia
            + el tiempo que suma a cada corrida (× miles de corridas)
            + diagnosticarlo cada vez que falla

Escribirlo es el pago inicial. Mantenerlo es la hipoteca. Un test vive años y se rompe con cada refactor. Por eso "automatizar todo" no es ambición, es un mal negocio: cada test tiene que ganarse su lugar.

El criterio: riesgo × costo

Aplica lo mismo del plan de pruebas: automatiza primero donde el riesgo es alto y el test es estable.

• Automatiza sí o sí: flujos que mueven dinero o datos críticos, regresión de lo que ya se rompió antes, y cualquier verificación repetitiva y aburrida (las máquinas no se cansan ni se saltan pasos).
• Piénsalo dos veces: pantallas que cambian cada sprint (el test se romperá más que la app), y casos raros de bajísimo impacto.
• No automatices: lo que requiere juicio humano.

Lo que no se automatiza (y está bien)

La automatización verifica lo que puedes expresar como una assertion. No puede decirte:

• Si una pantalla se entiende o confunde.
• Si el copy suena raro o el flujo se siente incómodo.
• Si "algo no cuadra" — esa sensación que te hace mirar donde nadie miró.

Eso es testing exploratorio, y es donde un QA aporta lo que ninguna máquina. Automatizar lo repetitivo existe justamente para liberarte tiempo y que puedas hacer eso.

Comprueba el criterio en el quiz y aplícalo a una app real en el reto.