[Blog]()Aceptación de software # Cómo aceptar un sistema: pruebas de negocio y pendientes verificables «Ya funciona» necesita un caso, un resultado y una persona que pueda aprobarlo. La aceptación empieza antes de la demostración. **[Jonathan Perez]()**Cofundador · Diseño, producto y ventas 8 de octubre de 2026 · 7 min de lectura **Respuesta breve** Acepta un sistema con pruebas acordadas de tus procesos críticos, ejecutadas por personas del negocio y acompañadas de resultados observados. Cada fallo necesita una decisión: bloquea la entrega, permite un uso limitado o queda como mejora posterior. Una corrección solo queda aceptada después de repetir el caso y revisar sus efectos. ## Hoja de prueba: Aceptar software con pruebas de negocio verificables «Ya funciona» necesita un caso, un resultado y una persona que pueda aprobarlo. La aceptación empieza antes de la demostración. Registra datos, resultado esperado, evidencia, responsable y resultado observado. [Descargar hoja CSV]() En esta guía - [Convierte el alcance en resultados que puedas comprobar]() - [Ejemplo ficticio: producir y entregar un pedido parcial]() - [Revisa la operación normal, la excepción y el reintento]() - [Después de corregir, vuelve a comprobar]() - [Entrega y aceptación necesitan una frontera clara]() ## Convierte el alcance en resultados que puedas comprobar «Módulo de producción terminado» no dice si puedes reservar materia prima, registrar una merma y entregar parcialmente un pedido. Escribe el inicio, los datos, los pasos y el estado final de cada proceso. Define quién lo ejecutará y quién puede aceptar el resultado. Si el requisito cambia durante la prueba, registra el cambio de alcance antes de evaluar al proveedor con otra regla. [ITI]() diferencia pruebas funcionales y aceptación respecto a necesidades y procesos del negocio. [Azure Test Plans]() permite organizar pruebas manuales y de aceptación con resultados. La herramienta puede ordenar el trabajo; los criterios, la representatividad de los datos y la decisión de usar el sistema siguen necesitando responsables. ## Ejemplo ficticio: producir y entregar un pedido parcial Una fábrica ensaya el pedido P-310 de 100 piezas. Hay material para 80, se produce un lote de 60 y calidad rechaza cinco. La salida esperada es 55 piezas liberadas, cinco rechazadas y 45 pendientes del pedido. Es un escenario sintético, no un resultado de un cliente. Su utilidad está en conectar producción, calidad y compromiso comercial en una sola comprobación. El comprador no debería aprobarlo porque cada pantalla abre. Debe encontrar el mismo pedido, ver la reserva de material, distinguir rechazo de entrega y comprobar que un segundo clic no crea otra salida. Acuerda de antemano cómo se manejará la cantidad pendiente. Si se permite cerrar el pedido sin justificarla, decide si eso incumple el proceso definido. | Estado |Qué significa |Siguiente decisión | | --- | --- | --- | | Aprobada |Resultado y evidencia coinciden con el criterio acordado |Puede cerrar ese caso | | Fallida y bloqueante |Impide un flujo crítico o altera datos |Corregir y repetir antes de liberar | | Uso limitado aceptado |Hay alternativa concreta y riesgo asumido por el dueño |Documentar límite, responsable y fecha | | No ejecutada |Faltó acceso, dato o dependencia |Sigue pendiente; no cuenta como aprobada | ## Revisa la operación normal, la excepción y el reintento La matriz debe identificar la versión probada, el ambiente y el dato usado. En evidencia, anota un folio, exportación o captura que permita reconstruir el resultado sin mostrar información sensible innecesaria. Un video largo de la demostración no reemplaza la referencia de un caso concreto. La columna observada se llena durante la ejecución, no desde la propuesta. | Prueba |Resultado esperado |Responsable del resultado | | --- | --- | --- | | Reservar material para 80 |Reserva visible sin autorizar una producción imposible |Producción | | Liberar 55 y rechazar cinco |Cantidades separadas y motivo del rechazo registrado |Calidad | | Entregar las 55 liberadas |Pedido queda con 45 pendientes |Ventas y almacén | | Intentar entregar las rechazadas |Bloqueo con una explicación útil |Calidad | | Repetir confirmación tras perder respuesta |Una sola salida; consulta del folio existente |Almacén | | Usuario sin permiso intenta liberar |Ningún cambio de estado, con intento trazable |Dueño del proceso | ## Después de corregir, vuelve a comprobar Pide una nueva ejecución del caso fallido sobre la versión corregida. También revisa un caso cercano que pudiera verse afectado: cambiar el cálculo de pendiente puede alterar devoluciones o cancelaciones. Conserva el resultado anterior y el nuevo; no borres la evidencia inicial para que la matriz parezca perfecta. El cierre de un fallo debe explicar qué cambió y quién confirmó el resultado. No reduzcas toda la decisión a un porcentaje. Nueve pruebas aprobadas y una salida duplicada pueden seguir impidiendo operar. Clasifica por efecto en el negocio y acuerda el tratamiento de cada pendiente. Rendimiento, seguridad especializada y recuperación pueden necesitar evaluaciones adicionales; una aceptación funcional no demuestra por sí sola que esas áreas estén resueltas. ## Entrega y aceptación necesitan una frontera clara Usa una copia controlada para el ensayo y acuerda qué datos se conservarán. La preparación de usuarios, conexiones, capacitación y ventana de corte puede limitar el uso aunque el código esté entregado. Relaciona la aceptación con el [plan de corte y reversa]() y revisa las [preguntas antes de contratar software]() para dejar responsabilidades y acceso por escrito. La hoja descargable contiene casos de ejemplo que debes adaptar a tu proceso. Trae un pedido anonimizado, una excepción frecuente y el alcance de la etapa a una [consulta gratuita]() de [consultoría de software](). Podemos revisar si los criterios permiten tomar una decisión concreta, sin convertir una demostración favorable en aprobación automática. ## Definamos cómo comprobar la entrega Tomemos un pedido o servicio con una excepción real y contrastémoslo con el alcance acordado. En el diagnóstico gratuito podemos definir el resultado esperado, quién lo verifica y qué pendiente impide aceptar esa etapa. - Alcance de la etapa y criterios acordados - Pedido o servicio anonimizado con una excepción real - Lista de usuarios que ejecutan y autorizan cada resultado [Agendar diagnóstico gratuito]()[Consultar por WhatsApp]() Relacionado - [Consultoría de software]() - [Software a la medida]() ## Preguntas frecuentes ### ¿El proveedor puede aprobar sus propias pruebas? Puede ejecutar y documentar verificaciones técnicas, pero la aceptación del negocio debe pertenecer a la persona acordada. Esa persona necesita datos y criterios suficientes para decidir; firmar una lista sin ejecutar los casos no demuestra el resultado. ### ¿Todas las pruebas deben aprobarse? Los bloqueos deben resolverse antes del uso que afectan. Otros pendientes pueden aceptarse con un límite y una alternativa documentados. La decisión depende del riesgo y del acuerdo; un porcentaje de aprobación no reemplaza esa revisión. ### ¿Qué evidencia es suficiente? La que permite identificar versión, dato, pasos y resultado sin repetir toda la conversación. Puede ser un folio con exportación, una captura autorizada o un registro del sistema. El tipo de evidencia depende del proceso y de la política de datos. ### ¿Una prueba fallida significa que debo cancelar el proyecto? No necesariamente. Un fallo bien descrito permite corregir y repetir. Si el criterio era ambiguo, aclárenlo; si falta una capacidad crítica fuera del alcance, revisen el acuerdo. No aceptes un resultado distinto solo porque la etapa debía terminar. ## Fuentes 1. [Azure Test Plans overview]()Microsoft 2. [Pruebas de software]()ITI Última actualización: 8 de octubre de 2026 ## Sigue leyendo [Cambio de sistema8 oct 2026 ### Cambio de sistema: ensayo, corte y condiciones para volver atrás]()[Operación2 oct 2026 ### Cómo documentar procesos sin burocracia (para que tu mejor empleado no sea el manual)]()[Guías2 oct 2026 ### Antes de contratar software a la medida: 10 preguntas para cualquier proveedor]() --- Canonical: https://nightlysoftware.com/blog/aceptacion-software-pruebas-negocio Updated: 2026-10-08 Description: Define pruebas de negocio, distingue bloqueos de pendientes y exige un nuevo ensayo tras corregir. Incluye una matriz de aceptación descargable.