sábado, 17 de septiembre de 2011

Automatización de Pruebas: Creencias Erroneas

1  La Automatización de Pruebas

Dentro del Testing de Software, la automatización de pruebas es una de las actividades que presentan una mayor expectativa. La posibilidad de ejecutar las pruebas de software de manera desatendida, hace que las organizaciones vuelquen sus esperanzas en la automatización como la solución ideal para abaratar los costes y acortar los tiempos de pruebas.


2  Creencias erróneas sobre la Automatización.

Las esperanzas puestas en la Automatización de Pruebas se deben generalmente a puntos de partida erróneos, que hacen que se espere de ella expectativas que no proporcionarán:

  • Error 1: La automatización de pruebas es una actividad fácil de poner en marcha.

La automatización de pruebas no es una actividad fácil de implementar. Necesita de una herramienta de automatización que soporte las diferentes tecnologías, personal con conocimientos, una metodología de trabajo adecuada y de recursos hardware.

  • Error 2: Los casos automáticos  se ejecutan más rápido que de forma manual.

Los casos automatizados no se ejecutan más rápidamente que de manera manual. La ejecución de un mismo caso de prueba puede ocupar mayor tiempo que de manera automática. Esto no significa un menor rendimiento ya que el verdadero potencial de la automatización se encuentra en que la ejecución de casos se realiza de manera desatendida, con disponibilidad 24x7, se ejecuta de manera paralela a las actividades manuales y permite destinar el tiempo manual de pruebas a tareas de mayor valor (pruebas de evolutivos, pruebas no funcionales, etc...)

  • Error 3: La automatización de pruebas es una “grabación” de pasos en un script.

Automatizar un caso de prueba no es únicamente "grabar". Un caso de prueba automatizado debe ser robusto y fiable. Para ello es necesario introducir en los casos de prueba elementos de control como son: validaciones de correcto funcionamiento, control de flujo y sentencias de reporting que prolongan el tiempo de construcción de los casos de prueba.

  • Error 4: Empezar a automatizar en fases tempranas del desarrollo de la aplicación.

La automatización se debe llevar a cabo una vez que las funcionalidades de nuestra aplicación se encuentran estables e implementadas de una manera definitiva. Comenzar a automatizar antes, significaría que nuestros casos automáticos cambien de manera continua, provocando constantes fallos en la automatización y requiriendo destinar tiempo al mantenimiento de los scripts.

  • Error 5: Todos los casos de prueba son automatizables.

No es posible automatizar cualquier caso de prueba. Casos de prueba que requieran actuaciones manuales o tomas de decisión complejas no son automatizables.

  • Error 6: Buscar rentabilidad a corto plazo.

La automatización es una inversión a medio plazo. A corto plazo significa una inversión en creación de un “parque” de casos de prueba, en herramientas, y en la infraestructura que soporte las tareas asociadas a la automatización.

  • Error 7: Automatizar casos con corta “esperanza de vida”

No se deben automatizar casos de prueba cuyo número de reejeuciones va a ser pequeño. La automatización de un caso de prueba comienza a ser rentable cuando el tiempo destinado a la automatización, es inferior al tiempo ahorrado en ejecutar ese caso de manera manual.

  • Error 8: Los casos automáticos detectan más “bugs”.

La automatización de un caso de prueba no detecta errores. Es la definición del caso de prueba el que permite la detección de errores o defectos, es decir, que el mero hecho de automatizar un caso no significa que se vayan a detectar más errores de los que se detectarían ejecutándolo de manera manual.


    2 comentarios:

    1. Excelente exposición.

      mi modesta contribución:

      El procedimiento de la automatización no es independiente de la herramienta que lo implementa.

      Debe serlo, la herramienta debe aportar soporte nunca dirigir, definir, imponer la estrategia a seguir en la automatizacion de un caso de prueba.

      ResponderEliminar
    2. Tienes toda la razón. La herramienta en muchos casos dirige el procedimiento de automatización: modularación de scripts, el "paso" de parámetros, etc...

      Lo ideal sería disponer de una metodología de automatización independiente de la herramienta.

      Muchas gracias por tu aportación.

      ResponderEliminar