Pruebas de humo para releases que los fundadores pueden ejecutar en 10 minutos

Qué es una prueba de humo (y por qué importa tras el despliegue)

Una prueba de humo es una comprobación rápida que ejecutas justo después de un release para responder a una sola pregunta: ¿sigue funcionando el producto en las cosas que más importan? No se trata de encontrar todos los bugs. Es una puerta rápida de aprobado/fallo que detecta las fallas que los usuarios reales encuentran primero.

Piénsalo como el conjunto mínimo de acciones que haría un cliente: iniciar sesión, completar la acción principal (crear o actualizar algo), recibir un correo clave y (si cobras) completar un pago. Si cualquiera de esos falla, quieres saberlo en minutos, no cuando se acumulen tickets de soporte.

Las pruebas de humo no reemplazan QA completo. No sustituyen tests automatizados, pruebas profundas de casos límite, revisión de accesibilidad ni pruebas de seguridad. Tampoco deberían durar una hora. Si tu checklist de release necesita una hoja de cálculo y una reunión, se va a saltar. La idea es rapidez y repetibilidad.

Muchas fallas solo aparecen después del despliegue porque producción se comporta distinto que tu laptop. Las causas suelen ser aburridas pero brutales: variables de entorno incorrectas (claves de API, ajustes de correo, webhooks de pago), secretos rotados, diferencias de permisos, migraciones que corrieron pero no coinciden con lo que el código espera, o comportamiento de cache/CDN que cambia rutas, cookies o cabeceras.

Esto es especialmente útil para fundadores que envían rápido con equipos pequeños, y para cualquiera que dependa de código generado por IA y prototipos rápidos. Cuando te mueves rápido, una prueba de humo simple y consistente puede ser la diferencia entre un lanzamiento tranquilo y una alarma.

Antes de empezar: 2 minutos de preparación

Una prueba de humo de 10 minutos funciona mejor cuando no improvisas. Dedica dos minutos a preparar un pequeño “kit de prueba” para que los resultados sean claros y repetibles.

Primero, elige los usuarios exactos con los que vas a probar. Usa una cuenta normal y una admin (o los roles que tenga tu app). Asegúrate de que las cuentas estén en un estado limpio: sin onboarding a medias, sin trial caducado, sin perfil bloqueado.

Luego, confirma dónde estás probando. Anota el entorno desplegado (producción, staging o un preview) y la URL exacta. Muchos “bugs” son solo alguien probando en el sitio equivocado o mezclando dos versiones.

Finalmente, asegúrate de poder validar las dos cosas que no puedes ver completamente desde la UI: el correo y los pagos. Ten una bandeja de entrada abierta para el usuario de prueba (y revisa spam/promociones). Si tu app cobra, confirma que estás en el modo correcto (test vs live) y que puedes acceder a donde verificarías un cargo exitoso.

Mantén una nota simple abierta y registra resultados a medida que avanzas. No confíes en la memoria.

Ten listos estos elementos:

• Credenciales de usuario de prueba y admin
• Nombre del entorno y URL que pruebas
• Acceso a la bandeja de entrada de prueba (y forma de buscar en ella)
• Dónde verificar resultados de pago (si aplica)

Si algo falla después, estas notas (y una captura si hace falta) ahorran horas de ida y vuelta.

La ejecución de 10 minutos: flujo paso a paso sencillo

Pon un temporizador de 10 minutos y sigue la misma ruta cada vez. El objetivo no es probarlo todo. Es detectar las fallas que bloquean a usuarios reales justo después del deploy.

Usa una ventana privada del navegador para no obtener un pase falso por sesiones en cache.

El orden fijo (no improvises)

Ejecuta las comprobaciones en una secuencia estricta. Así podrás comparar resultados entre releases y detectar exactamente dónde se rompió algo.

1. Abre la app como lo haría un usuario nuevo (landing → app).
2. Inicia sesión (o regístrate) y confirma que aterrizas en la pantalla inicial esperada.
3. Realiza la acción central de tu producto (crear, actualizar y ver lo que sea).
4. Dispara una notificación de la que dependen los usuarios (email o en-app).
5. Si cobras, ejecuta un pequeño flujo de pago de extremo a extremo en modo test.

Qué hacer cuando algo se rompe

Trata la primera falla seria como una señal de stop. No sigas clicando “para reunir más información”. Mezclarás síntomas y perderás tiempo.

Escribe una nota de bug pequeña que facilite reproducirlo: qué clicaste, qué esperabas, qué pasó y cualquier mensaje de error. Una captura es útil, pero los pasos importan más.

Tras un fix, vuelve a probar primero el área rota usando los mismos pasos. Si pasa, continúa en orden. Volver a comprobar al azar crea confusión y oculta la causa raíz.

Ir/No ir en un minuto

Antes de desplegar, decide qué debe pasar. Manténlo pequeño: login, el flujo principal de crear/editar/ver, correos críticos que lleguen y pagos que se completen (si aplica). Si algún elemento obligatorio falla, es No-Go aunque todo lo demás parezca bien.

Comprobaciones de login y autenticación

La mayoría de pruebas de humo deberían empezar por auth, porque un pequeño cambio puede dejar a todos fuera. Usa una ventana privada (o navegador distinto) para no usar una sesión en cache.

Las 5 comprobaciones que detectan la mayoría de fallas de auth

Hazlas rápido, en orden, y para en cuanto algo parezca raro:

• Crea una cuenta totalmente nueva (si el signup está habilitado) y confirma que aterrizas en la página esperada.
• Cierra sesión y vuelve a iniciar con la misma cuenta.
• Abre una página protegida estando desconectado (por ejemplo, la URL del dashboard) y confirma que te bloquea o te redirige al login.
• Usa “olvidé mi contraseña” y completa el restablecimiento. Confirma que llega el correo y que el enlace de reset funciona en una ventana privada.
• Tras resetear, inicia sesión de nuevo y confirma que permaneces logueado tras un refresh.

Mantén la barra simple. Confirmas que la app puede crear una sesión, mantenerla y proteger páginas privadas.

Un fallo común: tras un deploy, las cookies se fijan para un dominio equivocado o se marcan como “secure” de forma que rompen en tu entorno. El síntoma es “el login funciona”, pero cada refresh te echa fuera.

Si tu app soporta login con Google/GitHub, haz una pasada rápida con ello también, pero no dejes que reemplace la comprobación de email/contraseña. El social auth puede funcionar mientras tu manejo de sesiones propio está roto.

Cuando falle cualquier paso, anota la pantalla exacta y el mensaje que viste.

Flujos CRUD centrales en menos de 3 minutos

CRUD es crear, ver, editar, borrar. Si alguno de estos falla tras un deploy, los usuarios lo sienten de inmediato. El objetivo aquí no es probar a fondo. Es una señal rápida de que la app sigue siendo utilizable.

Elige un “objeto central” de tu producto (un proyecto, tarea, cliente, factura, listing). Usa una cuenta de prueba y haz el mismo bucle cada vez.

Bucle CRUD de 3 minutos

Muévete rápido y manténlo simple:

• Crea un nuevo registro con un nombre corto y único como “Smoke 2026-01-16 10:05.” Confirma que se guarda y aterrizas donde esperas.
• Búscalo desde la lista principal (o dashboard). Si búsqueda o filtros son clave, úsalos una vez.
• Edita un campo obvio (renómbralo). Revisa dos lugares donde ese valor debería aparecer (página de detalle + vista de lista).
• Elimínalo. Confirma que realmente desaparece tras un refresh, no solo que queda oculto.
• Prueba una “entrada inválida” una vez: deja un campo obligatorio vacío, pega texto muy largo o incluye caracteres especiales. Quieres mensajes de error humanos y claros.

Si algo falla, registra qué hiciste y qué viste. “Clic Guardar → spinner infinito” es mucho más útil que “CRUD roto”.

Cómo es una buena falla

Una buena app bloquea la entrada inválida con un mensaje corto como “Nombre es obligatorio.” Una mala app muestra una página en blanco, texto de error crudo o descarta cambios silenciosamente.

Si renombras un registro y la página de detalle se actualiza pero la lista muestra el nombre viejo tras refresh, suele apuntar a cache, una actualización en background fallida o un deploy parcial.

Comprobaciones de correo y notificaciones

El correo es donde “todo parecía bien en la app” se convierte en “los usuarios piensan que está roto”. Un pase rápido de correo es una de las partes de más valor de una prueba de humo porque detecta claves faltantes, plantillas erróneas y envíos bloqueados.

Dispara un correo transaccional real desde el producto (no desde una herramienta de admin). Buenos candidatos: restablecer contraseña, invitación o un recibo.

Mantén la comprobación enfocada:

• Confirma que el correo llega en un par de minutos.
• Confirma que el remitente/dirección from se ve correcto (no un placeholder).
• Revisa si hay fallos obvios de plantilla (como {{name}} apareciendo).
• Haz clic en el botón principal y confirma que aterriza en la página correcta y que la acción funciona.

Vigila señales que suelen aparecer tras deploy aun cuando la UI parece bien: retrasos largos (workers/colas), duplicados (reintentos sin idempotencia), variables faltantes, branding/enlaces de entorno equivocados, o links que se abren pero fallan al completar la acción.

Si usas emails de invitación, haz una corrida completa: envía la invitación, ábrela desde otro navegador (o ventana privada), acéptala y confirma que entras en el workspace/cuenta correcto.

Ejemplo: pruebas restablecer contraseña, el correo llega pero el botón abre una página que dice “token inválido”. Eso suele apuntar a un desajuste en la URL de la app, dominio de cookie o claves secretas entre entornos.

Comprobaciones de pagos y facturación

Los pagos fallan de formas previsibles tras un deploy: el checkout deja de funcionar, el callback de éxito nunca llega a tu app, o el usuario paga pero sigue apareciendo como no pagado. Un pase rápido de pagos es una de las comprobaciones más valiosas que puedes hacer.

Un pago exitoso

Elige el plan más barato (o un ítem de $1 en modo test) y ejecuta una compra completa: desde precios hasta recibo.

• Inicia el checkout y confirma monto, moneda y nombre del plan correctos.
• Completa el pago y verifica que aterrizas en una página de éxito clara.
• Refresca la app y confirma que el estado del usuario cambia (plan activo, acceso desbloqueado, créditos añadidos, lo que vendas).
• Abre la cuenta de usuario o la pantalla de facturación y confirma que el estado coincide con lo que acabas de comprar.

Si usas un webhook, aquí es donde suelen aparecer problemas. Un fallo común: el pago se realiza pero el acceso nunca se actualiza porque cambió el secreto del webhook, el endpoint o la variable de entorno.

Rutas de fallo, cancelación y reembolso

Haz una corrida “mala” a propósito (cancelar en checkout, usar una tarjeta que falla o activar un modo de fallo que tu proveedor soporte). Los usuarios deben ver un mensaje normal, no un spinner infinito.

• Cancela o falla el pago y confirma que la app explica qué pasó y qué hacer a continuación.
• Confirma que el usuario no queda marcado como pagado (sin acceso otorgado, sin créditos añadidos).
• Si tu producto soporta reembolsos o cancelar suscripciones, prueba ese flujo una vez y confirma que el estado se actualiza tras refresh.

Por último, revisa qué muestra y qué envía tu app. La UI y los correos no deberían mostrar números completos de tarjeta, códigos de seguridad, claves de API o volcados de error crudos. Una buena regla: si no lo pegarías en un chat de soporte, no se lo muestres a un cliente.

Checklist rápido (copia y reutiliza)

Copia esto en tus notas de release para ejecutar las mismas comprobaciones cada vez. Mantén la consistencia. El objetivo es detectar los fallos comunes de “funcionaba ayer” justo después del deploy.

Release: __________ Fecha/hora: __________ Entorno: __________

Qué cambió en este release (1–2 líneas):

Si algo falla, escribe el detalle mínimo que ayude a depurar: el paso exacto, el email del usuario usado y el texto del error.

Ir/No ir: ________ Responsable: ________ Si No ir, rollback? ________ Tickets de seguimiento: ________

Errores comunes que hacen que las pruebas de humo no detecten fallos reales

La mayor trampa es probar la app que quisieras haber desplegado, no la que los usuarios realmente usan. Una prueba de humo debería resultar un poco molesta: sesión nueva, dominio real, datos reales y los mismos permisos que un usuario normal.

Un fallo común es permanecer logueado como desarrollador o admin. Eso puede ocultar permisos rotos, pasos de onboarding faltantes y páginas que solo funcionan porque ya tienes datos precargados. Usa una ventana incógnita y una cuenta básica, o crea una nueva cada vez.

Otro fallo es probar en el entorno equivocado. Si pruebas en un build preview pero los clientes usan producción, puedes perder las cosas que fallan tras deploy: variables de entorno erróneas, migraciones faltantes o un callback URL mal configurado.

El correo es especialmente traicionero. A menudo funciona localmente con una bandeja de dev y luego falla en producción porque falta una clave del proveedor, un dominio de envío no está verificado o los mensajes van a spam. Trata cada deploy como si el correo pudiera estar roto hasta que veas un mensaje real.

Auth es otro punto común de ruptura. Si solo pruebas “iniciar sesión funciona”, aún puedes desplegar logout roto, restablecimiento de contraseña roto o expiración de sesión errónea.

Algunos hábitos aumentan la probabilidad de que tu prueba de humo detecte problemas reales:

• Prueba como un usuario totalmente nuevo y como un usuario existente normal (no solo como admin).
• Prueba en el entorno desplegado real, no solo local o preview.
• Verifica que llegue un correo real (y que el enlace dentro funcione).
• Incluye logout y restablecimiento de contraseña cada vez.
• Si algo falla, cambia una cosa, vuelve a probar y anota qué cambió.

No ignores “ayer iba lento”. Los usuarios sufren timeouts, hacen doble clic y refrescan a mitad de carga. Si una página está inestable durante tu chequeo de 10 minutos, suele ser el primer bug real en producción.

Ejemplo: detectar una falla post-despliegue en minutos

Maya tiene una pequeña SaaS. Ella despliega un cambio de viernes que “solo toca UI” y hace deploy. Antes de anunciarlo, corre su prueba de humo en una ventana privada.

Todo parece bien hasta que intenta restablecer contraseña. El formulario acepta su email y muestra un mensaje de éxito, pero no llega ningún correo de reset.

En lugar de adivinar, verifica el alcance rápido. Crea una cuenta nueva para disparar el correo de bienvenida. Ese sí llega. Luego intenta “cambiar email” (si la app envía una confirmación). Ese también llega. Así que no es “todo el correo está roto”. Es específicamente la ruta de restablecimiento.

Eso apunta a una falla post-deploy común: una plantilla, un endpoint o un job en background que falla mientras el resto del sistema parece sano. En el caso de Maya, el mensaje de reset de contraseña se movió a un nuevo ID de plantilla, pero la variable de entorno en producción seguía apuntando al antiguo.

Ahora toma una decisión simple:

• Si los usuarios no pueden iniciar sesión, hacer rollback primero y luego arreglar.
• Si solo están afectados los resets y la reparación es segura, desplegar un hotfix.
• En cualquier caso, publicar una nota corta de estado para que soporte no se sorprenda.

Ella elige hotfix, actualiza el ID de plantilla, redeploya y vuelve a probar el reset. El correo llega en menos de un minuto.

Por último, actualiza su checklist para la próxima vez: “disparar restablecimiento de contraseña y confirmar correo recibido” y “verificar plantilla/worker específico, no solo envío general”.

Próximos pasos cuando algo falla (y cómo puede ayudar FixMyMess)

Cuando una prueba de humo falla, trátala como una señal de stop, no como un bache. Si la misma falla ocurre dos veces, bloquea registros o pagos, o parece un tema de seguridad (datos expuestos, acceso admin extraño, claves filtradas), detén el release y haz rollback si puedes.

Una regla simple: si los usuarios no pueden iniciar sesión, crear datos o pagar, ya no estás “probando”. Estás enviando un producto roto.

Captura un pequeño paquete de información antes de pedir a alguien que lo arregle. Ahorrarás horas y acelerarás la reparación:

• Pasos exactos que seguiste (1, 2, 3), empezando desde una pestaña nueva
• Qué esperabas vs qué pasó (incluye texto de error)
• Captura o breve grabación de pantalla
• Marca temporal y zona horaria
• Detalles del entorno (producción vs staging, navegador, email de cuenta)

Luego convierte el checklist en hábito. Ejecútalo justo después del deploy y otra vez tras cualquier hotfix. Si registras issues, etiquétenlos consistentemente (login, CRUD, email, pagos) para que los patrones salten a la vista.

Si tu app fue generada por herramientas como Lovable, Bolt, v0, Cursor o Replit, las fallas post-despliegue suelen ser síntomas de problemas más profundos: auth rota, secretos expuestos, arquitectura desordenada o consultas inseguras a la base de datos. En esos casos, parchear un único mensaje de error a menudo no basta.

Si heredaste una base de código generada por IA que sigue rompiéndose tras deploy, FixMyMess (fixmymess.ai) puede ejecutar una auditoría de código gratuita y luego remediar las causas raíz, desde reparación de auth y lógica hasta endurecimiento de seguridad y preparación del deployment.