Pruebas de automatizaciones: saber que el proceso sigue haciendo lo correcto

Probar una automatización es verificar que hace lo correcto, no solo que termina sin error. La distinción importa porque la falla más costosa no es la que se detiene: es la que sigue ejecutándose con un resultado equivocado y no avisa a nadie hasta que aparece en una auditoría.

A continuación: qué se prueba antes de publicar, cómo se vigila después, qué fallas son silenciosas y qué debe existir antes de pasar a producción.

La conversación sobre calidad en automatización suele quedarse en si el proceso corre. Es la pregunta fácil y la menos informativa: un proceso puede correr perfectamente todos los días y producir cifras equivocadas durante meses.

Distinguir "terminó" de "hizo lo correcto" es lo que separa una automatización supervisada de una que simplemente nadie está mirando.

Qué se prueba antes de publicar

El caso normal, que es el que todo el mundo prueba. Sirve para confirmar que la lógica principal funciona y no dice casi nada sobre la robustez.

Los bordes: el registro vacío, el importe en cero, el nombre con caracteres raros, la fecha del último día del mes. En operaciones de Colombia y México conviene incluir explícitamente los acentos y la eñe, que siguen rompiendo integraciones con sistemas que no declararon su codificación.

El volumen: qué pasa cuando llegan diez veces más casos de lo previsto. Muchas automatizaciones correctas fallan por tiempo de espera el primer día de cierre.

La interrupción: qué queda si el proceso se corta a la mitad. Si deja un caso parcialmente procesado sin marca, la siguiente ejecución lo duplicará.

Las fallas silenciosas

Son las que justifican todo el esfuerzo de vigilancia. Ocurren cuando la automatización sigue funcionando y el resultado deja de ser correcto: la regla de negocio cambió y nadie avisó, el reporte de origen añadió una columna y los datos se desplazaron, un catálogo se actualizó y las categorías ya no corresponden.

Ninguna de las tres genera un error. Todas generan cifras equivocadas con apariencia normal, y se descubren tarde: en un cierre, en una auditoría, o cuando un cliente reclama.

La defensa no es probar más antes de publicar, porque estas fallas aparecen después. Es verificar el resultado de forma continua.

Cómo se vigila después

Con comprobaciones sobre la salida, no sobre la ejecución. Las tres más útiles son simples: el conteo —¿procesó un número de casos parecido al habitual?—, la suma —¿los importes totales están en el rango esperado?— y la tasa de excepción —¿empezó a fallar más de lo normal?—.

Cualquiera de las tres desviándose es señal de mirar. Ninguna requiere herramientas especiales, y juntas detectan la mayoría de las fallas silenciosas antes de que lleguen a un cierre.

Qué debe existir antes de pasar a producción

Cuatro cosas, y son las mismas que definen un estándar de construcción: un registro de qué hizo y cuándo, un lugar donde queden los casos que no pudo resolver, una alerta a una persona nombrada cuando algo se sale del rango, y una forma de reprocesar sin duplicar.

La cuarta es la que más se olvida y la que más daño causa. Si reprocesar un lote implica ejecutar de nuevo sin control de duplicados, el remedio del incidente crea el siguiente.

Ese estándar es una de las decisiones que concentra un centro de excelencia, y es lo que separa un portafolio mantenible de un conjunto de piezas artesanales.

Probar lo que cambió, no todo

La objeción práctica a probar en serio es el tiempo, y tiene respuesta. No hace falta repetir la batería completa ante cada ajuste: basta identificar qué depende de lo que se tocó.

Un cambio en una regla de negocio exige revalidar los casos que esa regla cubre. Un cambio en el sistema de origen exige revisar la lectura de datos y nada más. Mantener escrito qué depende de qué convierte una prueba de horas en una de minutos, y es la razón por la que el registro de dependencias vale el esfuerzo de mantenerlo.

Dónde encaja el esfuerzo

Probar cuesta, y conviene dimensionarlo por criticidad y no por costumbre. Una automatización que mueve dinero o alimenta una declaración merece verificación continua; una que ordena una bandeja interna, bastante menos.

Esa clasificación sale del mismo levantamiento que prioriza qué automatizar: un assessment de automatización de procesos evalúa la estabilidad y la criticidad de cada candidato, y de ahí se deduce cuánta vigilancia justifica cada pieza del portafolio de automatización.

Preguntas frecuentes

¿Qué se prueba en una automatización además del caso normal?

Los bordes —registro vacío, importe en cero, acentos y eñe, fin de mes—, el comportamiento con diez veces el volumen previsto, y qué queda si el proceso se interrumpe a la mitad. Ese último caso es el que produce duplicados en la siguiente ejecución.

¿Qué es una falla silenciosa?

Cuando la automatización sigue ejecutándose sin error y el resultado deja de ser correcto: cambió una regla de negocio, el reporte de origen añadió una columna, o un catálogo se actualizó. No genera alerta y se descubre en un cierre o una auditoría.

¿Cómo se detectan las fallas silenciosas?

Verificando la salida y no la ejecución: el conteo de casos procesados, la suma de importes y la tasa de excepción, cada uno contra su rango habitual. Las tres son simples y detectan la mayoría antes de que lleguen a un cierre.

¿Qué debe existir antes de publicar una automatización?

Un registro de qué hizo y cuándo, una cola para los casos no resueltos, una alerta a una persona nombrada cuando algo sale del rango, y una forma de reprocesar sin duplicar. La última es la que más se olvida.