BlogAceptació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.
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.
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.
Relacionado
Preguntas frecuentes
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.
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.
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.
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
- Azure Test Plans overviewMicrosoft
- Pruebas de softwareITI
Última actualización:
