Saltar al contenido principal
causProsolutions

Lección 1 de 7 · 10 min

Qué automatizar y qué no

Al terminar sabrás

10 min
  • Ubicar cada prueba en el nivel correcto de la pirámide y saber por qué
  • Calcular el costo real de un test automatizado, no solo el de escribirlo
  • Decidir con argumentos qué NO se automatiza

Construyes: El criterio de automatización de una app real: qué va a e2e, qué a integración y qué se deja manual.

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

NivelVelocidadFragilidadConfianzaCuántos
UnitariomsMuy bajaBaja (una pieza)Muchos
IntegraciónsegundosMediaMedia (piezas juntas)Bastantes
E2EminutosAltaAlta (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.

Compruébalo

0/3

Responde sin mirar atrás. Verás la explicación al instante.

  1. 1. ¿Por qué la pirámide pone pocos tests e2e arriba y muchos unitarios abajo?

  2. 2. ¿Cuál es el costo real de un test automatizado?

  3. 3. ¿Qué caso es MEJOR dejar como prueba manual/exploratoria?

Reto: el criterio de una app real

Toma una app que conozcas y lista 8 comportamientos. Para cada uno decide: ¿unitario, integración, e2e o manual? Y justifica en una línea.

Recursos de esta lección