Pruebas de regresión y retest: no es lo mismo

Posted on 26/01/2015 by Guillermo Villarrubia Esteban

Toda  persona  familiarizada  con  el  mundo  de  las  pruebas  ha  oído
hablar alguna vez de las pruebas de regresión y retest. Si bien son
términos  muy  parecidos  que  tienden  a  confundirse,  resulta  muy
beneficioso  tener  muy  presente  qué  significa  cada  uno  de  ellos  y,
sobretodo, saber cómo aplicarlos y en qué momento.

La  terminología  utilizada  en  testing  está  basada  en  conceptos  a

simple  vista  no  muy  complejos  pero  llenos  de  contenido.  Estos
conceptos, al parecer llenos de sentido común, son muchas veces
menospreciados  y  poco  estudiados.  Y  eso  es  un  error.  Es  mucho
más recomendable comprender los conceptos y sus diferencias.

El objetivo de las pruebas siempre es doble. En primer lugar verificar que el software es correcto y, en caso
de no ser así, descubrir los posibles bugs. En ese proceso las pruebas son ejecutadas una y otra vez. Las
pruebas de regresión y retest están relacionadas con el concepto de ejecutar una y otra vez las pruebas.
Una prueba es ejecutada más de una vez.

Retest: descubriendo y resolviendo bugs
Cuando  una  prueba  no  produce  el  resultado  esperado  (condición  de  salida)  se  produce  un  bug.  Éste,
evidentemente, tiene que ser solucionado por el equipo de desarrollo. Una vez resuelto, las pruebas tienen
que ser ejecutadas de nuevo para comprobar que el bug ha sido resuelto. Eso es precisamente el  retest:
volver a ejecutar las pruebas para verificar que los bugs han sido resueltos. El retest forma parte de la
solución de los bugs descubiertos.

No obstante el proceso de retest no debe ser ejecutado sin control. Es necesario registrar información de
cada  una  de  los  intentos  de  reparar  el  bug  (puede  que  haya  varios).  De  cada  bug  que  se  levanta  es
recomendable recoger la siguiente información de cada intento de remediación:

Tiempo de resolución: tiempo transcurrido desde que se descubrió el bug hasta que fue entregado para
realizar el retest de verificación (con el tiempo del retest incluido).
Número de intentos: número de iteraciones para la resolución de un bug.

Con esta información es posible calcular tiempos medios, máximos, mínimos y número medio de
iteraciones para resolver bugs. El estudio de estos datos ofrecerá datos de cuánto cuesta arreglar un bug o
cual es el tiempo mínimo de reparación.

Regresión: comprobando que el software sigue funcionando
Cuando  se  resuelve  un  bug  (o  se  añade  más  funcionalidad  en  un  mantenimiento  evolutivo)  se  está
modificando  el  código;  y  esto  tiene  un  riesgo.  El  riesgo  es  evidente:  que  deje  de  funcionar  algo  que
previamente lo hacía. Por ese motivo existen las pruebas de regresión. Son un conjunto de pruebas que
buscan verificar si ciertas funcionalidades del sistema siguen intactas después de haber aplicado un
cambio en el software.

Evidentemente  realizar  una  regresión  es  costoso.  Por  ese  motivo  se  insiste  en  automatizar  el  mayor
número  de  pruebas.  Cuanto  más  automaticemos  menos  esfuerzo  costará  realizar  la  regresión  de  las
funcionalidades y más seguros estaremos de cada cambio que se acometa en el software.

El conjunto de pruebas de regresión no está formado por todas las pruebas del sistema. Es un subconjunto.
Evidentemente cuanto mayor número de pruebas automáticas tengamos más pruebas podemos incluir en
nuestro conjunto de pruebas de regresión y, en consecuencia, aumentar la fiabilidad del cambio acometido;
todo esta relacionado.
Después de la entrega de cada una de las releases de nuestro producto (en la retrospectiva de un spring,
por  ejemplo,  si  se  sigue  la  metodología  scrum)  hay  que  revisar  el  conjunto  de  pruebas  de  regresión,
aumentarlo o sustituir ciertas pruebas por otras nuevas correspondientes a las nuevas funcionalidades que
forman parte del producto.

Pruebas de regresión y retest en las estimaciones
Las pruebas de regresión y retest con sus tiempos y esfuerzo deben tenerse en cuenta en las
estimaciones. Saber exactamente qué tiempo lleva la regresión, sobretodo si están automatizadas y el
tiempo es más o menos fijo, será muy útil a la hora de establecer el tiempo mínimo para realizar un
despliegue. Esto es muy necesario para establecer la duración mínima de una iteración.

Los resultados de los tiempos y esfuerzos del retest servirán para poder estimar cuando estarán resueltos
nuevos bugs del mismo tipo, entre otras cosas. Pero para estimar tanto despliegues como soluciones es
necesario medir. Evidentemente cualquier estimación depende siempre del equipo.