Resumen:
- Probar no es hacer clicks al azar: es ejecutar casos escritos con datos reales y comparar contra un resultado esperado.
- El proveedor prueba que el sistema cumple el documento; el cliente prueba que el documento era lo correcto.
- Las pruebas se hacen por módulo terminado, no en un bloque al final del proyecto.
- La distinción entre error bloqueante y error menor debe estar en el contrato antes de la primera entrega.
- Las pruebas automatizadas no son un lujo: son lo que permite tocar el sistema en el año tres sin romperlo.
Hay un momento reconocible en los proyectos que salen mal: la semana en que el sistema se entrega, la operación empieza a usarlo con clientes reales y aparecen quince errores en tres días. Nadie fue negligente a propósito. Lo que pasó es que la etapa de pruebas se comprimió hasta desaparecer, porque es la única del proyecto cuyo recorte no se nota el día que se recorta.
Las tres capas que el proveedor debe traer
La primera son las pruebas automatizadas sobre la lógica que calcula o decide: el cálculo de impuestos, la aplicación de descuentos, la regla que determina si un pedido se puede surtir. Son código que prueba código, se ejecutan en segundos y se vuelven a correr cada vez que alguien toca el sistema. Su valor no es tanto hoy como en el año dos, cuando un ajuste pequeño en un módulo rompe algo en otro y la prueba lo detecta antes de que lo detecte un cliente.
La segunda son las pruebas de flujo completo: entrar, buscar un cliente, levantar un pedido, autorizarlo, facturarlo y ver que aparezca en el reporte. Prueban que las piezas hablan entre sí, que es donde se rompen los sistemas armados por módulos.
La tercera es la revisión manual de pantallas con volumen y datos sucios. Qué pasa con un nombre de ciento veinte caracteres, con un cliente sin RFC, con un producto cuyo precio es cero, con treinta mil registros en la lista. Los datos de prueba limpios esconden exactamente los problemas que la operación real produce todos los días.
Lo que le toca al cliente, y por qué nadie más lo puede hacer
Hay una clase de error que el proveedor no puede encontrar porque no conoce tu negocio. El sistema calcula la comisión como dice el documento, y el documento se equivocó porque nadie mencionó que a los clientes de gobierno se les calcula distinto. Eso solo lo encuentra alguien de tu operación, con tus números, comparando contra lo que hoy sale a mano.
La forma de hacerlo sin convertirlo en un mes de reuniones es la prueba paralela: durante una o dos semanas, la operación registra lo mismo en el sistema nuevo y en el método actual, y se comparan los totales al cierre del día. Es trabajo doble y encuentra en días lo que de otro modo aparece en tres meses.
Cómo se escribe un caso de prueba
| Mal escrito | Bien escrito |
|---|---|
| Probar que los pedidos funcionen | Como vendedor, registrar pedido al cliente Ferretería del Norte con 3 piezas de SKU 4471 y descuento 10%: el total debe ser 2,436.00 con IVA |
| Revisar los reportes | El reporte de ventas de octubre debe dar el mismo total que la suma de los CFDI timbrados en octubre: 1,284,310.52 |
| Ver que la app sirva sin internet | En modo avión, registrar dos visitas con foto; al recuperar señal, las dos aparecen en el sistema web en menos de un minuto |
| Checar permisos | Un usuario con rol capturista no debe ver el menú de precios de costo ni acceder por URL directa |
La columna derecha tiene números y nombres. Por eso se puede ejecutar y por eso el resultado no se discute.
Bloqueante o menor: la línea que evita el pleito
Una comercializadora de refacciones en Monterrey detuvo el pago final de un sistema por tres semanas. La lista de reclamos tenía veintidós puntos: dos eran graves, el reporte de cobranza daba mal el total y el sistema permitía facturar dos veces el mismo pedido. Los otros veinte eran tamaños de letra, un logotipo chico y el orden de dos columnas.
No había en el contrato una definición de error bloqueante, así que las veintidós líneas tenían el mismo peso en la discusión. Se resolvió acordando lo que debía estar escrito desde el principio: bloqueante es lo que produce un dato incorrecto, impide completar una operación del negocio o expone información a quien no debe verla. Lo demás entra a una lista de ajustes con fecha. Los dos errores graves se arreglaron en cuatro días, el sistema arrancó y los veinte detalles se cerraron en el mes siguiente.
¿Qué pruebas debe hacer el proveedor antes de entregarme el sistema?
Como mínimo tres capas: pruebas automatizadas de la lógica que calcula o decide, pruebas de los flujos completos de punta a punta, y una revisión manual de cada pantalla con datos parecidos a los reales. Si el proveedor no puede describir qué probó, lo que vas a recibir es una demostración ensayada, no un sistema probado.
¿Qué me toca probar a mí como cliente?
Lo que solo tú sabes: que los números cuadren con tu operación, que los casos raros de tu negocio funcionen y que la gente que va a usar el sistema pueda usarlo. El proveedor prueba que el software hace lo que dice el documento; tú pruebas que lo que dice el documento era lo que necesitabas.
¿Cuánto tiempo hay que dejar para pruebas?
Entre el quince y el veinte por ciento del tiempo del proyecto, y nunca al final como un bloque único. En un proyecto de catorce semanas eso son dos o tres semanas, repartidas: se prueba cada módulo cuando se termina, no todo junto en la semana trece, porque ahí ya no hay tiempo para arreglar lo que salga.
¿Qué es un caso de prueba y cómo se escribe?
Es una secuencia concreta con un resultado esperado: entro como vendedor, registro un pedido de tres productos con descuento del diez por ciento, y el total debe ser exactamente este número. Se escribe con datos reales de tu operación, no con "producto de prueba 1". Veinte casos de prueba bien escritos encuentran más que tres días de clicks al azar.
¿Puedo rechazar una entrega por errores?
Sí, si el contrato define qué es un error bloqueante y qué es uno menor. Lo sano es acordar que los bloqueantes impiden la aceptación y los menores se atienden en un plazo acordado sin detener el arranque. Sin esa distinción, cualquier detalle cosmético se vuelve excusa para no pagar y cualquier falla grave se vuelve "detalle".