3 conceptos erróneos acerca de la automatización de pruebas por Maximiliano Gonzalez Kunz

 

El avance hacia un modelo de entrega continua de desarrollo de software ha contribuido a la creciente popularidad de las pruebas automatizadas. Se ha alentado también la ruptura de las barreras entre los roles tradicionales. Testers con habilidades de codificación (que es lo que realmente los hace probadores de automatización) encajan perfectamente con este nuevo paradigma, comenta Maximiliano Gonzalez Kunz.

 

El Tester automatizado ofrece muchas ventajas potenciales, incluyendo el aumento de la eficiencia proporcionando una forma eficaz de resolver problemas complejos de pruebas. Sobre estas pruebas también se introduce más coherencia, permitiendo una utilización más eficiente de los recursos durante las horas no pico, explica Maximiliano Gonzalez Kunz.

 

Sin embargo, la automatización de pruebas no es una panacea. Para materializar el potencial de automatización de prueba, es importante ser consciente de los tres errores más comunes.

 

1) La Automatización nunca reemplazará a los testers

 

La idea de que se puede reemplazar a un tester con habilidades de pensamiento crítico, con capacidad de pruebas de formación clásica, y con las facultades de investigación, poniendo un código en su lugar, es una falacia, opina Maximiliano Gonzalez Kunz. Los scripts no van a pensar críticamente o realizar inmersiones más profundas en investigaciones en los softwares. Los scripts que se emplean son tan buenos como el probador que los escribe, explica Maximiliano Gonzalez Kunz.

 

Ya no vemos a la industria como compuesta de probadores automáticos y manuales. Tenemos evaluadores con habilidades de codificación y aquellos sin – todos contribuyen de maneras diferentes, dice Maximiliano Gonzalez Kunz. Los evaluadores capacitados tendrán siempre un lugar reservado y privilegiado debido a su capacidad de pensar críticamente, más allá de un script, claramente.

 

2) se debería automatizar pruebas de interfaz de usuario en primer lugar,

 

Este es un error común. La interfaz de usuario es quebradiza. Se encuentra en un estado constante de flujo a medida que evoluciona en función de las necesidades del cliente y del mercado. Si se comienza con la automatización de pruebas de UI, deberán estar preparados para que su equipo de automatización pase la mayoría de su tiempo en la regrabación de pruebas de interfaz de usuario, ironiza Maximiliano Gonzalez Kunz.

 

Las pruebas de interfaz de usuario generalmente tardan mucho tiempo en ejecutarse. Lo que queremos hacer es centrarnos en el nivel inferior o pruebas a nivel de componentes en primer lugar. No sólo son las pruebas que se van a ejecutar de forma más rápida y con cada generación, pero el componente de nivel inferior, unidades y pruebas de integración tienden a no cambiar con tanta frecuencia. Maximiliano Gonzalez Kunz explica que los scripts pueden validar que su funcionalidad básica está trabajando correctamente y, a continuación, puede emplear el manual de pruebas exploratorias para validar la UI.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *