Las pruebas de aceptación de usuario, o UAT, comprueban si los usuarios de negocio pueden realizar el trabajo acordado con el ERP que se va a entregar. Que una pantalla se abra no basta: un pedido puede parecer correcto mientras su movimiento de stock o estado de aprobación es erróneo.
El objetivo es conectar los requisitos con resultados observables. Las UAT complementan las pruebas de desarrollo, pero no sustituyen las comprobaciones de seguridad, rendimiento o defectos técnicos.
Define el alcance y quién puede aprobarlo
Enumera los procesos incluidos en esta versión, los departamentos implicados y las personas autorizadas para aceptarlos. Comprueba requisitos previos como roles configurados, datos representativos e integraciones disponibles. Mantén visibles las exclusiones para no confundir una nueva funcionalidad con un defecto.
Los responsables del negocio deben definir los resultados aceptables junto al equipo de desarrollo. Este puede apoyar las pruebas, pero no debería decidir por sí solo si el trabajo cotidiano resulta viable.
Escribe escenarios con resultados verificables
Registra datos iniciales, rol del usuario, pasos, resultado esperado, resultado real y evidencias. Añade referencias de las operaciones para reproducir un fallo sin depender únicamente de una captura de pantalla.
Ejemplo ilustrativo: un pedido contiene diez unidades, se envían seis y quedan cuatro pendientes. Especifica el registro de envío, la cantidad restante, el movimiento de inventario y la regla de aprobación o facturación aplicable. No supongas que todas las empresas facturan los envíos parciales de la misma manera.
Incluye excepciones y límites de permisos
- Información de producto incompleta o inválida.
- Solicitudes duplicadas o reintentos tras una interrupción.
- Cancelaciones después de completar parte del proceso.
- Un usuario que intenta una aprobación reservada a su responsable.
- Correcciones que deben conservar el historial de la acción original.
Utiliza un entorno controlado y datos autorizados para las pruebas. Evita que las operaciones de prueba provoquen expediciones reales o avisos a clientes, salvo en una comprobación supervisada de producción acordada expresamente.
Separa defectos de nuevos requisitos
Un informe de defecto debe indicar el comportamiento esperado, la diferencia observada, el impacto en el negocio y los pasos para reproducirlo. Define la gravedad por sus consecuencias operativas, no por lo llamativo del problema. Asigna un responsable y una fecha de nueva comprobación.
Después de corregirlo, repite el escenario fallido y los pasos relacionados. Una modificación del cálculo de envíos puede exigir revisar también la vista de inventario y las cantidades pendientes del pedido.
Deja constancia de la decisión de lanzamiento
Acuerda qué problemas bloquean la puesta en marcha antes de empezar. Documenta incidencias pendientes, soluciones temporales, responsables y fechas. Una demostración satisfactoria no reemplaza los escenarios completados y la aceptación autorizada.
Confirma también quién atenderá a los usuarios tras el lanzamiento y cómo comunicarán problemas. Si un proceso crítico sigue sin comprobarse, reduce el alcance o aplaza esa parte; una firma por sí sola no demuestra que funcione.
Si preparas un proyecto ERP, consulta nuestro servicio de desarrollo ERP y comparte los procesos que tu equipo necesita validar.