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.

Algo de Testing Automatizado

Objetivos del Testing Automatizado

  • Tests deben mejorar la calidad al más bajo costo
  • Tests deben reducir riesgos mientras aumentamos la velocidad de ejecución
  • Tests deben requerir mantenimiento mínimo al mismo nivel que el sistema involucrado
  • Tests deben ser ejecutados como parte del proceso de construcción
  • Tests deben ayudarnos a entender el sistema bajo pruebas
  • Tests deben ser fácil de ejecutar

Debemos evitar que:

  • El mantenimiento de pruebas automáticas se conviertan en un cuello de botella
  • Que provoquen una disminución de la velocidad de la productividad
  • Que el esfuerzo y tratamiento sea equivalente a un full-development-project
  • Centrar el éxito de los proyectos en la automatización

Tipos básicos de Testing donde se puede automatizar

  • Testing Unitario a nivel del código
  • Testing de aceptación de productos/servicios (pruebas del cliente)
  • Testing de interfaces a nivel de prototipos y luego a nivel de integración o preintegración

Que tener en cuenta para iniciarse en los Procesos Automatizados de Pruebas

¿Cuales son los objetivos de nuestro Testing Automatizado?

Estos deben estar alineados con todos los objetivos de Calidad.

Algunos factores que afectarían a nuestros objetivos:

  • Deseamos automatizar las pruebas regresivas?
  • Deseamos realizar Integración Continua en nuestro Proceso de Desarrollo?
  • Estamos buscando resolver un ítem específico de Aseguramiento de Calidad?

Comencemos a Organizarnos

Elegir una estrategia

Escojamos un Tipo Básico de Testing al que nos queremos aproximar con la automatización. Debería ser una combinación de aproximaciones basadas en:

  • Objetivos
  • Tipo de sistema que queremos probar
  • Cual es nuestro actual nivel de:

    • Testabilidad: Definir la capacidad del sistema a soportar automatización de pruebas
    • Automatización: Si la base es cero ese es el peor escenario
  • Cambios que debemos considerar para una mejor aproximación al nuevo Ciclo de Vida que exigen las pruebas automatizadas:
    • ¿Podemos modificar el Proceso de Desarrollo?
    • ¿Con solo la automatización de pruebas resolvemos algún problema o debemos tener en cuenta otros ítemes?
  • Seleccionemos un nivel de Testing a automatizar e iniciemos: de Aceptación, de Unidad, de Integración, de Regresión, etc.

Seleccionemos las herramientas basándonos en

  • Estrategia seleccionada
  • Orientación del testing (Aceptación del cliente, de componente,  middleware, GUI, bases de datos)
  • Open Source, propietario
  • la tool seleccionada se adapta a nuestra aplicación o debemos adaptar la apliación a la tool?
  • Cuales son nuestros costos?

Puntos para facilitar el mantenimiento

  • Cuales son las expectativas de gestión de pruebas automatizadas y en general?
  • Cuales serán los estándares a seguir o que patrones se implementaran?
  • Impactaremos positivamente en otras áreas?
  • Impactaremos positivamente en otros proyectos asociados?

Podríamos utilizar KeyWord como patrón regular para la reducción de costos de mantenimiento al utilizar la interfaz de usuario como base para automatización.

El enfoque que realizamos afectan las acciones

  • Los desarrolladores podrían ser resopnsables de crear o auditar y ayudar en el mantenimiento de las pruebas automatizada a nivel unitario, componentes y middle-ware, pero QA debe ser parte activa e igualmente responsable utilizando su criterio.
  • QA puede facilitar la integración directa con el proceso de desarrollo responsabilizándose de la creación de pruebas automáticas de otro tipo, como las de GUI para sistemas y aceptación.

Revisemos el Plan de Pruebas Automatizadas

En todos los casos se debería hacer una revisión de la efectividad del proceso y buscar la forma de mojorarlo. Las siguientes cuestiones podrían ayudarnos:

  • ¿Las automatizaciones son difíciles de mantener?
  • ¿Disminuyen la velocidad del Proceso de Desarrollo?
  • ¿Son eficaces en el logro de nuestros objetivos de calidad?

Performance Testing con JMeter

Recientemente iniciamos una iteración donde trabajaríamos dos recursos QA en unas pruebas de comparación de rendimiento de una aplicación Web, luego de que se le introdujera un importante cambio que loguearía en base de datos, los eventos más importantes que típicamente nuestros usuarios ejecutan en algunas secciones críticas de la aplicación.

La herramienta seleccionada fue JMeter, la cual inicialmente fue utilizada como un Proxy para hacer las grabaciones de los escenarios de testing, luego parametrizar comportamientos especiales y finalmente ejecutar miles y ciento de miles de bucles sobre estos escenarios.

Posteriormente utilizamos BadBoy para hacer la grabación de los escenarios fundamentales para las pruebas de regresión. Allí también debimos invertir una buena cantidad de tiempo en obtener los escenarios y luego configurar los parámetros especiales. Ahora contamos con un juego de pruebas básicos y fundamentales para cada cambio que se pudiera aplicar.

Ciertamente no fue un trabajo sencillo, pero al final de nuestra actividad pudimos obtener valores bastantes interesantes los cuales desnudaron aspectos que hicieron dudar de algunos diseños y replantear estos aspectos funcionales.

Había iniciado este artículo con la intención de hacer un resumen de como utilizar JMeter para hacer grabaciones de escenarios de testing de performance, pero ahora mismo lo considero innecesario pues hay varios blogs que a esta materia se dedicaron. De modo tal que solo les dejo las URL para que hagan sus incursiones personales, después de esto podemos discutir la utilidad del testing automatizadoy sus complicaciones.

Performance Testing con JMeter: Paso por Paso para grabar escenarios

Grabación de Test Plan con Jmeter

Grabación de Test Plan con Bad Boy

El desarrollo de software Ágile y la automatización

todo lo que he leído hasta el momento da claros inidicios de que la automatización es un hecho en los entornos de desarrollo Ágiles. Tal es así que pareciera que no existe programación sin Pruebas Unitarias o sin Intengración Contínua, ni pruebas de sistemas sin automatización, inclusive si las mismas fueran manuales.
También se está hablando a pleno de los ambientes colaborativos y automáticos para la generación de requerimientos.
Por experiencia puedo decir que en muchas fabricas de software no se utilizan tales herramientas y se utilizan procedimientos y técnicas “artesanales”.

Inclusive siguiendo metodologías de desarrollo Ágile para la gestión, tal como Scrum, no se ejecutan otras prácticas Ágile. 

Cual es el límite para decir que somos verdaderamente Ágile o que no lo somos?

Mi amigo Juan Carlos Sanchez Miralba, nos da desde XING una respuesta con un punto de vista completo y claro:
Primero debemos diferenciar entre modelo de desarrollo y de gestión. El modelo de gestión puede ser Scrum sin desarrollar utilizando metodologías ágiles.

Si miramos algunos Principios Ágile no forzosamente debemos automatizar todos los procesos. Por lo tanto podríamos aplicar perfectamente el manifesto agile a un proceso de desarrollo cascada iterativo en el que cada iteración sea de una o do semanas como mucho.

No obstante la metodología de programación extrema XP involucran prácticas y herramientas de test unitario e integración continua, las cuales son excelentes para dar soporte a un verdadero proceso de desarrollo Ágile. 
Aquí la automatización de las pruebas y la integración contínua son inobjetables.

Otras Metodologías Ágile no hacen referencias directas a la automatización.

Básicamente aplicando dos principios:
1- Encontrar errores antes en el ciclo de vida es más barato –> Inspección de código y test unitario.
2- Cuantos menos cambios antes del test fácil es la solución –> Integración continua / test automatico de integración.

podemos decir que son dos buenos pilares en los que asentar un desarrollo ágil.

Gracias Juan Carlos
https://www.xing.com/app/forum?op=showarticles;id=16233872;articleid=16254918#16254918