Saltar al contenido
Guías4 min de lectura

Paquete de UAT y go-live del proyecto con cliente (con IA)

Antes del corte a producción, monta pruebas de aceptación de usuario: ChatGPT convierte el alcance en guiones, un Brief UAT en Google Docs, log de defectos en Sheets y cadencia Gmail hasta el go/no-go.

Por DoAIWork · 8 de noviembre de 2026

Paquete de UAT y go-live del proyecto con cliente (con IA)

En proyectos con cliente, la “UAT” muchas veces se convierte en una semana vaga en la que el cliente hace clic al azar y manda bugs por Slack. Así se lanza un viernes sin criterios de pass escritos, sin severidades y con un sponsor que creía que UAT era formación. Las pruebas de aceptación de usuario (UAT) son la ventana en la que usuarios de negocio demuestran que el entregable cumple criterios acordados: no es una demo sorpresa, no es la aceptación de hito para facturar una fase, y no es el hipercare post-lanzamiento.

Este playbook va después de entregar el candidato a release y antes del pase a producción. Combina ChatGPT para convertir el SOW en guiones ejecutables, un Brief UAT en Google Docs, un log de defectos en Google Sheets y tres correos en Gmail que cierran con un go/no-go explícito. Para el paquete de entrega, mira entrega del proyecto; para cambios de alcance durante UAT, usa solicitud de cambio.

Cuándo montar la UAT

Úsalo cuando:

  • Staging (o entorno UAT acordado) refleja el RC que vais a publicar.
  • Hay criterios de aceptación escritos (SOW, hito o especificación firmada).
  • El cliente nombra un responsable UAT con agenda y poder de decidir go/no-go.
  • Necesitáis trazabilidad antes de DNS, pagos o URLs públicas.

No lo uses si aún negociáis alcance o el cliente solo pide demo sin compromiso de pruebas.

Flujo completo

Loading diagram…

Paso 1 — Guiones desde criterios (ChatGPT)

Pega criterios en ChatGPT:

Eres QA lead en una semana UAT con cliente. Criterios: [pega SOW o hito]

Salida:
1) 12–25 casos en tabla: ID, rol, precondiciones, pasos, resultado esperado, prioridad (P0/P1/P2)
2) Cinco pruebas negativas (permisos, vacíos, bordes)
3) Fuera de alcance UAT (lista explícita)

Cada caso debe citar un criterio del documento.

Lleva la tabla al Brief UAT. Tú validas que un no técnico pueda ejecutarlos.

Paso 2 — Brief UAT de una página (Google Docs)

SecciónContenido
CabeceraProyecto, versión/build RC, fechas UAT (husos horarios)
EntornosURLs, cuentas de prueba, reglas de reset de datos
RolesOwner UAT, testers, tu contacto, escalado
Criterios de entradaQué debe estar listo el día 1 (smoke OK, contenido cargado)
Criterios de salidaP0=0 abierto; P1 con waiver o fix; go/no-go firmado
SeveridadesP0 bloquea lanzamiento; P1 fix o waiver pre-go; P2 backlog
GuionesTabla completa generada con ChatGPT
Proceso defectoCómo loguear en Sheets y SLA de triaje
Reunión go/no-goAgenda y regla de decisión

Comparte en comentarios hasta acordar guiones; luego edición solo en el log.

Paso 3 — Log de defectos (Google Sheets)

Columnas: ID, Caso, Severidad, Pasos, Esperado, Actual, Captura, Estado, Responsable, Fecha retest.

Clasificación de defectos UAT por severidad antes del go-live
Clasificación de defectos UAT por severidad antes del go-live

Triage con ChatGPT (una fila, datos personales redactados):

Etiqueta HECHO vs SUPOSICIÓN. Defecto UAT: [pega].
Clasifica P0/P1/P2 según nuestro brief.
Propón: datos para reproducir, o texto de waiver si es cosmético.

No cierres defectos sin retest humano.

Paso 4 — Cadencia Gmail (tres correos)

  1. Kickoff UAT — Brief, URLs, invitaciones a testers, horario de soporte, enlace al log.
  2. Checkpoint mitad UAT — Recuento por severidad, bloqueantes, waivers candidatos, fecha go/no-go.
  3. Resultado go/no-go — GO o NO-GO explícito, waivers P1 firmados, siguiente paso (ventana de lanzamiento o retest).

Redacta en ChatGPT; envía tú desde Gmail con fechas y build reales.

Paso 5 — Reunión go/no-go (30 min)

Agenda: smoke en staging; revisión P0/P1 en Sheets; waivers y riesgos; decisión y responsable de comunicar.

Si es NO-GO, define retest acotado (P0/P1)—no repitas toda la batería salvo cambio de criterios.

Paso 6 — Puente a lanzamiento, hipercare o garantía

Con GO: confirma lanzamiento, contacto de rollback, monitor primera hora; P2 deferidos pasan a hipercare o backlog; anota inicio de garantía si el contrato lo define.

Con NO-GO: time-box de fixes y retest focalizado; NO-GO por escrito evita el “aprobamos por teléfono” posterior.

Errores habituales

  • Sin criterios de salida — la UAT no termina nunca.
  • Solo prueban desarrolladores — negocio no valida flujos reales.
  • Slack como sistema de defectos — usa Sheets.
  • Mezclar UAT con formación — sepáralo en el Brief.
  • Go-live sin texto de waiver — P1 cosméticos acaban en guerra de garantía.

Checklist rápido

  • Build RC congelado en el Brief
  • Guiones trazan a criterios escritos
  • Responsable UAT nombrado
  • Sheets es la única entrada de defectos
  • Tres correos enviados o programados
  • Decisión go/no-go en el Doc

Más guías en guides para autónomos y pymes que entregan proyectos con IA—pruebas estructuradas sin fingir que el modelo firma por el cliente.

Guías relacionadas