Las pruebas de aceptación de software (UAT, User Acceptance Testing) son la verificación final en la que tu equipo usa el sistema en preproducción y lo compara con criterios pactados por escrito con el proveedor. Si se cumplen, firmáis un acta de aceptación que cierra la entrega. Es la última fase de cualquier proyecto de software a medida para empresas y se prepara desde el contrato.
Firmar el acta demasiado pronto convierte cada defecto posterior en una petición de cambio que pagas aparte. No firmarla nunca deja el proyecto sin fecha de cierre y con el proveedor esperando el último pago. El testing automatizado de aplicaciones web del proveedor reduce los defectos que llegan a esta fase, pero no sustituye la validación de quien usará el sistema.
Al terminar sabrás cómo redactar los criterios y qué revisar en el acta antes de firmarla, incluidos los umbrales de las pruebas de carga previas al lanzamiento.
Qué son las pruebas de aceptación de software (UAT)
Las pruebas de aceptación de software son las que ejecuta el usuario final para comprobar que el sistema entregado cumple lo pactado y decidir si lo acepta. La metodología Métrica Versión 3 les asigna una finalidad precisa: "validar que el sistema cumple los requisitos básicos de funcionamiento esperado".
Así lo recoge el documento de Métrica Versión 3 sobre Implantación y Aceptación del Sistema, publicado en el Portal de Administración Electrónica. Las demos de cada sprint, que trata el artículo sobre metodología ágil con un proveedor externo, enseñan avances. La aceptación es un acto formal que en muchos contratos inicia la garantía y libera el último pago.
Criterios de aceptación: cómo escribirlos antes de desarrollar
Un criterio de aceptación útil describe un resultado observable que las dos partes pueden comprobar sin interpretar. Se redacta antes de desarrollar y se adjunta al alcance del contrato.
El formato Given, When y Then de Gherkin, el lenguaje de especificaciones ejecutables de Cucumber, obliga a escribir cada criterio como un ejemplo concreto y no como una intención. Imagina, como caso hipotético, una distribuidora que encarga un portal de pedidos. "El portal calcula bien los precios" no se puede aceptar ni rechazar. "Dado un cliente con tarifa mayorista, cuando añade 50 unidades, entonces ve el precio de su tarifa" sí.
- Funcionales: cada requisito del alcance tiene al menos un criterio comprobable.
- No funcionales: tiempos de respuesta bajo carga y navegadores soportados, con valores medibles.
- Documentales: la documentación técnica que exigir al proveedor se entrega y se revisa como un criterio más.
- De datos: los registros migrados cuadran con el origen, según el plan de migración de datos al nuevo software.
El entorno de preproducción para las pruebas de aceptación
El entorno de preproducción para la UAT reproduce la configuración y las integraciones de producción, y solo cambia los datos y las credenciales. Métrica Versión 3 va más allá y pide ejecutar las pruebas de aceptación en el entorno real de operación. En un proyecto privado, una réplica dedicada cumple ese objetivo sin afectar a los clientes.
- Datos realistas y anonimizados: volumen parecido al real y sin datos personales de clientes que no necesites.
- Versión congelada: el proveedor no despliega durante la ventana de pruebas salvo correcciones registradas.
- Integraciones en modo pruebas: la pasarela de pago y el ERP apuntan a sus entornos sandbox.
Si tu sistema ya está en la nube tras una migración a la nube para empresas de Madrid, la preproducción puede encenderse solo durante la ventana de pruebas y apagarse después.
Qué firmar y qué no en el acta de aceptación
El acta de aceptación es el documento con el que el cliente declara que el sistema cumple los criterios pactados, y su redacción decide qué pasa con cada defecto pendiente. Pacta en el contrato una clasificación de defectos como esta:
- Bloqueante: impide completar un proceso de negocio. Con uno abierto, el acta no se firma.
- Grave: el proceso funciona con una alternativa manual. Se firma solo con fecha de corrección escrita en el acta.
- Leve: afecta a la presentación. Se lista en el acta y se corrige dentro de la garantía.
Firma un acta que identifica la versión probada y enumera los defectos pendientes con su fecha. No firmes una conformidad genérica sin versión ni lista de defectos. Los fallos que aparezcan después entran por el sistema de tickets con SLA de soporte.
CodeZone Pro Tip: evalúa el registro de resultados de la UAT y decide si el acta se puede firmar según la clasificación de defectos pactada.
import csv
import sys
from datetime import date
# Columnas: id, resultado (ok/fallo), severidad (bloqueante/grave/leve), fecha_correccion; vacías = ""
def evaluar_acta(ruta_csv: str) -> list[str]:
motivos = []
with open(ruta_csv, newline="", encoding="utf-8") as f:
filas = list(csv.DictReader(f))
if not filas:
return ["No hay criterios registrados: no se acepta lo que no se ha probado"]
for fila in filas:
if (fila.get("resultado") or "").strip().lower() == "ok":
continue
severidad, fecha = (fila.get("severidad") or "").strip().lower(), (fila.get("fecha_correccion") or "").strip()
if severidad == "bloqueante":
motivos.append(f"{fila['id']}: defecto bloqueante abierto")
elif severidad == "grave":
# Un grave solo es aceptable con una fecha de corrección futura y por escrito
try:
if date.fromisoformat(fecha) < date.today():
motivos.append(f"{fila['id']}: la fecha de corrección ya ha vencido")
except ValueError:
motivos.append(f"{fila['id']}: defecto grave sin fecha de corrección válida")
elif severidad != "leve":
motivos.append(f"{fila['id']}: severidad no pactada '{severidad}'")
return motivos
if __name__ == "__main__":
motivos = evaluar_acta(sys.argv[1])
print("Acta firmable" if not motivos else "No firmar todavía:")
for motivo in motivos:
print(" -", motivo)
# Código de salida distinto de cero para que nadie lo pase por alto en un pipeline
sys.exit(1 if motivos else 0)El script aplica la misma regla a cada criterio, sin depender de la memoria de nadie. La reunión de cierre pasa de discutir impresiones a revisar una lista de motivos concretos.
Lo Que Arriesgas Si Firmas el Acta Sin Probar
Un acta firmada sin probar traslada al cliente el coste de cada defecto que aparezca después. Reserva en el calendario una ventana real para esta fase: los tiempos reales de un software a medida incluyen la aceptación y no terminan en la última entrega.
En Codezone pactamos los criterios de aceptación con el cliente al inicio del proyecto y los adjuntamos al alcance. Cuéntanos cómo quieres cerrar la entrega de tu proyecto y te ayudamos a preparar los criterios y el acta.
