Lista de pruebas después del despliegue: qué pedir tras una corrección

Por qué deberías pedir pruebas después de que una corrección se despliegue

Tras un despliegue, las correcciones pueden ser difíciles de ver. La app parece igual, el bug es complicado de reproducir o solo aparece en una cuenta concreta o en un momento específico. Así que cuando oyes “está arreglado”, te quedas con dudas: ¿llegó el cambio a producción y resolvió el problema correcto?

Omitir las pruebas es cómo los equipos aprueban trabajo que en realidad no llegó a donde están los usuarios. Una corrección puede haberse mergeado pero no desplegado, desplegada en el entorno equivocado o enviada pero enmascarada por caché o un feature flag. A veces solo cubre un caso y el fallo sigue existiendo en un flujo ligeramente distinto. En áreas de alto impacto como autenticación, pagos o parches de seguridad, esa incertidumbre puede costar dinero, dañar la confianza o crear riesgo legal.

Una lista corta de pruebas después del despliegue elimina las conjeturas sin añadir reuniones. Convierte una actualización vaga en un pequeño conjunto de recibos: qué cambió, dónde se está ejecutando y cómo se verificó. Con eso en la mano puedes repasarlo rápido, reenviarlo a un cofundador y aprobar con confianza. No se trata de “vigilar a los desarrolladores”, sino de hacer visible el trabajo.

Más necesitas pruebas cuando:

• El problema ocurrió en producción (no solo en staging)
• La corrección toca login, permisos o datos de cuenta
• Hay dinero involucrado (checkout, suscripciones, facturas)
• Se mencionó seguridad (secretos expuestos, riesgo de inyección)
• Usuarios reportaron el bug repetidamente o prometiste una fecha límite

Ejemplo: un desarrollador dice “el login está arreglado”. Una lista de pruebas incluiría la versión/build en producción, la hora del despliegue y una captura o un breve vídeo del flujo que fallaba ahora funcionando (más una prueba negativa, como una contraseña incorrecta).

Qué es una “lista de pruebas” (y qué no es)

Una lista de pruebas es un conjunto corto y itemizado de evidencias de que una corrección llegó al lugar correcto y funciona como esperas. Es lo mínimo que necesitas para confiar en un cambio sin leer código.

Una lista de pruebas debe confirmar tres cosas:

• Comportamiento: el bug desapareció
• Alcance: qué se tocó (y qué no)
• Tiempo: cuándo llegó el cambio al entorno que te importa

Debe mantenerse ligera. Para la mayoría de correcciones, 5 a 10 elementos bastan, siempre que cada elemento sea específico y fácil de verificar. También debe vivir donde ya haces seguimiento del trabajo (el mismo ticket, hilo de correo o doc compartido) para que no desaparezca.

Una lista de pruebas suele incluir:

• Marca de tiempo del despliegue y entorno (producción vs staging)
• Los pasos exactos usados para verificar la corrección (2 a 5 pasos, escritos de forma clara)
• Capturas o breves grabaciones de pantalla mostrando el comportamiento crítico
• Un pequeño conjunto de logs clave, mensajes de error o snapshots de monitorización que cambiaron
• Notas sobre el impacto (por ejemplo, “solo login” vs “auth y facturación”)

No es sustituto de QA completa, ni un montón de artefactos técnicos incomprensibles. Debe aclarar el resultado.

Qué no es:

• Un mensaje vago como “arreglado” o “desplegado” sin evidencia
• Un plan de pruebas largo que nadie ejecutará
• Un volcado de código o lista de archivos que no puedes validar
• Notas de lanzamiento escritas solo para desarrolladores
• Una promesa de “debería estar bien” sin mostrar resultados

Ejemplo: si se arregló un fallo en el checkout, la lista de pruebas debería mostrar una compra de prueba exitosa (en producción o en tu sandbox de pagos), la hora del despliegue y el error ya no apareciendo.

Qué incluir en una lista de pruebas

Una lista de pruebas tras el despliegue es un conjunto corto de recibos que responde tres preguntas simples: qué cambió, dónde puedes verlo y cuándo cambió. Si puedes verificar eso rápido, es mucho menos probable que apruebes una corrección que solo funcionó en el portátil de alguien.

Mantén el foco en la evidencia, no en una historia larga. Una página suele bastar.

Lo esencial (el conjunto “confiar pero verificar”)

Pide esto cada vez, incluso para arreglos pequeños:

• Qué cambió (en palabras sencillas): una a tres frases describiendo el cambio de comportamiento. Ejemplo: “El inicio de sesión ahora bloquea usuarios inactivos y muestra un mensaje claro.”
• Dónde verlo: el entorno exacto (producción vs staging), el nombre de la pantalla y cualquier rol de usuario requerido (admin, usuario normal, usuario invitado). Si hace falta una cuenta de prueba, indica cuál.
• Prueba del resultado: capturas o un breve clip mostrando los pasos clave y el estado final (mensaje de error, nuevo botón, diseño corregido).
• Cuándo y quién verificó: hora del despliegue, hora de la prueba y nombre de la persona que probó.
• Qué se probó (breve): ruta feliz más los edge cases importantes (contraseña incorrecta, sesión expirada, formulario vacío, red lenta).

Cuando sea posible, incluye un simple “antes vs después.” Una captura del antes y otra del después suele ser más convincente que un párrafo.

Extras útiles (cuando quieras mayor evidencia)

No siempre son necesarios, pero importan si la corrección toca seguridad, pagos o datos:

• Identificador de commit/build: un hash de commit o número de build que conecte la prueba con la versión desplegada.
• Logs o nota de monitorización: una captura que muestre que el error dejó de ocurrir, o una métrica que volvió a la normalidad.
• Nota de rollback: una frase sobre cómo desharían el cambio si aparece un problema nuevo.

Si heredas código generado por IA y es un desastre, pide la lista de pruebas y una nota corta sobre qué se limpió (por ejemplo: “se eliminó un secreto expuesto, se añadió validación server-side”).

Cómo pedirla (paso a paso)

Empieza con criterios de aceptación en una frase. Manténlo claro y comprobable, por ejemplo: “Los usuarios pueden iniciar sesión con email y contraseña, y permanecen logueados tras refrescar.” Eso le da al desarrollador un objetivo claro y te da algo que puedas verificar sin adivinar.

Luego pide una lista de pruebas tras el despliegue que cubra cada ítem de aceptación. Evita un único mensaje “Arreglado y desplegado”. Quieres prueba por ítem, porque una parte puede verse bien mientras otra sigue rota.

Una petición simple que puedes enviar

Puedes pedirlo sin sonar técnico:

• Comparte los criterios de aceptación (una frase, más los edge cases que te importen).
• Pide prueba por ítem (numerada, para que puedas responder al punto 3 si no queda claro).
• Solicita ambos: evidencia y pasos exactos de verificación (para que puedas repetir la comprobación más tarde).
• Especifica entorno y nivel de acceso (producción vs staging, admin vs usuario normal, cuenta de prueba vs cuenta real).
• Marca formato y plazo (ejemplo: “10 ítems cortos antes de acabar el día, cada uno con prueba con marca de tiempo”).

Aclara también qué cuenta como prueba. “Las capturas están bien, pero incluyan hora y la cuenta usada.” Si la corrección es solo backend, una captura puede no mostrar gran cosa. En ese caso pide el resultado visible para el usuario (una compra exitosa, un email recibido, una métrica del dashboard actualizada).

Reduce la ambigüedad eligiendo el entorno exacto. “Deployado a staging” puede sonar tranquilizador mientras producción sigue rota. Si necesitas producción arreglada, dilo.

Formato sugerido para la lista de pruebas (fácil de escanear)

Pídeles que usen la misma mini-plantilla para cada ítem: qué cambió, dónde se probó, pasos exactos, evidencia (captura o clip corto) y marca de tiempo.

Si las correcciones parecen riesgosas, solicita una breve nota “antes vs después” para revisar rápido.

Preguntas según el tipo de corrección

La lista de pruebas debe variar según lo que se arregló. Si preguntas siempre lo mismo, te perderás detalles importantes (como un bug visual que solo ocurre en cierto navegador, o un fallo de API ligado a una petición concreta).

Usa estos prompts para obtener evidencia que puedas revisar en minutos.

Preguntas por tipo de corrección

• UI (visual o flujo de clics): “¿Puedes mostrar un antes/después de la pantalla exacta, además del navegador y el dispositivo usados?” También pregunta: “¿Qué pasos seguiste para reproducirlo y qué pasos ahora muestran que está arreglado?” Si es inconsistente, pide una breve grabación de pantalla.

• Backend (API, base de datos, error de servidor): “¿Qué petición exacta fallaba y qué respuesta obtienes ahora?” Pide un ejemplo real con marca de tiempo y el entorno donde se ejecutó. Si había un código de error: “¿Qué status code veíamos antes y cuál vemos ahora?”

• Autenticación / permisos: “¿Qué cuentas de prueba usaste y qué roles tienen?” Luego pregunta sobre edge cases: “¿Probaste login, logout, sesiones expirada, restablecimiento de contraseña y un usuario que no debería tener acceso?” Si hubo tokens o cookies: “¿Qué cambió para evitar la falla anterior?”

• Fallo de seguridad (vulnerabilidad): “¿Qué era vulnerable en lenguaje sencillo y qué podría haber hecho un atacante?” Sigue con: “¿Qué cambió para bloquearlo?” y “¿Cómo validaste la corrección?” (un intento de prueba que ahora falla, un escaneo o una nota de code review). Si se expusieron secretos: “¿Se rotaron las claves y cómo sabemos que las antiguas no funcionan?”

• Rendimiento (páginas lentas, timeouts): “¿Qué métrica mejoró y dónde se midió?” Pide números antes/después y el periodo de tiempo. También pregunta: “¿La prueba se hizo con datos y tráfico similares a producción o con una muestra pequeña?”

Si tratas con código generado por IA, las correcciones de seguridad merecen pruebas extra porque cambios pequeños pueden ocultar riesgos mayores.

Tras recibir la prueba, verifica una cosa tú mismo (una pantalla, una cuenta, un flujo). Ese spot-check rápido suele detectar malentendidos antes de que se conviertan en otro incidente en producción.

Cómo revisar la prueba rápidamente (sin profundizar en lo técnico)

Trata la lista de pruebas como una comprobación rápida de confianza, no como una auditoría completa. Tu objetivo es confirmar que la corrección es real, está en el entorno correcto y coincide con lo que pediste.

Empieza por el ítem de mayor riesgo y ponte un límite de cinco minutos. Si el riesgo es “los usuarios no pueden iniciar sesión” o “los pagos fallan”, verifica eso antes que nada.

Flujo de revisión de 5 minutos

Lee la lista una vez y luego haz un spot-check ajustado:

• Identifica la acción de usuario más importante (iniciar sesión, checkout, restablecer contraseña).
• Confirma el alcance en palabras sencillas: qué cambió y qué no.
• Comprueba marcas de tiempo contra la ventana de despliegue esperada.
• Verifica con la misma configuración que tienen tus usuarios: tipo de dispositivo, rol de cuenta y entorno.
• Pregunta una cosa de seguimiento: “¿Qué debo vigilar en las próximas 24 horas?” Una buena respuesta nombra una o dos señales, como picos de error o tickets de soporte sobre una pantalla específica.

Luego haz una comprobación de límites. No necesitas entender el código, pero sí debes saber qué no tocó el cambio. Una lista de pruebas limpia facilita decir: “Esto tocó login, sesiones y redirects, no signup, no facturación.”

Señales rápidas de alerta

Señales que merecen seguimiento:

• La prueba son solo palabras como “arreglado” sin capturas, logs o marcas de tiempo.
• La evidencia viene de staging cuando pediste producción.
• Las capturas evitan el paso que fallaba (muestran la página de inicio en lugar del formulario que daba error).
• Los pasos usan una cuenta admin aunque la mayoría de usuarios son cuentas estándar.

Ejemplo: para un arreglo de login, pide una captura de un intento real de inicio de sesión con un usuario normal, la marca de tiempo del despliegue y una nota corta sobre qué cambió (por ejemplo, “configuración de cookies actualizada” o “se eliminó un bucle de redirección”).

Lista rápida que puedes copiar y usar siempre

Cuando una corrección vaya a producción, pide una lista corta de pruebas tras el despliegue. Debe ser rápida de leer, fácil de repetir y lo suficientemente específica para que puedas verificarla tú mismo en unos minutos.

Usa esta lista como petición por defecto:

• Para cada ítem de prueba: entorno (prod o staging), pasos exactos, evidencia (captura o clip corto) y marca de tiempo.
• La evidencia coincide con la afirmación: muestra la pantalla exacta, tipo de cuenta y estado ligado al bug original (no una página genérica de “funciona ahora”).
• Puedes reproducirlo: los pasos están escritos para que una persona no técnica pueda seguirlos y ver el mismo resultado.
• Se listan cambios de configuración: cualquier variable de entorno, feature flag, permisos o ajustes de terceros cambiados deben nombrarse (y dónde se cambiaron).
• Incluye plan de riesgo: si la corrección toca auth, pagos o datos, añade una nota de rollback o mitigación.

Si quieres una plantilla lista para copiar, envía esto:

Proof list request
1) Issue/Change:
2) Environment: production / staging
3) Location: page/feature + account used
4) Steps to verify:
5) Evidence: screenshot/clip + timestamp:
6) Related config changes (if any):
7) Rollback/mitigation (if high risk):

Si algo te parece vago, insiste en la pieza que falta. La mayoría de las veces es o los pasos o la evidencia.

Trampas comunes y cómo evitarlas

El mayor riesgo tras un despliegue es pensar que algo está arreglado porque viste “algo” cambiar. La prueba solo funciona cuando es específica y está ligada al problema real.

Trampa 1: Una captura sin pasos

Una sola captura puede ser real y aun así no tener significado. Puede ser una página cacheada, una ejecución afortunada o un flujo distinto al que solía fallar.

Evítalo pidiendo los pasos exactos seguidos, los datos usados (cuenta de prueba o registro de ejemplo) y una marca de tiempo. Mejor aún: una breve grabación de pantalla de principio a fin.

Trampa 2: Pruebas en el entorno equivocado

La gente prueba en staging y luego anuncia que está en vivo.

Evítalo exigiendo que el entorno se indique claramente (producción o staging) e incluyendo una marca de tiempo en producción. Si tu app muestra una etiqueta de versión en el pie o en una página admin, pide que la incluyan.

Trampa 3: Arreglos de auth que ignoraron roles y permisos

Los bugs de inicio de sesión suelen “funcionar para mí” porque el desarrollador probó con una cuenta admin.

Evítalo pidiendo qué rol de usuario se usó para cada prueba y qué permisos tiene. Si tu app tiene flujos admin, miembro e invitado, consigue pruebas para cada uno relevante.

Trampa 4: Faltan edge cases

Muchos bugs se esconden en entradas malas y estados vacíos, no en el flujo normal.

Evítalo solicitando pruebas para algunos edge cases: campos en blanco, contraseña errónea, sesión expirada y un usuario sin datos aún.

Trampa 5: Prueba del síntoma, no de la causa raíz

A veces la UI parece correcta, pero el problema subyacente sigue y volverá.

Evítalo pidiendo una nota corta “qué cambió y por qué” más evidencia de que la falla original desapareció (por ejemplo, un snippet de log antes/después).

Si quieres una solicitud estándar simple, pide:

• Entorno (producción o staging) y marca de tiempo
• Pasos reproducibles que probaron (los pasos del bug original)
• Cuentas y roles usados (especialmente para auth)
• Edge cases probados (2 o 3 realistas)
• Una nota corta sobre la causa raíz y el cambio exacto realizado

Ejemplo: validar un arreglo de login desplegado en un proyecto real

Caso realista: tu app fue generada con una herramienta IA, se lanzó una actualización rápida y ahora algunos usuarios no pueden iniciar sesión. A ti te funciona, pero varios clientes ven un error o se quedan atascados.

Pides una lista de pruebas para confiar en qué cambió y a quién ayuda. No necesitas un informe largo, necesitas pruebas acordes al riesgo: roles, dispositivos y el fallo exacto que viste.

Prueba mínima a pedir:

• Identificador de build o release en producción y hora del despliegue.
• Captura de un inicio de sesión exitoso como usuario normal, incluyendo la pantalla de destino.
• Captura de inicio de sesión exitoso como admin o staff, incluyendo una página con permisos.
• Captura desde un segundo tipo de dispositivo (por ejemplo, iPhone Safari y Windows Chrome).
• Evidencia de que el error original desapareció: una captura de logs o del sistema de error filtrada a los últimos 30–60 minutos.

También pide una lista numerada corta: los pasos que antes fallaban y los mismos pasos ahora pasando, con marcas de tiempo.

Cómo decides:

• Aprobado: roles y dispositivos funcionan y la tasa de errores baja.
• Aprobado parcial: funciona para un rol o dispositivo solo; pides una prueba adicional dirigida.
• Pedir rollback: el error persiste en producción o aparece un nuevo problema de login.

Siguientes pasos si aún no te sientes confiado

Si lees la lista y sigues inquieto, no lo ignores. Normalmente pasa una de dos cosas: la prueba es demasiado débil, o la corrección es correcta pero el riesgo no está cubierto (edge cases, seguridad, monitorización, rollback).

Primero, guarda lo que sí recibiste. Conserva la lista junto a tus notas de lanzamiento, aunque esté incompleta. Semanas después, cuando algo falle de nuevo, ese registro será la forma más rápida de responder qué cambió, cuándo y qué se verificó.

Un plan simple de siguientes pasos:

• Escribe en lenguaje sencillo lo que sigue sin quedar claro.
• Pide 1 o 2 pruebas faltantes que lo resolverían.
• Solicita un retest del camino de riesgo, no un “todo bien” general.
• Pacta un plan de rollback si el cambio es de alto riesgo.
• Fija una comprobación de seguimiento para revisar métricas y tickets de soporte.

Hazlo repetible. Si ves que pides siempre las mismas pruebas, conviértelas en una plantilla estándar.

Cuándo pedir una revisión independiente

Si la corrección tocó código generado por IA y sigue fallando, suele ser un problema de base de código, no un bug único. Los prototipos hechos con IA pueden esconder problemas como lógica enredada, secretos expuestos, auth frágil, queries inseguras y patrones que no escalan. Puedes parchear síntomas semanas sin arreglar la causa.

En esa situación, una revisión independiente suele ser la vía más rápida para recuperar confianza. FixMyMess hace auditorías de código gratuitas para identificar qué está roto, luego repara la lógica, endurece la seguridad, refactoriza áreas desordenadas y prepara despliegues con verificación humana.

Si quieres una acción clara: reúne la prueba que ya tienes, anota lo que sigue siendo incierto y decide si necesitas una corrección profunda (no solo otro parche).