El proveedor te muestra las pantallas terminadas. Todo se ve bien: la de ventas, la de inventario, la de clientes. Aprobás.
El día del arranque descubrís que se puede vender un producto sin existencia, que las devoluciones no descuentan del reporte de comisiones y que si dos cajas cobran al mismo tiempo, una factura se salta el número.
Nada de eso se ve revisando pantallas. Se ve corriendo procesos completos, con los casos raros incluidos.
Lo corto
Probá procesos, no pantallas. De la compra al proveedor hasta el cierre de caja, sin saltarse pasos.
Que pruebe quien va a usarlo, no el proveedor ni el dueño.
Usá tus datos reales, no productos de ejemplo.
La mitad de las pruebas son casos raros. Ahí es donde se rompe.
Anotá cada falla con el paso exacto para repetirla, o se pierde.
Probar pantallas no prueba nada
Una pantalla puede estar perfecta y aun así producir un resultado equivocado tres pasos más adelante.
La pregunta correcta no es "¿se ve bien la pantalla de ventas?". Es "¿si vendo este producto, el inventario baja, la caja sube, el margen se calcula bien y el reporte del mes lo refleja?".
Eso solo se sabe recorriendo el proceso entero y revisando el efecto en todos lados.
Los seis recorridos que hay que probar sí o sí
Compra completa. Pedido al proveedor, recepción, registro de la factura, y verificar que el inventario y el costo promedio quedaron bien.
Venta de mostrador. Buscar, agregar, cobrar en efectivo, imprimir, y revisar inventario y caja.
Venta con pago mixto y crédito. Mitad efectivo, mitad transferencia. Y una al crédito con abono parcial después.
Devolución. De una venta ya cobrada, y revisar qué pasa con inventario, caja y comisiones.
Ajuste de inventario. Con motivo, y verificar que queda registrado quién lo hizo.
Cierre de caja. Que cuadre con todo lo anterior, incluidas las devoluciones y los gastos.
Si estos seis funcionan de punta a punta con tus datos, ya cubriste el 80% del riesgo.
La mitad de las pruebas son casos raros
Acá se separa una prueba seria de una demostración disfrazada de prueba. Probá deliberadamente lo que no debería pasar:
Vender un producto con existencia cero. ¿Lo permite? ¿Avisa? ¿Debería?
Cobrar sin internet y ver qué pasa cuando vuelve.
Dos cajas cobrando al mismo tiempo. ¿Se repite o se salta un número de factura?
Un descuento mayor al permitido. ¿Lo bloquea o solo lo registra?
Anular una venta ya cobrada. ¿Queda rastro de quién y por qué?
Un cliente que pasa su límite de crédito.
El mismo producto con dos códigos.
Cerrar caja con una venta a medias en otra computadora.
Cada uno de estos casos, si no se prueba antes, se descubre con un cliente enfrente.
Que pruebe quien va a usarlo
Si prueba el proveedor, va a hacer lo que sabe que funciona. Si prueba el dueño, va a probar lo que le interesa a él.
Quien tiene que probar es la persona que va a estar en la caja y en la bodega todos los días, porque es la única que va a intentar hacer las cosas como se hacen de verdad.
Dales una lista de casos concretos, no "revisá el sistema". Y dales tiempo protegido: dos horas sin atender clientes valen más que una semana de ratitos.
Anotá las fallas para que se puedan repetir
Una falla que no se puede reproducir no se puede arreglar. Cada reporte necesita cuatro cosas:
Qué hiciste, paso por paso.
Qué esperabas que pasara.
Qué pasó.
Qué tan grave es: impide operar, molesta pero se puede seguir, o es cosmético.
Esa última clasificación es la que te va a permitir decidir si podés arrancar o no. Un problema cosmético no detiene un arranque; uno que impide facturar, sí.
Ponele número a probar bien
Probar cuesta tiempo y siempre hay presión por arrancar. La cuenta ayuda a decidir.
Si dedicás 12 horas de tu equipo a probar, a C$ 120.00 la hora son C$ 1,440.00. Si no probás y el primer día el sistema deja vender sin existencias, un solo día de operación desordenada en un negocio que vende C$ 16,000.00 diarios cuesta mucho más que eso, y eso sin contar el daño a la confianza del equipo.
Cómo saber si probaste suficiente
Los seis recorridos completos funcionan con tus datos reales.
Probaste al menos ocho casos raros y sabés cómo responde el sistema en cada uno.
Quien va a usar el sistema lo probó y dijo que puede trabajar así.
No queda ninguna falla que impida operar.
Las fallas menores están anotadas con fecha de solución.
Errores comunes
Revisar pantallas en vez de procesos. El error de fondo.
Probar solo el camino feliz. Tu negocio no vive ahí.
Probar con datos de ejemplo. No dice nada sobre tu operación.
Que pruebe el proveedor. Conoce el sistema, no tu negocio.
Aceptar "eso se arregla después". Después es cuando ya estás operando y duele.
Empezá esta semana
Escribí los seis recorridos con tus productos reales y entregáselos a quien va a usar el sistema. Que los corra y anote todo lo que no funcione como esperaba.
En Tienda en Control el día 4 es exactamente esto: el equipo practica vender, revisar existencias y cerrar caja antes de salir en vivo el día 5. Probar no es un paso opcional del proyecto; es el paso que decide si el arranque sale bien.
