# Ejemplo de informe de evaluación y lanzamiento

Versión 1.0 · 13 de octubre de 2026 · Wavect

Informe ilustrativo para un producto B2B de reservas ficticio. Los registros muestran el formato de entrega; no son resultados de pruebas de un cliente.

## Encargo y método

Preparar un prototipo existente para el primer piloto y transferir la operación al equipo del cliente. El alcance incluye creación de reservas, permisos, reintentos y recuperación. Dos organizaciones sintéticas contienen un administrador, un editor y un lector cada una. Evaluar la versión A, registrar defectos reproducibles y volver a probar las reparaciones acordadas en la versión B con los mismos datos.

## Decisión de lanzamiento

**Detener el piloto hasta aprobar la recuperación OP-01.** Las reparaciones de permisos y reintentos cumplen sus comprobaciones en la revisión ilustrativa. Un trabajo de copia de seguridad correcto no demuestra por sí solo que el equipo entrante pueda recuperar el servicio.

## Hallazgos y verificación

| ID | Gravedad e impacto | Reproducción | Esperado / observado en A | Aceptación y estado en B | Responsable |
| --- | --- | --- | --- | --- | --- |
| QA-01 | Alta: un lector modifica una reserva | Como lector de A, enviar la misma actualización que un editor; recargar la reserva | Esperado: rechazo sin cambios. Observado: actualización aceptada | APROBADO: lector rechazado y reserva intacta; editor de A sigue autorizado; B no accede al registro | Ingeniero de API |
| QA-02 | Alta: el reintento duplica la reserva | Enviar una reserva, interrumpir la respuesta y repetir con el mismo ID de solicitud | Esperado: una reserva y el mismo resultado. Observado: dos reservas | APROBADO: el reintento devuelve el resultado original; dos solicitudes diferentes siguen creando reservas separadas | Ingeniero de API |
| OP-01 | Bloqueo de lanzamiento: recuperación sin responsable verificado | Restaurar la última copia sintética en un entorno aislado con los accesos del equipo entrante | Esperado: reservas legibles y reinicio documentado. Observado: faltan credenciales y responsable | BLOQUEADO: asignar acceso, restaurar, comparar datos y medir recuperación frente al objetivo acordado | Responsable de plataforma |

La gravedad depende del impacto y la posibilidad de recuperación dentro del alcance, no de la herramienta que detecta el defecto. Un hallazgo alto requiere reparación o una decisión de riesgo con responsable antes del piloto. Un bloqueo incumple la condición de lanzamiento acordada.

## Rescate: conservar, reforzar, sustituir

- **Conservar:** modelo de reservas y calendario funcionales; verificarlos con los datos de prueba tras cada reparación.
- **Reforzar:** autorización del backend y deduplicación. Las reparaciones deben cubrir fallos y acciones permitidas.
- **Sustituir:** dependencia de despliegue en la cuenta del proveedor saliente por un flujo controlado por el cliente. Estos hallazgos no requieren reconstruir la función de reservas.
- **Orden:** establecer acceso del cliente, reparar QA-01 y QA-02, verificar y completar OP-01 antes del piloto. Esfuerzo y precio dependen de la inspección del repositorio y el alcance acordado.

## Aceptación de la transferencia

El equipo entrante debe compilar desde un commit fijado, desplegar en staging, verificar el recorrido crítico, consultar monitorización y ejecutar recuperación. Documentar responsables de repositorios y entornos, ubicaciones de secretos sin valores, despliegue y rollback, retención de copias y escalado de soporte. Rotar credenciales heredadas una vez comprobados los accesos de sustitución.

Código fuente, cuentas de infraestructura y registro de hallazgos quedan con el cliente. Cada asunto abierto necesita responsable, siguiente comprobación y fecha de decisión. La transferencia termina cuando el equipo demuestra las operaciones acordadas, no al enviar un documento.

## Evidencias y alcance pendiente

Adjuntar commits de A y B, descripción de datos, registros de solicitudes y respuestas depurados para QA-01 y QA-02, salida de regresión y registro de restauración OP-01. Mantener los mismos IDs entre hallazgo, reparación y revisión. Registrar revisor, fecha y entorno por resultado.

Capacidad bajo carga, pagos, funcionamiento móvil sin conexión y datos reales quedan fuera del ejemplo. APROBADO se refiere a la prueba y versión indicadas. El informe termina con la siguiente decisión de lanzamiento y su responsable.