Blog de Pruebas de Software

Todo líder de QA ha visto la misma película. Un equipo decide automatizarlo todo, celebra las cifras de cobertura durante un trimestre, y luego pasa el año siguiente ahogado en pruebas inestables y reescribiendo scripts en cada sprint. La suite que debía ahorrar tiempo es ahora la razón por la que los releases se retrasan, los desarrolladores fusionan alrededor de un pipeline en rojo, y el CFO empieza a preguntar por qué la partida de QA sigue creciendo mientras la velocidad de entrega no lo hace.

¿Alguna vez te ha pasado que, tras lanzar un cambio pequeño durante la noche, un cliente amaneció sin poder llegar al checkout? La modificación parecía inofensiva, pero rompió silenciosamente una función que nadie había tocado en meses. Esa brecha entre "cambiamos una sola cosa" y "algo no relacionado falló" es exactamente el problema que las pruebas de regresión de software existen para resolver.

Las pruebas de resistencia tienen un problema de credibilidad. Los equipos las ejecutan, obtienen un informe limpio, lanzan la compilación y luego ven aparecer una fuga de memoria en producción tres días después. La ejecución no estaba defectuosa. Midió lo que se configuró para medir. El problema es que la mayoría de las configuraciones de resistencia responden a una pregunta más estrecha de lo que los ingenieros creen, y por eso las ejecuciones aprobadas y la producción con fugas siguen coexistiendo.

Un jugador se coloca unas gafas, da tres pasos dentro de tu mundo bellamente diseñado y de inmediato se las quita porque se le ha revuelto el estómago. Ese momento no aparecerá en un registro de fallos, pero al instante te cuesta la venta, la reseña y la confianza del jugador. En la realidad virtual (RV), la línea entre una obra maestra de cinco estrellas y un reembolso inmediato se reduce a milisegundos: el tiempo que tarda un fotograma en llegar y que el movimiento se sienta bien en el cuerpo humano, no solo en un monitor.

Tu equipo ya ejecuta pruebas negativas. Los correos electrónicos no válidos se rechazan. Los campos obligatorios en blanco lanzan el error correcto. Los valores límite están cubiertos para cada entrada numérica. Y aun así, la bandeja de entrada de soporte se sigue llenando de cosas para las que nadie escribió un caso: dos pedidos idénticos realizados con 400 ms de diferencia por un doble clic, una canalización de analítica que se cae ante un emoji en un nombre visible, una comprobación de unicidad que trata john@acme.com y la misma dirección con un espacio final invisible como dos cuentas diferentes.

Unity impulsa algunos de los títulos más grandes del planeta, y los envía a teléfonos, consolas, navegadores y computadoras de escritorio desde un único proyecto. Ese alcance es precisamente lo que hace complicadas las pruebas de juegos en Unity, porque una sola compilación tiene que sobrevivir en iPhone, Android, consola y escritorio, y cada uno de esos destinos falla a su manera.

Un equipo despliega una exportación nocturna que funciona sin problemas con 999 usuarios en el entorno de staging, pero se agota exactamente al llegar a 1.000 en producción. Nadie escribió «1.000» en la especificación. No hay ningún formulario que validar, ni ningún rango de edad que comprobar. El límite es real, y la batería de pruebas nunca lo tocó.

Tu app funciona bien en inglés. Entonces marketing programa un lanzamiento en Alemania, Japón y Brasil, y de repente el botón «Continuar» se convierte en «Weitermachen», la notificación push llega a las 3 AM hora local y las capturas de pantalla de la App Store todavía muestran precios en dólares estadounidenses. Nada de eso es un problema de traducción. Es un problema de QA móvil, y no se parece en nada al QA que hiciste para la compilación en inglés.

Has pasado meses puliendo las mecánicas de tu juego y ultimando el apartado artístico, solo para que el título se cierre de forma inesperada el día del lanzamiento para los jugadores que usan determinadas GPU o pantallas de móvil. El juego nunca estuvo defectuoso. Simplemente nunca se encontró con el hardware que tus jugadores usan de verdad.