Diferencias I: Regresion vs Retesting

Jenkins, Nick. A Software Testing Primer: An Introduction to Software Testing. En http://www.softwaretestinghelp.com/ (en línea). 2008. Disponible en Internet: http://www.nickjenkins.net/prose/testingPrimer.pdf. Traducción: Ezequiel Silva. Uno debe retestear las correcciones para asegurarse que el problema se haya resuelto antes de que se continúe con el desarrollo. De esta manera, retestear es el acto de repetir el test para verificar que un defecto que encontramos haya sido correctamente resuelto. Por otro lado, el Testing de Regresión es el acto de repetir las pruebas sobre los diferentes módulos de la aplicación, para asegurarse que la solución aplicada o el cambio en el código no hayan producido otros errores y/o comportamientos inesperados. Por ejemplo, si un error se detecta en una rutina particular que maneja archivos, esto puede ser corregido por un simple cambio en el código. Sin embargo, si ese código es utilizado en un número diferente de lugares a través del software, el efecto de tal cambio puede ser difícil de predecir. Lo que aparece como un detalle menor, puede afectar a módulos separados de código en cualquier parte del programa. Un bug corregido puede, de cierta manera, crear nuevos bugs en otros lugares. Pueden sorprenderse al enterarse de cuan común es esto en realidad. En estudios específicos se ha estimado que más del 50% de los bugs corregidos introducen nuevos errores en el código. Dado esto, es muy raro que cualquier proyecto se entregue en su debido tiempo. Mejores procesos de Aseguramiento de Calidad podrían reducir este ratio de tiempo, pero nunca lo eliminarían. Los programadores se arriesgan a introducir nuevo código cada vez que ellos apoyan sus manos en el teclado. Un inadvertido resbalón hacia una tecla que reemplace un punto por una coma puede no ser detectado por semanas pero, seguramente, traerá aparejados serios problemas. El test de regresión tiende a mitigar este problema evaluando el "área de impacto" afectada por el cambio o la corrección del Bug, para ver si tiene consecuencias no deseadas. Verifica el comportamiento conocido después de un cambio. Nota: es muy común que el test de regresión cubra TODO el producto o el software en prueba. ¿Por qué? Porque los programadores son notoriamente malos para seguir y llevar el control de los cambios en su software. Cuando ellos arreglan un problema, causan otros. Generalmente no tienen idea del impacto que pueden producir, ni tampoco pueden fiarse de volver atrás sus cambios. Si los desarrolladores pudieran, con algún cierto tipo de certeza, especificar el alcance exacto y los efectos de algún cambio que hagan, entonces el testing podría limitarse solo a la zona afectada. ¡¡¡Ay, pobre de aquel tester que haga esta suposición!!!