Las pruebas funcionales que se lanzan contra la interfaz gráfica de usuario, históricamente, han sido una de las áreas que más se ha intentado automatizar. A lo largo de la historia de esta parte de la automatización de pruebas, llena emociones, penas y alegrías, podemos encontrar numerosos enfoques y estrategias, fruto de cómo ha ido evolucionando a lo largo del tiempo esta área de la calidad software, siempre intentando ahorrar tiempo… y que “no sea peor el remedio que la enfermedad”.
Allá por el 2012, David Hunt, en su artículo “Software test on demand – A smarter way”, propuso una clasificación de los enfoques de automatización de pruebas funcionales en generaciones. Y hasta la fecha, podemos distinguir 5 generaciones de estrategias de automatización de pruebas funcionales que se lanzan contra una interfaz gráfica de usuario, que son las siguientes: grabar – reproducir, scripting, data-driven scripts, keywords y scriptless.
Generación 1: Grabar y reproducir (Record and playback)
Las primeras herramientas de automatización de pruebas funcionales empleaban este enfoque: grabar los casos de prueba a partir de las interacciones del tester con la interfaz gráfica de la propia aplicación a probar. Después, las herramientas permiten reproducir esos casos de prueba. A partir de esas acciones grabadas, la propia herramienta genera código (los llamados scripts) para volver a ejecutar los casos de prueba.
Como puntos negativos de este primer enfoque podemos destacar, por un lado, que cada caso de prueba automatizado incluye tanto las acciones a realizar como los datos de prueba, dificultando la reutilización del caso de prueba y reduciendo su mantenibilidad. Si queremos automatizar otro caso de prueba parecido pero con distintos datos de entrada, deberemos crear un caso nuevo.
Por otro lado, muchas herramientas que siguen este enfoque se basan en identificadores o etiquetas de los elementos de la interfaz gráfica. Si por ejemplo hemos automatizado una serie de casos de prueba de una aplicación, y el nombre de alguno de los elementos de la interfaz gráfica de dicha aplicación cambia (cambia el nombre de un botón, de un formulario, etc.) en la siguiente versión, el caso de prueba no funcionaría, y habría que arreglarlo o crear otro nuevo. A modo de caso de estudio, recuérdese el siguiente post: Automatizar las pruebas puede ser lo peor que hagas en tu vida. Te lo explico con una mala experiencia real.
Ejemplos de herramientas que utilizan este enfoque serían el framework de Selenium o la herramienta WindowTester Pro, al igual que también soporta esta funcionalidad la herramienta TestComplete.
Generación 2: Scripting
En este enfoque se programan directamente los scripts en algún lenguaje de programación, y estos serán los que llamen a la ejecución de los casos de prueba. Por un lado este método es más robusto, más flexible y permite reutilizar el código de los casos de prueba, pero también hay que tener en cuenta que la elaboración de scripts es más compleja y requiere que el equipo que desarrolle los test tenga altos conocimientos de programación y esté más especializado.
Herramientas como UISpec4J y FEST quedarían englobadas en esta generación.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
hacia mucho que no se vei una entrada con tanto contenido
gracias javier
Hola Javier,
Me gustaria continuar mi lectura de las partes 2 y 3…. pero no las veo. Aunque estoy seguro esta algo desactualizado dado el tiempo que lleva en la web, me resulta interesante ya que no habia encontrado nada parecido en nuestro idioma.
De paso te aviso el boton de busqueda no funciona 😛
Saludos,
Leandro
ya lo he encontrado. Gracias!