Pruebas de regresión, tu tipo de prueba

¿Te ha sucedido que con la liberación de una nueva versión de tu aplicación favorita alguna funcionalidad ha desaparecido? ¿O funciona pero con un comportamiento inesperado? ¿O simplemente casca de manera estrepitosa? 

Hoy veremos cuáles son las posibles pruebas que garantizan evitar todo este panorama, las pruebas de regresión.

¿Todavía no sabes qué son las pruebas de regresión?

Existen muchas normas para realizar las pruebas de software y tal vez te sorprendas al decirte que incluso existe el trabajo de documentación de las pruebas de software. 

*Dejo aquí unos segundos de intervalo para que te sorprendas.

Y no sólo eso, amigo, hay organismos internacionales que se dedican a estudiar y realizar recomendaciones generales. 

*Por ejemplo, las normas ISO/IEC 29119 plantean, grosso modo, lo que deberían ser los procesos de prueba de software. 

Desde hace varias décadas me fascinan todos estos procesos, incluída la monitorización de dispositivos industriales, hasta tal punto les soy fiel que siempre me acaban tachando de perfeccionista, ¡a mí…! 

¡Te recuerdo que el diseño y construcción de una maquinaria cualquiera, aún hoy día, es realizada por seres humanos cuyas vidas dependen del correcto funcionamiento de éstos!

Automóviles, aparatos de aire acondicionado, centrales eléctricas que enfrían hogares en ardientes veranos…

Por esa razón las pruebas de software han de ser adaptadas al trabajo en sí mismo que realizarán dichos programas:

• ¿Un programa para pilotar automáticamente un avión? Ten por seguro que será sometido a pruebas muy exhaustivas.
• ¿Un software bancario? Será probado y tendrá un apartado especial para las pruebas del software de auditoría correspondiente.
• ¿Un software de videojuego? Nadie morirá si algo sale mal, si acaso los jugadores comprarán el juego de la competencia, pero ¿Quién quiere eso, compi gamer?

Por eso aquí mismo me gustaría explicarte, de la manera más sencilla posible, de qué van estos procesos y pruebas.

Pruebas unitarias, reaprobación y reanálisis

Rápidamente veamos unos conceptos claves:

• Pruebas unitarias: 

A diferencia del siglo pasado tenemos una mejor oferta de hardware, el cual permite realizar pruebas automatizadas, completas y rápidas, que se pueden reutilizar una y otra vez (y que se ejecutan de manera independiente) para el código fuente en sí mismo. 

Una coma, un par de paréntesis podrán estar mal o bien colocados dependiendo de la versión del lenguaje de programación utilizado (por ejemplo, véase en lenguaje Python el comando print). Para esto se realizan las pruebas unitarias.

• Proceso de reaprobación: 

Cuando un software es modificado, cualquiera que sea la razón, se han de reaprobar todos y cada uno de los puntos que hayan sido trabajados. 

Dichas pruebas son siempre hechas de manera manual.

• Proceso de reanálisis: 

Si el punto anterior resulta suspendido, el software se devolverá al departamento de desarrollo especificando cuáles son sus disfuncionalidades. 

Una vez hayan sido corregidas y entregadas serán reanalizadas y, si todo va bien, pues serán reaprobadas.

¡Basta de preámbulos! ¿Qué es una prueba de regresión?

Las pruebas de regresión son totalmente diferentes a las pruebas anteriores. 

Se denominan de esta manera porque parten del principio de que si un software funciona como se espera, y es alterado ya sea de manera interna o externa, pues hay que cerciorarse de que regresa a su condición de estabilidad anterior.

*Cuando decimos que un software es estable y funciona como fue diseñado, estamos hablando de todo como un conjunto, de manera general. 

Por ello, una prueba de regresión se ha de aplicar a todos y cada uno de los componentes. 

Como puedes imaginar, esta es una tarea titánica, pero, si es bien realizada, ayudará a mejorar la experiencia del usuario y ganará la confianza del cliente.

¿Cuándo realizar una prueba de regresión?

Cuando a un software se le agrega una característica nueva, realizadas las pruebas de reaprobación y reanálisis, se debe realizar una prueba de regresión antes de entregar al cliente. 

Y también cuando:

• El requisito cambia o fue mal entendido por los desarrolladores y entonces una funcionalidad ha de ser «reparada».
• El software ha pasado por una prueba de regresión, es entregado y funciona muy bien hasta que algo cambia. *Por ejemplo, el usuario ha actualizado el sistema operativo o ha migrado a una versión más reciente: el programa sufre un fallo que ha de ser subsanado.
• El software hace su trabajo pero con el paso del tiempo se acumulan datos y tarda más y más tiempo en ejecutar las mismas tareas. Se requiere entonces una optimización del código fuente y todo el ciclo de pruebas se repite de nuevo.
• Dependiendo de cada país existirán nuevas legislaciones y el software habrá de cumplir con las medidas legales. En este caso el software se rehace y una prueba de regresión será necesaria antes de ser legalizado de nuevo.
• Necesitamos migrar el software a otro sistema operativo distinto (por ejemplo de GNU/Linux® a MS Windows®) para poder venderlo a más clientes. Aquí las mismas pruebas de regresión serán también copiadas y adaptadas al nuevo entorno.

Algunas desventajas de este tipo de test de regresión

No todo es «miel sobre hojuelas»:

• El más mínimo cambio ha de ser probado en una prueba de regresión. 

Incluso sin haberse producido cambio alguno en el código fuente del software. 

• Tal como funciona la monitorización, habrá funcionalidades sencillas y algunas más complejas, lo cual puede ser un problema si tenemos límite de tiempo. 

Por ejemplo, monitorizar una página web puede tardar milisegundos si se trata de hacer un ping u obtener un valor conciso, pero en el caso de la monitorización de experiencia de usuario habrá de registrar cada una de las pruebas a realizar.

• Una vez hayamos automatizado las pruebas de regresión cabe la posibilidad de que haya de realizar una prueba manual, esto ocasionará más gasto tanto de tiempo como de dinero.

Recursos

Librería de plugins Pandora FMS

Foro oficial Pandora FMS

Quiero saber MaaS

Nuestro Trial