Factores que atentan al testing automatizado

Antes que nada, voy a respestar a otros blogers que en sus blogs llevan nombres similares:

http://josepablosarco.wordpress.com/2010/06/02/factores-que-atentan-contra-las-pruebas-automatizadas/

http://testingbaires.com/?p=749

Algunos nos dicen que los siguientes factores son los que atentan contra la posibilidad de automatizar efectivamente las pruebas de software:

  • Falta de testers que sepan programar, en varios lenguajes y con experiencia en automatización.
  • Desarrollos que no siguen prácticas de diseño que facilitan la automatización de las pruebas y su reusabilidad en el tiempo.
  • La falsa creencia de que la automatización de pruebas solo se realiza a nivel de GUI.
  • Dependencia en herramientas que no son la panacea de la automatización.

Otros disparan contra los mismos clientes quienes expresan gran interés en automatizar el proceso de pruebas y tienen muy altas expectativas en ello sin saber realmente si posible por parte de sus proveedores, brindar un servicio tan específico

Algunos remarcan como algunos conceptos erróneos  se establecen en el mercado:

  • Es fácil sólo hay que grabar los test manuales
  • Es el trabajo de los Testers el automatizar los test
  • Podremos reducir el número de Testers en cuanto tengamos la herramienta
  • Somos ágiles ahora los desarrolladores harán esto

 

Fuera de foco

Desde mi punto de vista, considero que la falta de enfoque es el primer factor en contra del Automation Test.
Las personas que deben pensar esta materia con un enfoque estratégico dentro de una organización, suelen cometer varios errores fatales.
Un error típico suele ser el de intentar automatizar solo algunos aspectos, por ejemplo, solo el código y se relegan otros niveles de pruebas.
Un error similar pero contrapuesto, es el de intentar automatizar todo, desde el requerimiento hasta la prueba de aceptación y mucho más allá.

Con cualquiera de estos enfoques sumado una baja asignación de recursos (horas, equipamiento, proyecto) y sin un proyecto acorde, lógicamente a muy corta data se fracaza.

Creo que esto es así por los “Buzzwords” que al final de tanto sonar generan tendencias erróneas y también por aquello de que aún no se sabe que es la calidad y que es el testing y todo eso que tanto discutimos en los foros.

Conociendo nuestras necesidades

Las organizaciones primero deben conocer sus necesidades, ligarlas con sus posibilidades y limitaciones, establecer los objetivos específicos que persiguen con la automatización (más calidad y menores costos, disminución de riesgos, entendimiento de los sistemas, generación de oportunidades de mejora), para luego establecer pautas para la creación de una arquitectura de automatización.

Un ejemplo costoso

Si solo consideramos la automatización de pruebas de sistemas para un sistema ya existente, podríamos pensar en un modelo que finalmente se parece mucho a los aplicados actualmente por las organizaciones que intentan migrar rápidamente a un modelo de automatización para pruebas de pre-release.

Bajo este modelo, la automatización se hace en paralelo al ya existente juego de pruebas definidas para la ejecución manual. La estrategia consiste en reemplazar paulatinamente las pruebas manuales que dan cobertura a determinadas características, por pruebas que a futuro serán plenamente automaticas.

En muchos casos, el esfuerzo ha sido tal que los ciclos futuros de pruebas de regresión ya cuentan con un modesto juego de pruebas automáticas y actualmente son seleccionables para ciclos que corren en paralelo al ciclo de pruebas manuales, siendo éstas últimas un validador de los resultados de las primeras.

Sin embargo esta forma de hacer las cosas tiene costos que son dificilmente posibles de encarar y sostener por cualquier tipo de organización.

Pude observar que se trata de una gran inversión con un ROI no muy cercano, debido a que mientras existe un grupo de testers que corren pruebas manuales, hay otro grupo que para los mismo casos de pruebas van diseñando los casos “automatizables” y esto implica quizás una duplicación del personal para hacer lo mismo, pero con especialidades diferentes. Cabe destacar que este modelo solo es posible si ya se cuenta con casos de pruebas manuales definidos, ejecutados y con resultados conocidos.

Por otro lado, es necesario incurrir por parte de los automatizadores, en el aprendizaje de varios tipos de herramientas, debido que aún cuando cada una de ellas insista en darnos máxima cobertura, esto no ocurre y de uno u otro modo se ven limitadas por distintos factores propios de las aplicaciones; y no solo del diseño sino de otros aspectos conyunturales. Esto significa que hay más inversión de la que inicialmente se estimó, no solo en tooling sino en tiempo y esfuerzo para los mismos objetivos.

Y suponiendo que lograramos alcanzar un importante nivel de automatización, básicamente un Pass-Fail de una herramienta no reemplaza el carácter analítico de los humanos, sobre todo en escenarios de gran complejidad donde las variables de resultados posibles requieren del análisis experimentado de personas que ya se han enfrentado a problemas que no se registraron o que conocen modos de fallos específicos en condiciones particulares.

Este grado necesario de interacción, nuevamente juega en contra del ROI de las pruebas automatizadas al requerir de más recursos que los estimados.

Finalmente debemos iniciar el modo de mantenimiento de lo automatizado y para cada ciclo deberemos generar aún más automatización, de modo que los problemas mencionados antes ingresan a nuestros nuevos ciclos, cada vez.

Ahora ustedes habrán notado que solo hice referencia a un modelo de todos los que podríamos imaginar, en este caso expuse uno que considero de los más común y que implica que ya tenemos un sistema donde al menos existe un profesional experto en sus características y existen casos de pruebas para regresión.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s