La mayoría de los incidentes en producción no vienen de bugs exóticos e imposibles de prever — vienen de verificaciones básicas que se saltaron por apuro antes de un lanzamiento. Un checklist corto y siempre igual, revisado antes de cada versión, evita la mayoría de esos casos sin necesitar un proceso de release complicado.
Antes de probar: ¿qué cambió realmente?
Antes de ejecutar un solo caso de prueba, vale la pena tener claro el alcance real del cambio: qué archivos o módulos se tocaron, y qué otras partes del sistema podrían verse afectadas aunque no se hayan modificado directamente. Probar "todo, por las dudas" sin este paso hace perder tiempo en zonas que no cambiaron, y a veces deja sin revisar una zona que sí se vio afectada de forma indirecta.
El checklist
- Casos críticos ejecutados de nuevo: login, pagos, y cualquier flujo que si falla afecta a todos los usuarios — sin importar si el cambio de esta versión los tocó directamente.
- Regresión de lo que ya funcionaba: confirmar que la funcionalidad existente sigue igual, no solo que lo nuevo funciona. Es fácil arreglar un bug y romper algo que estaba bien.
- Probado en más de un navegador o dispositivo: al menos el navegador más usado por tus usuarios reales y una vista mobile, no solo el entorno donde se desarrolló.
- Casos negativos, no solo el camino feliz: campos vacíos, datos inválidos, doble clic accidental — donde suelen aparecer los bugs que un desarrollador apurado no alcanzó a cubrir.
- Bugs conocidos, revisados uno por uno: ¿hay bugs abiertos que esta versión debía resolver? Confirmar que de verdad se solucionaron, no solo que el código cambió.
- Plan de reversa claro: si algo sale mal después de publicar, ¿todos saben cómo volver a la versión anterior sin improvisar en el momento?
Después de lanzar: la primera hora importa
El checklist no termina cuando el botón de publicar se presiona. Los primeros minutos después de un lanzamiento son cuando más vale la pena estar atento: revisar que el sitio cargue con normalidad, que no aparezcan errores nuevos en los logs, y tener a alguien disponible que pueda reaccionar rápido si algo se rompe. Un lanzamiento "silencioso" sin nadie mirando las primeras horas es donde los problemas pequeños se convierten en incidentes grandes.
Un checklist que nadie sigue no sirve de nada
La parte más difícil no es escribir el checklist — es que de verdad se use en cada versión, no solo en las "importantes". Tenerlo escrito en un lugar fijo, vinculado a los casos de prueba reales del proyecto y con un registro de qué se ejecutó en cada lanzamiento, es lo que lo convierte en hábito en vez de una buena intención que se olvida bajo presión — exactamente el tipo de registro que QAcove deja armado por proyecto, con ciclos de ejecución que se pueden reutilizar en cada lanzamiento.