¿Les ha sucedido que con la liberación de una nueva versión de su 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.
Aclaratoria
Existen muchas normas para realizar las pruebas de software y tal vez se sorprenderán al decirles que incluso existe el trabajo de documentación de las pruebas de software. Organismos internacionales que se dedican a estudiar y realizar recomendaciones generales son un muy buen punto de inicio: por ejemplo las normas ISO/IEC 29119 (cinco grandes capítulos) plantean de manera general (y hasta somera en mi opinión) lo que deberían ser los procesos de prueba de software. En todo caso las intenciones que impulsan dicha normativa son sumamente buenas.
Hace varias décadas yo estudiaba ingeniería mecánica y todavía me fascinan todos los procesos industriales, incluída la monitorización de dispositivos industriales. Siempre me tachan de perfeccionista pero recordemos que el diseño y construcción de una maquinaria cualquiera, aún hoy en día, es realizada por seres humanos cuyas vidas dependen de su correcto funcionamiento (automóviles, aparatos de aire acondicionado, centrales eléctricas que enfrían hogares en ardientes veranos, etcétera).
Por esa razón las pruebas de software han de ser adaptadas al trabajo en sí mismo que realizará dicho programa:
- ¿Un programa para pilotar automáticamente un avión? Ténganlo por seguro que será sometido a pruebas muy exhaustivas.
- ¿Un software bancario? Será probado de menor manera y de seguro tendrá un apartado especial para las pruebas del software de auditoría correspondiente.
- ¿Un software de juego? Nadie morirá si algo sale mal, si acaso sucederá que los jugadores probablemente comprarán el juego de la competencia.
Acá explicaré de la manera más sencilla posible, simplificando al máximo, los procesos y pruebas.
Pruebas unitarias, reaprobación y reanálisis
Rápidamente veamos unos conceptos claves:
- Pruebas unitarias: a diferencia del siglo pasado, que me tocó vivir en carne propia, 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 la versión del lenguaje de programación utilizado (por ejemplo, véase en lenguaje Python el comando
print): para esto se realizan la pruebas unitarias. - Proceso de reaprobación: cuando un software es modificado, cualquiera sea la razón, se ha de reaprobar (o reprobar) todos y cada uno de los puntos que hayan sido trabajados. Dichas pruebas son siempre hechas de manera manual ya que el trabajo es muy pequeño o poco.
- Proceso de reanálisis: si del punto anterior resultare reprobado, se devolverá al departamento de desarrollo especificando cual o cuales son sus disfuncionalidades. Una vez hayan sido corregidas y entregadas serán reanalizadas y si todo va bien pues serán reaprobadas.
¿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 que 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 podrán 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 (y sí, estoy hablando de dinero).
¿Cuándo realizar una prueba de regresión?
Evidentemente que cuando a un software se le agrega una característica nueva, realizadas las pruebas de reaprobación (y reanálisis) respectivos, de se debe realizar una prueba de regresión antes de entregar al cliente (generalmente acompañado de una nueva numeración de versión). Pero esperad, aún hay más:
- Algunas veces el requisito cambia (o fue mal entendida 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 o reino habrán nuevas legislaciones y el software ha de cumplir con los extremos de ley. En este caso el software se refacciona y una prueba de regresión será necesaria antes de ser legalizado de nuevo.
- Aunque es una razón más que obvia pues igual la menciono: necesitamos portar 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.
Desventajas
No todo es «miel sobre hojuelas»:
- El más mínimo cambio ha de ser probado en una prueba de regresión. Es más, incluso sin haberse producido cambio alguno en el código fuente del software: si estamos en el mes de diciembre yo recomiendo hacer pruebas de regresión con la fecha del año siguiente y asegurarse de que todo vaya bien.
- Tal como es la monitorización, habrán 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 la 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 (en el caso del software aeronáutico esto es inevitable).