Pruebas de regresión

El término pruebas de regresión es un término común usado frecuentemente en la industria del software, no solo por QA, sino por desarrolladores, gerentes de proyecto, incluso clientes, este término es a veces confundido por algunas personas y por eso hoy voy a darles mi visión de lo que para mí son las pruebas de regresión.

Primero que todo, cada proyecto debe tener una o más fases de pruebas de regresión, a mi modo de verlo, antes de cada entregable al cliente, QA debe ejecutar pruebas de regresión para asegurar que lo que se entrega está bien y que otras áreas del sistema que ya fueron probadas antes no se vean afectadas por los múltiples cambios, actualizaciones y nuevas funcionalidades agregadas, este tipo de pruebas también deben hacerse antes de cada actualizaión o cambios en el ambiente de producción.

Las pruebas de regresión son un tipo de pruebas en donde se confirma y se verifica que el sistema funciona correctamente con nuevas funcionalidades agregadas y que las anteriores también están bien y funcionan perfectamente sin errores, habiendo dicho esto, una prueba de regresión requiere probar todo el sistema, todas las páginas, todos los modulos, toda la funcionalidad, servicios y demás en todos los navegadores, dispositivos móviles y sistemas operativos incluidos en el plan de pruebas y alcance inicial, yo sé que toma mucho tiempo, pero se debe asegurar que toda la funcionalidad se comporta correctamente en cada dispositivo.

Ahora bien, hay muchas técnicas a usar al momento de ejecutar las pruebas de regresión, por supuesto, esto varía dependiendo de la experiencia y la forma en la cual cada QA hace sus cosas, se puede probar todo el sistema y dividir el sistema en módulos y pasar por ellos uno por uno, se pueden priorizar las áreas más importantes y luego probar las otras al terminar y la otra técnica es solo probar algunas áreas o módulos, personalmente no me gusta la última técnica, para mí, todas las funcionalidades, áreas y módulos del sistema se deben probar, por supuesto, esto también depende del tiempo que se tiene y del requerimiento del cliente.

Se puede hacer un informe de progreso de la regresión de muchas formas: Google docs, Excel, alguna herramienta de adminstración de casos de prueba o mapas mentales, lo que importa aquí es que todas las áreas del sistema tengan sus bugs creados (ojalá no hayan) y que el estado de cada área diga si la funcionalidad probada pasó o falló, esto  también da visibilidad del porcentaje de pruebas finalizadas y probadas por parte de QA. También es importante y obvio (a veces no es obvio) decir que el tiempo que toman las pruebas de regresión debe ser estimado por el equipo de QA, no por el líder técnico o por algún otro miembro del equipo o del proyecto, QA estima su trabajo y el tiempo que se demora en acabar la regresión, entre más pronto mejor,  hay que intentar cumplir los objetivos y completar las tareas pendientes en el tiempo correcto. Otro punto importante a resaltar, es que los desarrolladores no deben esperar a que QA termine las pruebas, sino que pueden empezar a resolver bugs mientras tanto y después actualizar el ambiente y servidor de pruebas para que QA pruebe. Si me lo preguntan a mi, dependiendo del bug, QA puede parar la regresión, confirmar si el bug fue arreglado en el ambiente de pruebas y después continuar con la regresión. El tiempo y el progreso son temas claves en metodologías ágiles.

Las pruebas de regresión son las pruebas más robustas, que consumen tiempo y las más grandes que ocurren durante el desarrollo del proyecto, por supuesto, se puede ahorrar tiempo corriendo pruebas automatizadas, pero igual las pruebas visuales y las diferentes configuraciones (si se trabaja con un administrador de contenidos o CMS) toman tiempo de probar a fondo para asegurar que todo lo que se va a entregar funciona bien. No hay que olvidar que QA es el encargado de hacer cumplir el proceso y las pruebas, pero la calidad del proyecto depende de todos los miembros del equipo.


@LuchoAgileQA