Qué exigir en la entrega
Qué es una prueba automatizada y por qué te importa aunque no seas técnico
Una prueba automatizada es un programa corto que revisa que otro programa siga haciendo lo que debe. Se escribe una vez y se ejecuta sola cada vez que alguien cambia algo. Te importa porque es lo único que evita que arreglar una cosa rompa otra en silencio, que es la forma más común en que un sistema se cae a pedazos.
Publicado el · 7 minutos · César Barreto
Es de las pocas cosas técnicas que conviene que un dueño entienda, porque separa a un proveedor de otro más que cualquier certificación. No hace falta saber programar: basta con entender qué revisa, qué no revisa y cómo comprobar que de verdad existen.
¿Qué es una prueba automatizada?
Es un programa corto que ejecuta una parte del sistema con datos conocidos y verifica que el resultado sea el esperado. Por ejemplo: mete una venta de tres piezas de un producto que tenía diez, y comprueba que queden siete. Si un día quedan ocho, la prueba falla y avisa antes de que nadie lo note en el almacén. Se escribe una sola vez y se ejecuta miles de veces, sola, cada vez que alguien toca el código.
La diferencia con probar a mano es que probar a mano se hace una vez, con lo que uno recuerda revisar, y el día que hay prisa no se hace. Una suite de pruebas revisa todo, siempre, incluso lo que nadie recuerda que existe.
¿Por qué le importa esto a un dueño de negocio?
Por una razón muy concreta: el modo en que los sistemas se descomponen. Casi nunca es un desastre de un día. Es un cambio pequeño en la pantalla de cobranza que, sin que nadie se dé cuenta, deja de descontar bien el inventario. Pasan dos semanas antes de que alguien lo note, y para entonces hay cien movimientos mal. Las pruebas automatizadas existen para que ese cambio no llegue a producción.
- Convierten un cambio arriesgado en uno rutinario. Sin pruebas, cualquier ajuste da miedo, y un sistema que da miedo tocar deja de mejorar.
- Permiten que otro equipo continúe el trabajo. Las pruebas describen, en ejecutable, cómo debe comportarse el negocio: es la mejor documentación que existe.
- Acortan la discusión sobre si algo falló o siempre fue así. Si hay una prueba que lo cubre, la respuesta está escrita.
- Son la única forma de crecer sin romper. Cuando el sistema tiene veinte módulos, nadie puede volver a probar todo a mano en cada entrega.
¿Qué tipos de pruebas existen?
Cuatro, y cada una revisa una capa distinta. No compiten: se acumulan. Estas son, con el ejemplo real del sistema de Distribuidora del Golfo, donde suman 1,148 pruebas en total.
| Tipo | Qué revisa | Ejemplo en un ERP | En el ERP de Distribuidora del Golfo |
|---|---|---|---|
| Unitaria | Una pieza sola, sin nada alrededor | Que el cálculo de la comisión de un chofer dé el número correcto | 365 pruebas en 23 archivos |
| De integración | Que dos o más piezas trabajen juntas | Que al confirmar un pedido se descuente el inventario y se genere el movimiento de caja | 249 pruebas en 29 archivos |
| De base de datos | Que las reglas y los permisos vivan en los datos, no solo en la pantalla | Que un chofer no pueda leer los saldos de clientes que no le tocan, ni siquiera saltándose la aplicación | 487 pruebas en 40 archivos |
| De navegador | El recorrido completo, como lo haría una persona | Entrar, levantar un pedido sin señal, recuperar la conexión y ver que el pedido llegó | 47 pruebas en 9 suites |
Las de base de datos son las que más sorprenden a quien no es técnico, y son las que más protegen. Un permiso que solo vive en la pantalla se salta con cualquier herramienta; un permiso escrito en la base se cumple siempre, y una prueba comprueba que se cumple. Es la diferencia entre esconder un botón y cerrar una puerta.
El número por sí solo no dice nada. Mil pruebas que revisan lo fácil valen menos que doscientas que revisan el cobro, el inventario y los permisos. Lo que importa es qué cubren, no cuántas son.
¿Qué no garantiza una prueba automatizada?
Conviene decirlo con claridad, porque se vende mal. No garantiza que el sistema no tenga errores: garantiza que los errores ya conocidos no vuelvan, y que lo que se probó siga funcionando. Tampoco garantiza que el sistema sirva para el negocio: se puede tener un sistema perfectamente probado que resuelva el proceso equivocado. Y no sustituye a que una persona lo use antes de entregarlo.
¿Cómo compruebo que un proveedor de verdad las tiene?
Con tres peticiones sencillas, que no requieren saber nada técnico y que se responden en minutos si las pruebas existen.
- 01
Pide verlas correr en pantalla
No un informe en PDF: la ejecución en vivo, con el conteo al final. Toma menos de un minuto y es imposible de improvisar.
- 02
Pide que rompan algo a propósito
Que cambien una regla del negocio en el código, delante de ti, y vuelvan a correr. Si las pruebas no fallan, no estaban cubriendo eso.
- 03
Pregunta qué pasa si una prueba falla al publicar
La respuesta correcta es que la publicación se detiene. Si la respuesta es que se revisa después, las pruebas son decorativas.
¿Cuánto cuesta tener pruebas?
Tiempo de desarrollo, y no poco: escribir una prueba puede tomar tanto como escribir la función que revisa. Ese costo está dentro del precio del proyecto en cualquier equipo que trabaje así, y se paga solo la tercera o cuarta vez que hay que cambiar algo sin miedo. Un sistema sin pruebas es más barato de construir y más caro de mantener, y la diferencia empieza a notarse justo cuando el negocio quiere crecer.
Por eso conviene preguntarlo antes de firmar y no al final. Junto con el manual técnico, el respaldo probado y la propiedad del código, es una de las cuatro cosas que hacen que un sistema siga siendo tuyo el día que cambies de proveedor.
Cuándo no vale la pena exigir una batería grande de pruebas
- En un prototipo hecho para decidir si vale la pena construir algo. Ahí lo que se prueba es la idea, no el código, y las pruebas encarecen algo que se va a tirar.
- En una landing o un sitio informativo sin operación detrás. Con revisar que las páginas cargan y que el formulario entrega, alcanza.
- En una automatización pequeña que una persona revisa todos los días. Si el error se ve el mismo día y no cuesta dinero, la prueba puede esperar.
- Cuando el proceso todavía cambia cada semana. Las pruebas fijan comportamiento: escribirlas sobre algo que va a cambiar es trabajo que se tira dos veces.
Quién escribe
César Barreto, fundador de riel. Ingeniería industrial y desarrollo: mira la operación antes que el código.
Construyó el ERP de Distribuidora del Golfo, 19 módulos entregados en 6 fases con 1,148 pruebas automatizadas.
Conocer a riel →Preguntas frecuentes
¿Qué es una prueba automatizada, en una frase?
Un programa corto que ejecuta una parte del sistema con datos conocidos y verifica que el resultado sea el esperado. Se escribe una vez y se ejecuta sola en cada cambio, para avisar si algo dejó de funcionar como debía.
¿Cuántas pruebas debería tener mi sistema?
No hay un número correcto, y el número sin contexto engaña. Lo que conviene revisar es qué cubren: el cobro, el inventario, los permisos y los cálculos que mueven dinero. Doscientas pruebas sobre eso valen más que mil sobre lo fácil.
¿Las pruebas garantizan que el sistema no falle?
No. Garantizan que lo que ya se probó siga funcionando y que un error conocido no regrese. No cubren lo que nadie previó, ni sirven de nada si el sistema resuelve el proceso equivocado. Cualquiera que prometa cero errores está vendiendo otra cosa.
¿Puedo pedir pruebas si mi sistema ya está hecho?
Sí, y suele ser la primera tarea de un rescate. Se empieza por las partes que mueven dinero, se escriben pruebas que describan el comportamiento actual y a partir de ahí se puede tocar el código sin romperlo a ciegas.