Respuesta.

La organización de la prueba manual en la etapa de lanzamiento es un conjunto de medidas para la búsqueda rápida y efectiva de defectos en la versión del producto preparada para el despliegue, con un enfoque en las funciones más críticas y utilizadas con frecuencia.

Historia de la cuestión: En el pasado, los lanzamientos a menudo iban acompañados de "urgencias nocturnas": los testers se apresuraban a revisar todo, lo que afectaba la calidad de las pruebas, los errores "se escapaban" a producción y los recursos se gastaban de manera ineficiente. Gradualmente, se notó que, al sistematizar claramente las prioridades, era posible lograr un mejor resultado en menos tiempo.

Problema: El tiempo limitado para las pruebas antes del lanzamiento no permite verificar todo, además, aumenta el factor humano: fatiga, prisa, estrés. A menudo, los errores críticos solo aparecen después del despliegue, socavando la reputación del producto y creando caos en el equipo.

Solución:

Junto con el negocio, analistas y desarrollo, evaluar los escenarios críticos y de valor comercial.
Formar una lista de verificación de lanzamiento con los llamados escenarios "críticos": aquellos que se utilizan con mayor frecuencia o son arriesgados.
Realizar pruebas finales de smoke y sanity manualmente: verificar el inicio del sistema, el proceso de inicio de sesión, la realización de pedidos, pagos, etc.
Delimitar claramente las áreas de responsabilidad: quién es responsable de los datos de prueba, quién de los informes de defectos encontrados, quién de la comunicación con desarrollo.

Características clave:

Priorización de errores: encontrar y escalar lo crítico primero.
Uso de casos de prueba breves y de rápida ejecución y listas de verificación.
Comunicación operativa con el equipo de desarrollo para una rápida corrección.

Preguntas trampa.

¿Se puede "cubrirse las espaldas" y revisar manualmente toda la aplicación antes del lanzamiento?

No, generalmente no hay tiempo para una prueba manual completa; un enfoque ponderado centrado en los escenarios clave da un mejor resultado.

¿Vale la pena abrir "errores menores" antes del lanzamiento para que el equipo los conozca de antemano?

No, en modo de lanzamiento solo se deben escalar defectos críticos y bloqueantes, y los menos significativos deben documentarse como problemas conocidos y abordarse después del despliegue.

¿Es obligatorio escribir casos de prueba detallados manualmente en la etapa de lanzamiento?

No, a menudo es más fácil y rápido trabajar con listas de verificación o mini-scripts extraídos de los casos de prueba, lo que permite abordar rápidamente los escenarios relevantes.

Errores típicos y anti-patrones

Posponer las pruebas hasta las últimas horas, lo que hace que todo se realice apresuradamente, con pérdida de calidad.
Verificar escenarios poco utilizados o de poca importancia en detrimento de los claves.
Ausencia de pruebas finales de smoke/sanity inmediatamente antes del lanzamiento.

Ejemplo de la vida real

Caso negativo

Las pruebas de lanzamiento se realizan de noche, verificando rápidamente los documentos y olvidando el flujo crítico de pago. Al día siguiente, los usuarios no pueden pagar sus pedidos masivamente.

Pros:

Alta velocidad de verificación.

Contras:

Error crítico no detectado.
Riesgos de estrés a media noche, comunicación perdida con desarrollo.

Caso positivo

Antes del lanzamiento, el enfoque se centra solo en escenarios críticos (inicio de sesión, pago, guardado de pedidos, integración con socios). Los resultados se revisan con una lista de verificación, los errores se escalan de inmediato.