El Error de Redondeo de $80,000
El año pasado, un cliente mío — una empresa fintech que procesa facturación recurrente por suscripción — lanzó una actualización "menor" en su lógica de precios un viernes por la tarde. Un desarrollador cambió la forma en que el sistema redondeaba fracciones de centavo durante la conversión de moneda. El cambio pasó la revisión de código. Pasó el control de calidad manual — alguien recorrió el flujo de compra una vez, vio un precio normal y lo aprobó. Se publicó.
Para el lunes por la mañana, la empresa había cobrado de más a unos 1.400 clientes, en montos que iban desde algunos centavos hasta varios dólares cada uno, y había cobrado de menos a varios cientos más por montos mayores, debido a un error de signo en un caso límite que nadie había probado manualmente: una baja de plan a mitad de ciclo combinada con un reembolso prorrateado. Los tickets de soporte se acumularon. El equipo de finanzas pasó dos semanas conciliando el libro contable. Dos clientes con discrepancias visibles en su resumen bancario escalaron el reclamo hasta una disputa de contracargo. El costo total — reembolsos, horas de soporte, conciliación y una llamada muy incómoda con el procesador de pagos — rondó los $80.000.
Una sola prueba de integración, que cubriera el camino de baja de plan más reembolso con un puñado de validaciones, habría detectado ese error de signo en unos cuatro segundos, cada vez que se ejecutara, durante toda la vida del sistema.
Abro con esta historia porque no es inusual. He visto versiones de ella — distintas industrias, distintos errores, la misma causa raíz — más veces de las que puedo contar. Después del incidente, el dueño del negocio siempre hace la misma pregunta: "¿No era para esto que teníamos control de calidad?" La respuesta honesta es que el control de calidad manual detecta lo que a una persona se le ocurre probar. Las pruebas automatizadas detectan lo que a nadie se le ocurre probar, y lo hacen en cada despliegue, para siempre, por una fracción del costo del incidente que evitan.
La Cuenta que Casi Ningún Fundador Hace
Existe una afirmación muy citada — atribuida frecuentemente al Systems Sciences Institute de IBM — que dice que corregir un error en producción cuesta aproximadamente 100 veces más que corregirlo durante la fase de requerimientos. Esa cifra exacta ha sido cuestionada con los años; el estudio original es difícil de rastrear, y el número se ha repetido tanto que hoy es más folclore que dato verificable. Yo no lo trato como una verdad absoluta, y usted tampoco debería hacerlo.
Pero si se deja de lado el multiplicador exacto, el patrón de fondo se sostiene en cada proyecto en el que he trabajado: un defecto detectado por una prueba unitaria le cuesta a la empresa unos pocos minutos de trabajo de un desarrollador. El mismo defecto detectado durante una prueba manual cuesta una o dos horas de control de calidad, más un ciclo de corrección y reprueba. Detectado después del lanzamiento, cuesta respuesta a incidentes, atención al cliente, un parche apresurado hecho bajo presión y, según el error, daño reputacional o exposición regulatoria que ninguna cantidad de horas de ingeniería puede revertir después del hecho. La dirección de esa curva no está en discusión, aunque el multiplicador exacto sí lo esté.
El costo de un atajo en las pruebas no desaparece cuando se lo omite. Se traslada río abajo, acumula intereses y termina recayendo en una parte del negocio que no tiene forma de negociarlo: sus clientes, su equipo de soporte o su área de finanzas durante el cierre de mes.
Por Qué Dueños de Negocio Inteligentes Igual Omiten las Pruebas
Rara vez me encuentro con un fundador que piense que probar el software sea una mala idea en abstracto. Con quien me encuentro es con fundadores que lo viven como un impuesto sobre la velocidad de entrega, pagado por adelantado, a cambio de un beneficio que permanece invisible hasta el día en que deja de serlo.
Algunos patrones se repiten con consistencia:
- Las pruebas no producen ninguna funcionalidad visible. Un botón nuevo se luce en la demo del sprint. Una batería de pruebas no muestra nada en una demo — hasta que, en silencio, evita una caída del sistema seis meses después.
- El equipo es chico y cada hora es valiosa. Con tres desarrolladores, dedicar dos de esas horas a escribir pruebas en lugar de funcionalidades parece la opción más cara, aun cuando es la más barata en un horizonte de doce meses.
- Todavía nadie se quemó. En mi experiencia, la disciplina de pruebas se adopta de forma reactiva mucho más seguido que de forma preventiva. La mayoría de las empresas en las que introduzco pruebas automatizadas ya tuvieron su incidente de $80.000. Pocas la adoptan solo por el riesgo proyectado.
- "Después agregamos las pruebas" se vuelve permanente en silencio. Es la misma dinámica que describo en mi artículo sobre por qué el desarrollo de software barato termina costando más — el trabajo de calidad postergado casi nunca se retoma, porque la presión de plazos que causó la postergación simplemente es reemplazada por el próximo plazo.
Ninguna de estas razones es irracional. Son, simplemente, miopes de una manera específica, predecible y cara.
La Pirámide de Pruebas, Sin la Jerga Técnica
Los ingenieros hablan de la "pirámide de pruebas" como si se explicara sola. Para un dueño de negocio, esta es la traducción:
- Pruebas unitarias (la base — ahí debería vivir la mayoría de sus pruebas). Verifican una pieza pequeña de lógica de forma aislada: un cálculo de precio, una regla de descuento, una conversión de fecha. Se ejecutan en milisegundos, son las más baratas de escribir y mantener, y detectan la mayor cantidad de errores por cada dólar invertido.
- Pruebas de integración (la capa intermedia). Verifican que las piezas funcionen correctamente en conjunto: su API hablando con su base de datos, su servicio de facturación hablando con su procesador de pagos. El error de suscripción que describí antes vivía exactamente ahí.
- Pruebas de extremo a extremo (la cima, y la capa más pequeña). Simulan a un usuario real navegando su aplicación real. Son las más realistas, las más lentas de ejecutar y las más costosas de mantener — por eso deberían cubrir únicamente su puñado de recorridos de usuario más críticos, no todo el sistema.
El error que veo con más frecuencia es que las empresas invierten esta pirámide por completo: se saltan las pruebas unitarias y de integración y confían en una capa delgada de pruebas manuales, o sobre-invierten en pruebas de extremo a extremo frágiles que se rompen cada vez que cambia la interfaz y terminan deshabilitadas al cabo de un año, por pura frustración.
Cómo Se Ve "Suficiente" Cobertura de Pruebas para una Pyme
Nunca le recomiendo a un cliente una cobertura de código del 100%. Es cara, retrasa las entregas sin una reducción proporcional del riesgo, y con frecuencia implica probar código trivial solo para que un porcentaje de cobertura se vea bien en un panel de métricas. En cambio, recomiendo priorizar según la consecuencia:
- El movimiento de dinero primero. Todo lo que toque facturación, nómina, cobranza o procesamiento de pagos recibe cobertura de pruebas automatizadas antes que cualquier otra cosa. En proyectos fintech y de B2B SaaS, esto no es negociable.
- Todo lo que implique exposición legal o de cumplimiento normativo. El manejo de datos, los permisos y la lógica de control de acceso — el tipo de cosa que se convierte en una notificación de brecha de seguridad si falla en silencio.
- El recorrido central de su usuario. Los tres a cinco flujos que, si se rompen, impiden que sus clientes hagan aquello por lo que le pagan.
- El código que cambia con frecuencia. El código estable y poco tocado es menor prioridad que el módulo que su equipo modifica cada sprint, porque cada cambio es una nueva oportunidad de introducir una regresión.
- Todo lo que ya se rompió alguna vez. Un error que se publicó una vez volverá a publicarse de otra forma, a menos que exista una prueba que lo impida. Escribo una prueba de regresión por cada incidente de producción que me llaman a resolver, sin excepciones.
Para una aplicación típica de pyme, esto suele significar una base sólida de pruebas unitarias que cubran la lógica de negocio, pruebas de integración en los tres o cuatro puntos de mayor riesgo del sistema, y un número reducido de pruebas de extremo a extremo que cubran el registro, la compra y la transacción central de su modelo de ingresos. Ese es un alcance realista y financiable, no una iniciativa de ingeniería sin límite definido.
Adelántese al Error que Todavía No Ocurrió
La verdad incómoda es que la mayoría de las empresas no decide invertir en pruebas automatizadas por decisión propia. Las obliga un incidente lo bastante caro como para cambiar la conversación. Prefiero ayudar a un cliente a tomar esa decisión en sus propios términos, un martes por la tarde en una reunión de planificación, antes que dejar que se la imponga una caída de producción un viernes a la noche.
Esto se conecta con un patrón más amplio que observo en proyectos de software fallidos o en dificultades — la misma subestimación de la disciplina de ingeniería "invisible" que trato en mi artículo sobre errores comunes que cometen los fundadores en proyectos de software. Las pruebas rara vez son la razón por la que un proyecto luce impresionante en una demo. Son, de manera consistente, la razón por la que un proyecto sigue funcionando, con su lógica central intacta, tres años después.
Si no está seguro de si su cobertura de pruebas actual está a la altura del riesgo real de su negocio, esa es una conversación que vale la pena tener antes de su próximo despliegue, no después de su próximo incidente.