menu_superior

Automatización de Pruebas (II): el Cuándo

Este post forma parte de una serie sobre automatización de pruebas. Puedes acceder aquí a la primera parte.

En la primera parte de esta serie he hablado de una manera que puede parecer negativa sobre la automatización. Mi intención no es remarcar los aspectos negativos si no poner sobre la mesa los sacrificios y las implicaciones que tiene emprender el camino de la automatización de pruebas.  Hay toda una serie de ventajas derivadas de automatizar la ejecución de casos de prueba siempre que sepamos analizar el contexto, valorar el balance coste-beneficio y aplicar un criterio que realmente convierta las pruebas automáticas en algo que genere valor. A continuación os doy varios ejemplos atendiendo a la tipología de las pruebas:

  • pruebas de regresión. Este tipo de pruebas se hacen antes que el mantenimiento salga a producción y su objetivo es verificar que los cambios que se han hecho no han afectado negativamente a las partes no modificadas, es decir, las pruebas de regresión se hacen para evitar evitar efectos colaterales cuando hay cambios en el software.
  • funcionalidad mínima garantizada. Siempre que hay un mantenimiento (correctivo o evolutivo) el aplicativo tiene que superar un conjunto de pruebas antes de salir a producción. Estas pruebas afectan a un conjunto reducido de funcionalidades, generalmente las más importantes y aseguran que ni el proceso de puesta en producción ni los cambios introducidos han afectado a las funcionalidades más importantes. Hay un matiz que las hace diferentes de las pruebas de regresión: afectan no tanto a la integridad del sistema como a la asegurarme que mis funcionalidades clave están disponibles.
  • pruebas de sonda. Este tipo de pruebas se hacen con la aplicación funcionando en producción y tienen como objetivo obtener información sobre el rendimiento del sistema, la continuidad del servicio, el retardo de la red, la saturación de los servidores, etc… Me explico con un ejemplo: tienes un sistema que no tiene mucha carga de trabajo pero que es crítico, por lo tanto es vital que no haya caídas y “controlar” que este siempre disponible.  No es una prueba funcional propiamente dicha, ni de rendimiento por que no hay carga, simplemente se trata de diseñar un plan de pruebas ligerito que se ejecute en intervalos pequeños (un minuto, 5 minutos, etc) y que no provoque cambios en el sistema (una consulta, logarse y deslogarse, etc).
  • pruebas de fin de fase, de liberación de componentes, unitarias, y, en general, todas aquellas que se hacen de manera periódica, repetitiva y que van destinadas no tanto a encontrar defectos si no a asegurar un funcionamiento… Hay una regla general que podemos aplicar a casi cualquier contexto: si vas a ejecutar un caso de prueba más 7 veces es interesante considerar automatizar su ejecución. Lo de las 7 veces es un poco arbitrario, en realidad la idea es que haya un número suficientemente elevado que justifique su ejecución.

Hay un hilo conductor en los casos que acabo de poner como ejemplo, dos características que quiero destacar una vez más y que determinan la decisión de llevar a cabo la automatización:

  1. número de veces que se va a ejecutar el caso de prueba. Esto es evidente y se ve a primera vista, no puedo justificar la inversión en algo que no voy a utilizar un número de veces mínimo como para amortizar lo que me ha costado.
  2. las pruebas automáticas no encuentran defectos. Hay que partir de funcionalidades que hemos probado a mano y cuyo funcionamiento es satisfactorio. La idea es detectar cuando un cambio que no está relacionado puede interferir en esa funcionalidad.

Espero que con la lectura de este post tengáis más claro qué criterio podéis seguir a la hora de tomar la decisión de automatizar vuestros casos de prueba. Por favor, considerad los comentarios abiertos a sugerencias, recordatorios, opiniones y dudas.

Puedes continuar leyendo las siguientes entradas sobre automatización de pruebas: Cómo Automatizar y un caso de éxito.

, , , , , , , ,