paulasilvatech ASP Personas del SDLC Agéntico v1.0.0
EN PT ES
14 quality · Verification

Analista UAT

Pruebas de aceptación de negocio.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El UAT Analyst es la persona que representa el negocio dentro de la fase de Verification. En un SDLC AI-nativo, el UAT Analyst opera un agente Acceptance Scribe que convierte la intención del negocio en evidencia de aceptación ejecutable — no un formulario estático de sign-off.

Resumen ejecutivo

El UAT Analyst cierra el loop entre los requisitos del Business Analyst y la realidad del usuario final. Donde el QA Engineer prueba que el sistema está construido correctamente, el UAT Analyst prueba que es el sistema correcto. En un SDLC AI-nativo, esa prueba se ensambla con un único agente Acceptance Scribe, cuatro slash prompts, instrucciones con alcance, y un catálogo de MCPs validados que alcanza Azure DevOps Test Plans, GitHub y Playwright para walkthroughs grabadas.

Las salidas primarias son escenarios de aceptación en lenguaje de negocio, un plan formal de UAT con participantes y cronograma, registros de sign-off respaldados por evidencia, y un mapa de trazabilidad que enlaza cada requisito de negocio a una demostración revisada. El UAT Analyst se protege contra el modo de falla más antiguo del software: entregar lo que se pidió sobre papel y no lo que el negocio necesita en la práctica.

El UAT Analyst es también el traductor entre los expertos de dominio e ingeniería. Dirige el último ensayo antes de producción y el primero después, confirmando que el comportamiento de producción coincide con lo que fue autorizado.

Rol y responsabilidades

Piensa en el UAT Analyst como un dramaturgo teatral dirigiendo el ensayo general final. El director, el escritor y los actores tienen su propia perspectiva; el dramaturgo asegura que la audiencia comprenda lo que está sucediendo y que la obra honre el material fuente. En un SDLC AI-nativo, el UAT Analyst es la persona responsable de la perspectiva de la audiencia en cada feature antes de que entre en producción.

Responsabilidades principales:

  • Convertir cada requisito de negocio en escenarios de aceptación Given-When-Then en lenguaje de negocio
  • Coordinar sesiones de UAT con expertos de dominio reales, no proxies
  • Grabar cada walkthrough de aceptación con el MCP Playwright para evidencia
  • Capturar sign-offs con firmas digitales almacenadas en el repositorio y referenciadas desde Azure DevOps Test Plans
  • Mantener la matriz de trazabilidad de negocio: requisito → escenario → evidencia → sign-off
  • Operar el agente Acceptance Scribe y los prompts /acceptance-scenarios, /uat-plan, /sign-off, /business-trace
  • Marcar cualquier comportamiento de producción que diverja del escenario autorizado dentro de 24 horas de la entrega
  • Curar el glosario de términos de negocio para que ingeniería y el negocio compartan un único vocabulario

Jobs to be done

  1. Como UAT Analyst, quiero que cada requisito de negocio tenga al menos un escenario de aceptación ejecutable, para que el sign-off esté respaldado por evidencia, no por opinión.
  2. Como UAT Analyst, quiero que las sesiones de UAT se programen automáticamente desde el plan de entrega, para que ninguna feature entre en producción sin un ensayo fechado.
  3. Como UAT Analyst, quiero que los walkthroughs grabados estén adjuntos a cada sign-off, para que auditorías y futuras regresiones tengan un artefacto para reproducir.
  4. Como UAT Analyst, quiero que las divergencias entre escenarios autorizados y comportamiento de producción se detecten dentro de un día, para que la confianza con el negocio se preserve.
  5. Como UAT Analyst, quiero una única matriz de trazabilidad de negocio consultable, para que el liderazgo pueda responder “¿está verificado el requisito X en producción?” en segundos.
  6. Como UAT Analyst, quiero que cada escenario esté escrito en las propias palabras del negocio, para que los expertos de dominio puedan aprobar sin traducción.
  7. Como UAT Analyst, quiero que los sign-offs tengan marca de tiempo y estén firmados, para que las auditorías de gobernanza y cumplimiento estén satisfechas sin empaquetamiento manual.
  8. Como UAT Analyst, quiero que el plan de UAT se distribuya en Microsoft Teams y Loop, para que los stakeholders vean fechas, propietarios y resultados en un único lugar.

Dolores antes de la era AI-nativo

  • Requisitos se traducen mal. Las personas del negocio hablan lenguaje de procesos, los ingenieros escriben código; los escenarios de aceptación en el medio se diluyen.
  • Sign-offs sin evidencia. Una casilla en un formulario no prueba nada cuando sucede el incidente.
  • UAT como ocurrencia tardía. UAT recibe los últimos dos días antes de la entrega; los problemas encontrados allí o se envían o la entrega se retrasa.
  • Escenarios obsoletos. Los escenarios escritos para la versión 1 siguen siendo los únicos escenarios para la versión 4.
  • Sin loop de retroalimentación de producción. El escenario autorizado nunca se re-verifica en producción, así que la desviación pasa desapercibida.
  • Programación manual. Las sesiones de UAT se coordinan por correo electrónico con colisiones de calendario de cinco vías.
  • Herramientas desconectadas. Sign-offs por correo electrónico, escenarios en un documento, evidencia en una unidad compartida; nada es rastreable.

Flujo diario AI-nativo

El UAT Analyst trabaja principalmente en Microsoft 365 (Teams, Loop) y Visual Studio Code con GitHub Copilot, invocando el agente Acceptance Scribe para redactar y mantener escenarios.

Setup matinal

  1. Abre el canal Release Candidate en Microsoft Teams; verifica qué features están en la cola de UAT.
  2. En VS Code, ejecuta /uat-plan --release=next para regenerar el plan con tiempos de sesión, participantes y slots de evidencia requeridos.
  3. Revisa alertas de desviación nocturna de Azure Application Insights contra escenarios previamente autorizados.
  4. Trae el último SPECIFICATION.md y confirma que requisitos nuevos o cambiados tengan escenarios en borrador listos para revisión.
  5. Sincroniza con el Business Analyst para confirmar que el vocabulario de dominio se haya añadido al glosario.

Ejecución al mediodía

  1. Facilita sesiones de UAT con expertos de dominio. Usa el MCP Playwright para grabar cada walkthrough.
  2. Para cada escenario ejecutado, ejecuta /sign-off para capturar el resultado, enlace de evidencia e identidad del firmante; el prompt escribe un registro firmado en el repositorio.
  3. Para requisitos nuevos, invoca /acceptance-scenarios para redactar bloques Given-When-Then en lenguaje de negocio, luego revisa con el experto de dominio antes de congelar.
  4. Abre un PR que añade o actualiza los archivos de escenario; los revisores incluyen el Business Analyst y el Product Owner.

Revisión al final de la tarde

  1. Ejecuta /business-trace para regenerar la matriz de trazabilidad y publicarla en Loop para los stakeholders.
  2. Verifica el reporte de divergencia: cualquier telemetría de producción que contradiga un escenario autorizado se convierte en un ticket de incidente en GitHub Projects.
  3. Publica un resumen diario en Microsoft Teams con conteos de sign-offs, escenarios abiertos y cronograma del próximo día.

Primitivas recomendadas

Agente

AgenteArchivoPropósito
acceptance-scribe.github/agents/acceptance-scribe.agent.mdRedacta escenarios de aceptación, mantiene el plan de UAT, registra sign-offs y refresca la matriz de trazabilidad de negocio

Slash prompts

ComandoArchivoPropósito
/acceptance-scenarios.github/prompts/acceptance-scenarios.prompt.mdConvertir un requisito de negocio en escenarios Given-When-Then en lenguaje de negocio
/uat-plan.github/prompts/uat-plan.prompt.mdGenerar el cronograma de UAT, participantes, slots de evidencia para una entrega
/sign-off.github/prompts/sign-off.prompt.mdCapturar una aceptación autorizada y respaldada por evidencia de un escenario
/business-trace.github/prompts/business-trace.prompt.mdRefrescar la matriz de trazabilidad de negocio y exportar a Azure DevOps Test Plans

Instrucciones con alcance

Alcance (applyTo)ArchivoPropósito
docs/scenarios/**/*.feature.github/instructions/scenarios.instructions.mdReglas en lenguaje de negocio, sin jerga técnica, un requisito por escenario
docs/uat/**/*.md.github/instructions/uat-plan.instructions.mdFormato del plan de UAT con participantes, fechas, enlaces de evidencia
docs/signoff/**/*.md.github/instructions/signoff.instructions.mdFormato de sign-off con firmante, marca de tiempo, URL de evidencia

Hooks

  • pre-release: bloquea la entrega si algún requisito en alcance carece de un escenario autorizado
  • post-merge: reconstruye la matriz de trazabilidad de negocio y envía a Azure DevOps Test Plans
  • nightly: compara telemetría de producción contra escenarios autorizados y emite problemas de divergencia
  • pre-uat-session: genera el correo del participante, invitación de Teams y lista de verificación de evidencia
  • post-uat-session: archiva la grabación del MCP Playwright en Azure Blob Storage y la enlaza desde el sign-off

MCPs validados

MCPPropósitoDueño
GitHub MCP ServerGestionar PRs que añaden escenarios y sign-offs, abrir problemas de divergenciaGitHub
Azure DevOps MCP ServerSincronizar plan de UAT y sign-offs en Azure DevOps Test PlansMicrosoft
Playwright MCPGrabar cada walkthrough de UAT para evidenciaMicrosoft
Azure MCP ServerExtraer telemetría de Application Insights para detección de desviación de producciónMicrosoft
Microsoft Learn Docs MCPResolver semántica de features de Microsoft 365 y Azure referenciadas en escenariosMicrosoft

Ejemplos reales

Escenario A: un nuevo flujo de aprobación de reclamaciones

El Business Analyst publica REQ-CLM-210: “Los aprobadores deben recibir una notificación de Teams dentro de 30 segundos de que una reclamación entra en revisión.” El UAT Analyst invoca /acceptance-scenarios para redactar tres escenarios Given-When-Then (camino feliz, camino retrasado, camino usuario no disponible). Se realiza una sesión con dos expertos de dominio; el Acceptance Scribe registra los walkthroughs vía MCP Playwright. /sign-off captura las firmas. La matriz de trazabilidad de negocio cambia REQ-CLM-210 de draft a accepted-prod.

Escenario B: divergencia capturada en producción

La telemetría de Application Insights muestra que las notificaciones tardan 70 segundos en el 2 por ciento de las reclamaciones un sábado. El hook de divergencia nocturna compara contra el autorizado REQ-CLM-210 y abre una incidencia de GitHub en minutos. El UAT Analyst coordina con el SRE; la causa raíz es el throttling de Azure Service Bus. Después de la corrección, un /sign-off acortado re-verifica el escenario, y la matriz vuelve a accepted-prod.

Escenario C: retiro de un escenario

Un regulador depreca un paso de KYC; el Business Analyst marca REQ-KYC-018 como retirado. El UAT Analyst invoca /business-trace para tachar el escenario, archiva el último sign-off con razón retired y publica el registro de cambios en Microsoft Loop. Ingeniería elimina el camino de código con confianza porque la matriz de trazabilidad no muestra escenarios downstream restantes.

Anti-patrones

  • Sign-off de casilla. Una firma sin evidencia enlazada no es mejor que ningún sign-off. Siempre adjunta la grabación de Playwright y un ID de escenario.
  • Ingeniería redacta escenarios. Cuando los ingenieros redactan escenarios de negocio, codifican suposiciones del código; haz que los expertos de dominio revisen o rechacen cada escenario.
  • UAT agrupado al final. UAT por feature supera UAT por entrega; retrasar colapsa la ventana de retroalimentación.
  • Inflación de escenarios. Los escenarios que prueban diez cosas a la vez no pueden autorizarse limpiamente. Un escenario, un resultado.
  • Glosario sin dueño. Un glosario de dominio sin dueño designado se pudre; el UAT Analyst es el dueño.
  • Sign-offs obsoletos. Un sign-off de seis entregas atrás no prueba nada sobre el código de hoy; actualiza en cambios de versión mayor.
  • Escenarios ocultos. Los escenarios en una unidad privada o hilo de correo no pueden auditarse; todo vive en el repositorio.

KPIs y métricas de impacto

MétricaBaseline (manual)Objetivo (agéntico)Fuente
Requisitos con escenario autorizado70 por ciento100 por cientoMatriz de trazabilidad de negocio
Tiempo de ciclo de sign-off4 días< 1 díaTimestamps de PR de GitHub
Divergencias de producción a escenario sin resolver > 24h100Hook de divergencia
Sesiones de UAT grabadas40 por ciento100 por cientoArchivo del MCP Playwright
Incidentes de desviación de vocabulario de negocio6 por trimestre0Diff de glosario
Tasa de ausencia de participantes25 por ciento< 5 por cientoInvitaciones de Teams
Preparación para auditoría de sign-offDíasMinutosExportación de Azure DevOps Test Plans

Madurez en cuatro niveles

  • L1 Manual: Escenarios en un documento compartido, sign-offs por correo, sin grabaciones, sin matriz de trazabilidad.
  • L2 Asistido: Copilot redacta escenarios pero los humanos los copian manualmente en un wiki; los sign-offs son capturas de pantalla.
  • L3 Aumentado: Agente Acceptance Scribe, cuatro slash prompts, instrucciones con alcance, grabaciones del MCP Playwright enlazadas desde sign-offs.
  • L4 Autónomo: Detección de divergencia nocturna, programación automatizada en Microsoft Teams, matriz de trazabilidad de negocio publicada diariamente en Loop, hook de pre-entrega bloquea requisitos inaceptables automáticamente.

Integración con otras personas

  • Del Business Analyst: requisitos aprobados con sentencias EARS y actualizaciones de glosario de dominio.
  • Del Product Owner: plan de entrega priorizado indicando qué requisitos necesitan UAT en este ciclo.
  • Para el Developer: problemas de divergencia con escenarios autorizados enlazados y telemetría de Application Insights.
  • Con QA Engineer: fixtures compartidas de Playwright; escenarios de aceptación alimentan candidatos de suite de regresión.
  • Para el Compliance Auditor: la matriz de trazabilidad de negocio y artefactos autorizados como evidencia de auditoría.
  • Para el Release Manager: hook de pre-entrega bloquea en sign-offs faltantes.
  • Con Tech Writer: sincronización de glosario para que los docs de usuario y escenarios compartan el mismo vocabulario.

Glosario

  • Escenario de aceptación: un bloque Given-When-Then escrito en lenguaje de negocio, propiedad de un experto de dominio.
  • Sign-off: una aceptación autorizada, marcada con tiempo y enlazada a evidencia de un escenario.
  • Matriz de trazabilidad de negocio: el mapeo vivo desde requisito a escenario a evidencia a firmante.
  • Divergencia: comportamiento de producción que contradice un escenario autorizado, detectado por comparación de telemetría.
  • Glosario de dominio: la lista canónica de términos de negocio compartidos entre ingeniería y el negocio.
  • Evidencia: un walkthrough grabado, típicamente producido vía MCP Playwright, referenciado desde el sign-off.
  • Ensayo: el walkthrough final antes de la entrega, ejecutado en un ambiente de staging con el roster completo de participantes.

Referencias