Pruebas de software: cómo saber que tu sistema funciona antes de pagarlo

En este artículo

1. ¿Qué son las pruebas de software y cuáles te tocan a ti?
2. Paso 1: Prepara tus casos de prueba antes de la entrega
3. Paso 2: Prueba en un entorno de prueba, no en el sistema real
4. Paso 3: Revisa más que «que funcione»
5. Paso 4: Reporta los errores para que se puedan corregir
6. Paso 5: Segunda vuelta y conformidad
7. Errores comunes al aprobar un sistema
8. ¿Y después de la entrega?
9. En resumen
10. Preguntas frecuentes

El día que el proveedor te dice «ya está listo», empieza la parte más importante del proyecto y la que más empresas se saltan: comprobar que el sistema funciona antes de dar la conformidad y pagar. Si apruebas sin probar, los errores aparecen cuando ya estás operando con clientes reales, y cada corrección se vuelve una discusión sobre si estaba o no en lo acordado.

Esta guía te explica, paso a paso, cómo hacer las pruebas de aceptación de un sistema a medida aunque no seas técnico: cómo armar los casos de prueba, qué revisar además de «que funcione», cómo reportar los errores y cuándo firmar. Lo escribimos desde el otro lado de la mesa: en CONIT desarrollamos sistemas a medida y webs para empresas de todo el Perú, y las entregas que salen mejor son siempre las que el cliente prueba a fondo.

¿Qué son las pruebas de software y cuáles te tocan a ti?

Las pruebas de software son las revisiones que comprueban que un sistema hace lo que debe y no hace lo que no debe. Hay varios tipos; al cliente le toca sobre todo la prueba de aceptación, la que decide si el sistema se recibe o se devuelve con observaciones.

No necesitas entender las cinco primeras, pero sí preguntar si se hicieron. Un proveedor serio te puede contar qué pruebas automáticas tiene el sistema y cómo revisó la seguridad.

Paso 1: Prepara tus casos de prueba antes de la entrega

Un caso de prueba es una situación concreta de tu negocio, escrita como una receta: qué haces, con qué datos y qué debería pasar. Prepáralos mientras se desarrolla el sistema, no el día de la entrega.

Sácalos de tu operación real. Si el sistema es de ventas, revisa las últimas semanas de pedidos y anota los distintos tipos que aparecieron. Un buen caso de prueba tiene este formato:

Tres reglas para que la lista sirva:

1. Incluye los casos raros. El caso normal casi siempre funciona. Lo que falla son las excepciones: el descuento especial, la devolución, el cliente que cambia de opinión, el pago que rebota.
2. Escribe el resultado esperado antes de probar. Si lo decides mientras pruebas, terminas aceptando lo que el sistema hace en lugar de lo que debería hacer.
3. Relaciónalos con el alcance. Cada caso debe salir de algo que está en el documento de requerimientos. Si no está, es una mejora para después, no un error. Por eso conviene escribir bien los requerimientos desde el inicio.

Paso 2: Prueba en un entorno de prueba, no en el sistema real

El sistema debe entregarse primero en un entorno de prueba (también llamado «staging»): una copia separada donde puedes registrar, borrar y equivocarte sin afectar a clientes reales ni a tu contabilidad.

Pide que ese entorno tenga:

• Datos parecidos a los tuyos: productos, precios, clientes y casos reales, pero sin información personal verdadera. La Ley 29733 y su reglamento vigente obligan a cuidar los datos personales, y una copia de prueba suele estar menos protegida.
• Pasarelas y facturación en modo de prueba, para hacer pagos ficticios y emitir comprobantes que no van a SUNAT.
• Un usuario para cada perfil: administrador, vendedor, caja, cliente. Así compruebas que cada uno ve solo lo que le corresponde.

Paso 3: Revisa más que «que funcione»

Un sistema puede hacer bien cada operación y aun así no estar listo. Además de tus casos de prueba, revisa estos cinco puntos:

1. Permisos. Entra con cada perfil e intenta hacer lo que no debería: que un vendedor vea los reportes de utilidad, que un cliente vea pedidos de otro cambiando un número en la dirección de la página. El control de acceso roto es el riesgo número uno de la lista OWASP Top 10:2025, la referencia mundial de seguridad en aplicaciones web.
2. Velocidad en celular. Prueba con tu teléfono y con datos móviles, no solo con la computadora de la oficina. Google considera buena una carga del contenido principal en 2.5 segundos o menos (web.dev, revisado el 10 de octubre de 2026).
3. Errores bien manejados. Escribe un correo mal, deja campos vacíos, sube un archivo enorme, corta el internet a mitad de un pago. El sistema debe avisar con claridad y no perder datos.
4. Correos y avisos. Comprueba que los correos automáticos llegan, que no caen en spam y que dicen lo correcto.
5. Copias de seguridad. Pregunta dónde se guardan, cada cuánto y pide que te muestren una restauración. Una copia que nunca se probó no es una copia.

Lo que hacemos en CONIT

Construimos sistemas a medida y páginas web para empresas de todo el Perú, y entregamos cada módulo en un entorno de prueba con un usuario por perfil para que tu equipo lo apruebe antes de pasar a producción. Así trabajamos sistemas como el de reservas de Adventur. Conoce el servicio de sistemas a medida.

Paso 4: Reporta los errores para que se puedan corregir

Un reporte que dice «no funciona» hace perder días. Un buen reporte permite al desarrollador repetir el error en minutos. Cada observación debe tener:

• Qué hiciste, paso a paso, con el usuario que usaste.
• Qué esperabas que pasara (el resultado esperado de tu caso).
• Qué pasó en realidad, con una captura de pantalla o un video corto.
• Gravedad: bloqueante (no se puede trabajar), importante (hay que corregirlo antes de salir) o menor (se puede corregir después).

Junta todo en una sola lista compartida, una hoja de cálculo basta, con una columna de estado: abierto, corregido, verificado. Evita mandar errores sueltos por WhatsApp: se pierden y nadie sabe cuáles quedaron pendientes.

Paso 5: Segunda vuelta y conformidad

Cuando el proveedor corrige, no basta con que diga «listo». Vuelve a ejecutar los casos que fallaron y, de paso, algunos de los que ya funcionaban, porque una corrección puede romper otra cosa.

Firma la conformidad cuando:

• No queda ningún error bloqueante ni importante abierto.
• Los errores menores están anotados con fecha de corrección.
• Recibiste los accesos, el manual o la capacitación acordada.
• Sabes quién da soporte desde el primer día de uso real.

La conformidad suele estar atada al pago de un hito, así que revisa qué dice el contrato sobre plazos de prueba, garantía y qué cuenta como error. Lo explicamos en las cláusulas que debe tener un contrato de desarrollo de software.

Errores comunes al aprobar un sistema

Estos son los tropiezos que más vemos cuando una empresa recibe un sistema:

1. Probar solo el caso feliz. Se registra una venta normal, funciona y se aprueba. La primera devolución real descubre el problema.
2. Que pruebe el gerente y no quien lo usará. El gerente prueba lo que imagina; la persona de caja prueba lo que pasa de verdad.
3. Aprobar por cansancio. El proyecto se alargó y se firma para cerrar. Los errores siguen ahí y ahora salen más caros.
4. Mezclar errores con mejoras. «No funciona» y «me gustaría que también hiciera…» van en listas distintas. La primera la corrige la garantía; la segunda se cotiza.
5. No probar en celular. Si tus clientes o vendedores usan el teléfono, esa es la prueba principal.
6. No pedir el entorno de prueba. Probar directamente en producción mezcla datos de prueba con datos reales.

¿Y después de la entrega?

Las pruebas no terminan el día de la firma. Las primeras semanas de uso real son, en la práctica, la prueba más exigente. Acuerda un periodo de acompañamiento con respuesta rápida y define desde el inicio cómo se manejarán los ajustes y las mejoras. Lo que debe incluir ese servicio está en mantenimiento de software: qué incluye y cuánto cuesta.

En resumen

• La prueba de aceptación la haces tú: comprueba con tus procesos reales que el sistema cumple lo acordado.
• Prepara los casos de prueba antes de la entrega, con los casos raros y el resultado esperado escrito.
• Prueba en un entorno separado, con datos parecidos a los reales y un usuario por perfil.
• Revisa permisos, velocidad en celular, manejo de errores, correos y copias de seguridad.
• Reporta cada error con pasos, captura y gravedad, y vuelve a probar después de cada corrección.
• Firma solo sin errores bloqueantes ni importantes abiertos, y con el soporte definido.

Preguntas frecuentes

¿Qué son las pruebas de aceptación de un software?

Son las pruebas que hace el cliente, o alguien de su equipo, para confirmar que el sistema cumple lo que se acordó en el alcance. No buscan revisar el código, sino comprobar que los procesos reales del negocio funcionan de principio a fin. Al terminar, el cliente da su conformidad o devuelve una lista de observaciones.

¿Quién debe hacer las pruebas: el proveedor o yo?

Los dos, en momentos distintos. El proveedor prueba durante el desarrollo que cada parte funciona y que no se rompió nada. Tú haces la prueba final con tus casos reales, porque nadie conoce mejor que tu equipo las excepciones del negocio. Lo ideal es que pruebe la persona que va a usar el sistema todos los días.

¿Cuánto tiempo deben durar las pruebas?

Depende del tamaño del sistema. Para un módulo sencillo suele bastar con unos días; para un sistema con varios perfiles e integraciones, conviene reservar una o dos semanas, más el tiempo de corrección y la segunda vuelta. Acuerda ese plazo por escrito en el contrato para que no quede abierto.

¿Qué hago si encuentro errores después de firmar la conformidad?

Revisa la garantía del contrato. Lo habitual es que el proveedor corrija sin costo los errores de lo que se acordó durante un periodo después de la entrega. Lo que no está en la garantía son los cambios o funciones nuevas: esos se cotizan aparte.

¿Se puede probar un sistema con datos reales de clientes?

Es mejor usar datos parecidos a los reales pero anonimizados, sobre todo si son datos personales de clientes o pacientes. La Ley 29733 de protección de datos personales obliga a cuidarlos, y un entorno de prueba suele tener menos controles que el sistema en producción. Si no queda otra, limita quién accede y borra esa copia al terminar.

¿Necesito contratar a un especialista en pruebas?

Para un sistema pequeño o mediano, normalmente no: basta con una buena lista de casos y una persona de tu equipo que la siga con calma. Para sistemas que manejan pagos, datos de salud o mucha información sensible, conviene sumar una revisión de seguridad hecha por alguien independiente.