Metodologías Pruebas estructuradas

Regresión y Agilismo

En el ciclo de vida del desarrollo software existen muchas maneras de categorizar los tipos de pruebas. Una de estas categorizaciones y en la que vamos centrarnos en analizar hoy, es la de la naturaleza del desarrollo del cambio del software. Desde este punto de vista podemos diferenciar dos tipos:

  • Pruebas de progresión: Son aquellas cuyo objetivo es comprobar que la nueva funcionalidad o la adaptación de la ya existente funciona correctamente tras el desarrollo.
  • Pruebas de regresión: Son aquellas pruebas que tienen como objetivo verificar que las partes de un sistema que no han sufrido modificaciones directas siguen funcionando correctamente tras la implementación de un cambio.

En un mundo cada vez más orientado a conceptos como el agilísimo, la integración continua o la automatización es, en principio, donde este tipo de pruebas encajarían de una manera más natural; puesto que como hemos mencionado anteriormente, estas pruebas tienen como objetivo verificar que las partes de un sistema que están consolidadas y, supuestamente, sin errores siguen funcionando de manera de correcta.

¿Por qué encajan con las metodologías ágiles?

  • Los principios fundamentales del agilísimo son que sea iterativo e incremental. ¿Qué quiere decir esto? Que el cliente obtenga de una manera continuada software que aporte valor prácticamente desde el minuto uno. Es por eso que, la cantidad de cambios en el código, es bastante grande y hay que tener una batería de pruebas amplia de la funcionalidad consolidada en la que ante estos cambios se pueda asegurar el correcto funcionamiento de la aplicación.

¿Y por qué con la automatización?

  • Al ser una funcionalidad consolidada y en principio sin errores merece la pena invertir recursos en automatizar estas pruebas puesto que como hemos ido mencionando se deberán ejecutar de manera reiterada tras cada iteración. En este sentido tendríamos que tener en cuenta dos cosas, la primera que estas pruebas son un ente vivo y que por tanto requieren de un mantenimiento para adaptarse a los nuevos cambios introducidos, y por otro lado la necesidad de conocer una metodología de testing para poder establecer estrategias que aporten valor al cliente desde el punto de vista de la calidad y de minimizar riesgos ya que hay ciertos casos concretos en los que la automatización no puede ser lo más eficiente, atendiendo a las peculiaridades de cada organización.  En esta línea, una prueba automática que no está bien mantenida, con el tiempo  tiende a distorsionarse e ir perdiendo su objetivo principal, que es lo que se conocen como Flaky Test.

Para tener un ejemplo gráfico de este tipo de pruebas, podríamos imaginar cualquier web que para el uso de su área privada o de cliente, requiere de un usuario y contraseña. Si desde la parte de negocio de dicha organización se quiere introducir un nuevo desarrollo para acceder a esta área privada mediante la huella dactilar para que conviva con el método de acceso tradicional, las pruebas de regresión serían las encargadas de verificar que el acceso tradicional con usuario y contraseña sigue llevándose a cabo con eficiencia, tras la implementación de la nueva funcionalidad.

Además de este análisis funcional se debería hacer un análisis técnico de impacto para ver qué otros módulos podrían verse afectados por el cambio, para de la misma manera, sobre ellos efectuar también pruebas de regresión.

Las pruebas de regresión son  por tanto, una parte fundamental, a la hora de establecer la estrategia de pruebas para el aseguramiento de la calidad de cualquier aplicación.

3 comments on “Regresión y Agilismo

  1. Buenos días Pablo, lo primero agradecerte tus palabras y el interés mostrado por el artículo.

    En cuanto a tu pregunta, la respuesta es afirmativa, se ha implementado un cambio, pero lo que probamos en las pruebas de regresión no es que ese cambio funcione como se espera, si no que el resto de la aplicación que en principio no se ha “tocado” siga funcionando correctamente.

    Por tanto “modificación directa” haría referencia a la funcionalildad nueva que se implemente, bien sea, un nuevo desarrollo, un evolutivo de la ya existente o la correción de un error, pero como hemos dicho, indirectamente otras partes de la aplicación pueden haber sufrido modificaciones (de manera indirecta), que no estén controladas y que por tanto pudiesen estar fallando. Espero que te haya sido de ayuda la aclaración. Un saludo

    Me gusta

  2. Hola, felicitaciones por articulo.
    Me queda una duda en la definicion de pruebas de regresión. Dice “un sistema que no han sufrido modificaciones directas siguen funcionando correctamente tras la implementación de un cambio.” se ha cambiado algo o no?
    que son las modificaciones directas ?
    Saludos y gracias

    Le gusta a 1 persona

  3. Pablo Videla

    Hola, muy interesante tu articulo. Me queda una duda en la definición de pruebas de regresión. Dice:”un sistema que no han sufrido modificaciones directas siguen funcionando correctamente tras la implementación de un cambio”. Se ha cambiado algo o no?
    Modificacion directa seria la diferencia?
    Saludos

    Le gusta a 1 persona

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: