Antes de lanzar una aplicación: cuándo y qué probar

Cuándo hacerlo

Cuando la funcionalidad está cerrada y antes de abrir a usuarios reales. Si se prueba demasiado pronto, lo probado cambiará; si se prueba la víspera del lanzamiento, no habrá tiempo de corregir.

Deja margen para corregir y para el retest. Las fechas se cierran junto con el alcance.

Qué probar

Muchos fallos graves de una aplicación nueva no los detecta un escáner, porque están en la lógica: un usuario que puede ver o cambiar datos de otro, un rol que hace lo que no debe o un paso de un proceso que se puede saltar.

Por eso la prueba se hace con un usuario de cada rol y revisando también la API que hay detrás, no solo la interfaz. Si la aplicación estrena dominio, conviene incluir lo que queda expuesto a internet a su alrededor.

Qué preparar

Un entorno igual que el de producción. Si hay preproducción equivalente, mejor trabajar ahí; si no, se pacta qué se puede tocar en producción y cuándo.

Un usuario de prueba por cada rol, con datos de prueba y no de clientes reales.

La autorización por escrito del titular de los sistemas. Si la aplicación está en un proveedor de nube o de alojamiento, revisa también sus condiciones para pruebas de seguridad.

Después del lanzamiento

Una prueba vale para lo que había ese día. Si la aplicación cambia mucho (roles nuevos, pagos, integraciones), la parte que cambia merece volver a probarse.

Y cuando se corrigen los fallos del informe, el retest comprueba que los arreglos aguantan.