Automatización de pruebas funcionales
Test de Regresión
Las pruebas de regresión son un subconjunto de las pruebas planificadas que se seleccionan para ejecutar periódicamente, por ejemplo ante cada nueva liberación del producto. Tienen el objetivo de verificar que el producto no ha sufrido regresiones.
Podemos decir que hay dos cosas a las que el test automatizado le agrega valor:
- Business value: Da valor al negocio mejorando la calidad, evitando problemas de operativa, pérdida de imagen de clientes e incluso evitando problemas legales.
- IT value: Mejora el trabajo del grupo de IT ya que le simplifica las tareas rutinarias, permitiendo que con el mismo costo hagan mucho más y mejor.
Ventajas:
- Mejora la calidad, pues hay menos errores humanos.
- Mejora la performance de producción, pues con las mismas personas se puede lograr mucho más trabajo, a mayor velocidad y escala, y en ese sentido mejoran el rendimiento de las personas.
Las aplicaciones en las que más conviene usar testing automatizado son las que en algún sentido tienen mucha repetitividad, ya que será necesario ejecutar muchas veces las pruebas (ya sea porque es un producto que tendrá muchas versiones, que se continúe con el mantenimiento haciendo fixes y parches, o porque se debe probar en distintas plataformas).
Principios Básicos de la Automatización de Pruebas
- Paradigmas de automatización
- SCRIPTING
- RECORD AND PLAYBACK
- MODEL BASED TESTING / MODEL DRIVEN TESTING
- Diseño de pruebas según objetivos
- Priorización: decidir qué y cuándo automatizar
Diseño de Suites de Prueba
Generalmente todas las herramientas nos permiten agrupar los casos de prueba, de manera de tenerlos organizados, y ejecutarlos en conjunto. La organización la podemos definir por distintos criterios, dentro de los cuales podemos considerar:
- Módulo o Funcionalidad: agrupando todos los casos de prueba que actúan sobre una misma funcionalidad.
- Criticidad: podríamos definir un grupo de pruebas que se debe ejecutar siempre (en cada build), ya que son las más críticas, otro de nivel medio, que lo ejecutamos con menos frecuencia (o tal vez que se seleccionan solo si hay cambios en determinadas funcionalidades), y uno de poca criticidad, que ejecutaríamos opcionalmente si contamos con tiempo para hacerlo (o cuando cerramos un ciclo de desarrollo y queremos ejecutar todas las pruebas disponibles).
Nomenclatura
Es importante definir una nomenclatura de casos de prueba y carpetas (o lo que brinde la herramienta de automatización para organizar las pruebas).
Automatización
En cuanto a la automatización, algunas de las tareas a planificar son las que se ven a continuación:
- Automatización
- Mantenimiento
- Ejecuciones
- Verificación y reporte de bugs
- Correcciones de bugs detectados
Probando en busca de falsos negativos
Si el software está sano y no queremos que se muestren errores, debemos asegurarnos que la prueba está probando lo que quiere probar, y esto implica verificar las condiciones iniciales tanto como las finales.
Probando en busca de falsos positivos
Si el software está enfermo, ¡la prueba debe fallar! Una posible forma de detectar los falsos negativos es insertar errores al software y verificar que el caso de prueba encuentre la falla.
Pruebas de sistemas que interactúan con sistemas externos
Las herramientas de automatización (al menos las que nos estamos enfocando aquí) tienen como objetivo reproducir la interacción del usuario con el sistema, por lo tanto estas complejidades de fondo son casi indiferentes. Una vez que el usuario presiona un botón, la lógica que se ejecuta a partir de esa acción pude ser simple o compleja, pero a la vista de la herramienta eso está oculto (tan oculto como lo está a la vista del usuario), lo que importa para automatizar es la interfaz de usuario en este caso.
Ejecución de Pruebas Automáticas
Tenemos que considerar muchos elementos que son parte del ambiente:
- Los fuentes y ejecutables de la aplicación bajo pruebas.
- Los artefactos de prueba y los datos que estos usan.
- A su vez los datos están relacionados con la base de datos del sistema bajo pruebas, con lo que tendremos que gestionar el esquema y los datos de la base de datos que se corresponden con el entorno de pruebas
Si un reporte me dice que hubo un fallo, lo primero es determinar si el fallo se debió a los Test Cases. Hay que asegurarse que la culpa no es del test antes de reportar un bug (error) a un desarrollador.
ter Dictionary. Software Engineering Terms. 1990).
