Software a medida: una demo no basta para aceptarlo
La demo termina y todo parece funcionar. Pero el lunes una persona cambia un pedido, otra intenta aprobarlo y el informe ya no coincide. En un proyecto de software a medida, conviene acordar cómo se comprobará una entrega antes de darla por aceptada.
Esta guía ayuda a responsables de pequeñas y medianas empresas a preparar esa conversación con el proveedor. La pregunta útil es concreta: ¿qué tiene que poder hacer nuestro equipo y qué resultado debemos ver?
Convierte cada promesa en un resultado comprobable
«Gestionar pedidos» describe una capacidad, pero deja muchas interpretaciones abiertas. Un criterio de aceptación puede ser: una persona de ventas registra un pedido pendiente y una persona autorizada lo aprueba; hasta entonces, no aparece como confirmado.
La guía de historias de usuario de GOV.UK propone describir quién necesita algo, para qué y qué resultados permiten comprobar que se ha resuelto. Es una referencia metodológica; no impone obligaciones a una empresa española.
Acuerda estos criterios durante la definición del proyecto. Si aparecen después de desarrollar, será más difícil distinguir un defecto de una necesidad nueva. Aclara también qué queda fuera de la entrega.
Una ficha de prueba que tu equipo pueda usar
No necesitas empezar con una herramienta compleja. Para cada tarea importante, prepara una ficha con estos campos:
- Objetivo: qué trabajo debe completar la persona.
- Perfil y punto de partida: permisos, estado inicial y datos de prueba.
- Pasos: qué hace, incluida una excepción habitual.
- Resultado esperado: qué debe cambiar y qué debe permanecer igual.
- Evidencia: versión probada, fecha, resultado observado y captura o identificador sin datos sensibles.
- Decisión: aceptado, pendiente de corregir o no probado; responsable y siguiente paso.
«No probado» merece una casilla propia: que nadie haya encontrado un problema no demuestra que ese recorrido funcione.
Ejemplo hipotético: aprobar un pedido con una corrección
Imagina una distribuidora que encarga una aplicación interna. Su primera entrega permite preparar pedidos y aprobarlos. Este ejemplo es ilustrativo y no corresponde a un cliente real.
Recorrido habitual
Ventas crea un pedido de tres unidades. Administración comprueba el importe y lo aprueba. La ficha y el informe muestran el mismo total; el pedido conserva su identificador y el registro indica quién lo aprobó.
La excepción que cambia la decisión
Después, ventas corrige la cantidad. Antes de probar, la empresa debe elegir la regla: impedir cambios, devolver el pedido a revisión o permitir un ajuste autorizado. Si se ha acordado devolverlo a revisión, comprueba que pierde la aprobación anterior y deja de figurar como confirmado en el informe.
También prueba que una persona sin permiso no pueda aprobarlo. El objetivo no es añadir funciones durante la prueba, sino verificar el comportamiento que ambas partes acordaron.
Prueba con quienes harán el trabajo
Reserva tiempo para que usuarios del negocio ejecuten los recorridos con sus perfiles previstos, en un entorno separado y con datos ficticios representativos. Evita ensayar envíos o cobros sobre clientes reales.
La lista de preparación de Microsoft para Dynamics 365 incluye casos habituales y excepciones, roles correctos y validación del negocio. Aunque se refiere a ese producto, sirve como referencia para diseñar la aceptación de otras aplicaciones.
Estas pruebas de usuario complementan las pruebas técnicas: no sustituyen la revisión de seguridad, rendimiento, copias o integraciones. Si una conexión es crítica, revisa además cómo comprobar datos sin sincronizar entre CRM y ERP.
Deja por escrito qué permite ponerlo en marcha
Acuerda qué fallos bloquean la salida. En el ejemplo, aprobar sin permiso o mostrar importes incorrectos impediría aceptar ese recorrido. Un ajuste visual menor podría quedar pendiente si se documentan su impacto, responsable y fecha acordada.
Al cerrar una entrega, guarda los resultados, los puntos no probados y las correcciones pendientes. Define quién autoriza el arranque y cómo se atienden incidencias. Aceptar una versión concreta no equivale a garantizar que nunca habrá errores.
Qué enviar para solicitar una propuesta
El servicio de software a medida de Serboweb contempla análisis funcional, pruebas con usuarios y criterios de aceptación. El alcance y las responsabilidades se concretan en cada propuesta.
Cuéntanos qué proceso necesitas resolver, quién lo utiliza y una excepción que hoy os obligue a corregir trabajo. Con esa información podemos valorar el desarrollo y qué resultados conviene comprobar antes de ponerlo en marcha. No incluyas contraseñas ni datos de clientes en la consulta inicial.