Blog

El siguiente contenido sobre Automatizar ha sido elaborado por Jair Tabares Plebani (CIO & Founder at Mate Quality Services), MQS es Sponsor Gold de Argentesting.

Muy a menudo escuchamos a managers  y colegas de preventa hablar sobre las bondades de la práctica de automatización en QA, como esta puede reducir los errores encontrados en producción, el time to market, como la compañía rápidamente pude ver el retorno de la inversión, o ROI, y finalmente  el costo mediante la reducción del QA manual.

¡Es aquí donde automatizar falla!

Es en este punto donde un proyecto comienza a perder dinero y donde los ingenieros de QA comienzan a ser vistos como poco profesionales. Desde el comienzo, la definición de automatizar ha sido una mentira de personas que no tienen conocimiento alguno sobre QA Automation.

Expliquemos esto un poco: No se puede hacer “un intento” de automatizar la suite testing, no se puede intentar “automatizar algunos casos de regresión para reducir el tiempo”… bueno, de hecho si se puede, pero al final  esto terminara en un pérdida de tiempo, esfuerzo y con un montón de código inservible.

Como manager de proyecto, al querer reducir el número de errores de producción detectándolos antes durante la fase de testing de integración de sistemas, o SIT por System Integration test, hay que pensar cuidadosamente:

1. QA Automation es un trabajo de desarrollo
2. Como cualquier desarrollo, debe ser un proyecto de desarrollo
3. Como cualquier proyecto desarrollo, necesita desarrolladores escribiendo código
4. Como cualquier proyecto desarrollo, necesita de un arquitecto
5. Como cualquier proyecto desarrollo, también se necesitará:
   1. Evaluar si es necesario
   2. Si es necesario, crear un plan de automatización
   3. Cuando el plan esté listo, crear una estrategia para llevarlo adelante
   4. Cuando el plan y la estrategia estén terminados, debe buscarse la aprobación y el presupuesto del proyecto
   5. Si se tiene la suerte y se consigue lo anterior, hay que buscar la gente apropiada para llevar el proyecto adelante
   6. Cuando tengamos algunos miembros del equipo disponibles, habrá que darse cuenta de no haber olvidado poner en el plan y la estrategia, la realización de un producto mínimo viable, o MVP por Minimum Viable Product, o prueba de concepto, conocida como PoC por Proof of Concept

Como puede observarse, automatizar es un proyecto de desarrollo, y si no es visto de esa manera,  el riesgo de un gran fallo, y con ello la estabilidad del puesto de trabajo, aumenta.

Pero espera… esto no termina aquí. Ahora que hemos mostrado los porque automatizar no es una cosa simple, debemos ir más a fondo y ver otros riesgos latentes que podemos encontrar: 

1. Herramientas: más de una vez, los managers están impresionados por información de una herramienta que encontraron en Internet o una reunión con un vendedor. O peor, están fascinados después de escuchar una historia de éxito de otra persona acerca de alguna experiencia en otra compañía. Estos son ejemplos de un gran ¡NO!
   A menos que tenga mucha experiencia en Automatización, se debe permitir que el equipo participe de la discusión. Debería tenerse en cuenta:
   1. Su equipo de desarrollo: si desea soporte para su equipo de automatización de QA y desea tener un lenguaje de desarrollo común
   2. Comunidad de QA: si por alguna razón necesitas utilizar una comunidad de control de idiomas diferente, no sería fácil obtener mucho soporte o ingenieros si deseas automatización en Fortran.
   3. Su presupuesto si quiere usar una herramienta comercial
   4. Si busca una herramienta comercial, piense en la dependencia de la herramienta:
      1. ¿Qué pasa si el proveedor deja de apoyar la herramienta?
      2. ¿Qué ocurre si desarrollamos una nueva función que la herramienta no admite?
2. Roles y responsabilidades: es muy común que los managers decidan contratar a un ingeniero senior para construir todo el framework en etapas tempranas, que tenga todo el conocimiento y luego contratar a otros ingenieros para que trabajen con él, centralizando el conocimiento en un único «Atlas». «. ¿Qué pasaría si despedimos Atlas? ¿Qué pasa si se va por un mejor trabajo?
3. La mentira del vendedor: cualquier vendedor que quiera venderle proyectos de automatización usaría cualquiera de las siguientes frases:
   1. El equipo podría automatizar el 100%
   2. Podríamos tener cualquier QA haciendo automatización
   3. ROI inmediato
   4. Auto Mantenimiento: La automatización le asegura que su producto puede funcionar sin errores. Todas estas premisas no son ciertas. Todos estos objetivos son poco realistas. Como cualquier proyecto de desarrollo, la automatización va paso a paso, creciendo de error a error.
4. Cualquier QA puede automatizar: una cosa muy común es que los managers solicitan a QA manuales sin ninguna experiencia en codificación o desarrollo es comenzar a crear automatización porque es muy fácil, simplemente grabar los flujos y jugar un poco con algunas herramientas increíbles. Lo fácil será encontrar:
   1. Scripts sin flexibilidad
   2. Nula reutilización de código
   3. Nula documentación
   4. Necesidad de Invertir tiempos en refactorización cuando los QA’s aprenden a codificar para poder ganar flexibilidad
   5. Generación de código de espagueti cuando los QA’s sin experiencia comienzan a codificar
   6. Nombres extraños en variables del código que hacen imposible su mantenimiento
   7. Sin modularidad
   8. Scripts exageradamente largos sin atomicidad
5. ¡Dale mecha Cacho, que estamos al horno! Cuando el manager se da cuenta de que necesita mostrar el progreso en la automatización, lleva a su equipo a «automatizar más y más, que no se pierda tiempo en refactors». Ya se sabe cómo es esto … después de algunos meses, a nadie le importa el estado rojo en la suite de automatización … ahora ya nadie quiere refactorizar a este enorme monstruo-
6. Y muchas, muchas otras cosas…

Ahora que conoces esto, ¿Seguís pensando que automatizar es soplar y hacer botellas?

MQS estuvo presente en la expo:QA’18 (Madrid) y colaborando con Argentesting enviándole al final de cada jornada, una síntesis del día con fotos y sus comentarios.

Todos los articulos están publicados tanto en este blog como en la página de Argentesting en LinkedIn. MQS elaboró contenido de los tres días en los que se desarrolló el evento en España.

[gdlr_notification icon=»icon-flag» type=»color-background» background=»#99d15e» color=»#ffffff»]CASO DE ÉXITO CON NUESTRO SPONSOR[/gdlr_notification]
[gdlr_notification icon=»icon-flag» type=»color-border» border=»#99d15e» color=»#000000″]MQS – Mate Quality Services – es SPONSOR GOLD de Argentesting, y como tal, tiene ciertos beneficios de acuerdo con el Plan para Sponsors que adquirió. En este sentido, uno de los beneficios es proponerle ideas y acciones para realizar en conjunto con el objetivo de aumentar su visibilidad en la red a partir de contenidos de valor o bien, de acciones innovadoras que agreguen valor a la comunidad de software testers de latinoamérica. Es por ello, que se nos ocurrió desde Argentesting proponerle a MQS cuando nos enteramos que viajaban a España a participar como oyentes de la expo:QA’18, que sean nuestros corresponsales para enviarnos material que pudiera convertirse en artículos. Rápidamente nos confirmaron que les encantaba la idea y que contáramos con ellos. Luego de tener su aceptación, me puse en contacto con Graham Moran, Managing Director at NEXO QA & Organiser of expo:QA, a quien conozco desde hace algún tiempo, para comentarle la acción que se nos había ocurrido y por supuesto, tener su aprobación. Una vez conseguido la misma, se lo comunicamos a MQS y de ahí en más, pensamos en la estrategia y plan de acción a seguir, y que finalmente dieron origen a la actual publicación. (Gustavo Terrrera, Editor)[/gdlr_notification]

Automatización

English version

Automation? It’s Easy as Pie!

Very often we hear managers and IT sales people talking about the wonderfulness of the automation practice in QA, how it will reduce production bugs, time to market, how quickly company will get the ROI and finally cost by reducing manual QA.
It is at this point where automation fails! Is at this point where a project starts losing money and where QA Engineers start looking unprofessional. From the very beginning, the definition of the automation is a lie from people that has not idea about QA automation.

Let me explain a bit: You cannot make “an attempt to” automate your testing suite, you cannot try to “automate few regression test to reduce time”… well in fact you can, but it will conduce you to lose time, effort and to have a bunch of unusable code.

As a Project manager that likes to reduce the number of bugs on production by detecting them earlier on SIT phase, you need to think carefully:

1. QA automation would be development effort
2. As any other development effort, it will be development project
3. As any development project you will need to have developers creating code
4. As any development project you will need to have an Architect
5. As any development project YOU will ALSO need to:
   1. Think if you really need automation
   2. If you need automation, you need to make a QA Automation Plan
   3. When you have a plan, you need to make a QA Automation Strategy
   4. When you have the Plan and the Strategy, you need to get approval and budget
   5. If you are very lucky and get this, you need to find the correct people
   6. When you get part of the people, you will need to figure out that you don’t forget to put into the plan your QA Automation MVP or POC

As you see, QA Automation is a development project, and if you don’t see in that way, the risk of a big failure (and probably to lose your job) increases.

But wait… this does not end here. Now you that you learned that QA automation is not a simple thing, you need to go deeper and get the other risks you are facing:

1. Tools: more than once, managers are impressed by the brochure of a tool they found on internet or a call a sales person gives to them. Or worst, they are fascinated after hearing a success story from another person about some experience on another company. These are examples of a big NO! Unless you have a lot of experience on Automation, let your team participate into the discussion. You would like to have in mind:
   1. Your dev team: if you want support for your QA automation team and want to have a common dev language.
   2. QA community: if for some reason you need to use a different language check community, would not be easy to get much support or engineers if you want automation in Fortran.
   3. Your budget if you want to use a commercial tool.
   4. If you go for a commercial tool, think about tool dependency:
   5. What if vendor stops supporting the tool?
   6. What if we develop a new feature that the tool does not support?

2. Roles and Responsibilities: is very common that managers decide to hire a Senior Engineer to build the whole framework on earlier stages, let him get all the knowledge and then hire other engineers to work with him, centralizing the knowledge on a unique “Atlas”. What would happen if you Fire Atlas? What if he leaves for a better job?

3. The Salesman Lie: any sales person that wants to sell you automation projects would throw any of the following lies:
   1. The team would be able to automate 100%
   2. We could have any tester doing automation
   3. Immediate ROI
   4. Self maintenance Automation assured that your product can go without bugs.All these promises are not true. All these as goals are unrealistic. As any development project, automation goes step by step, growing from error to error.
4. Any QA can automate: a very common thing is that managers ask manual QA’s without any expertise on coding or development is to start creating automation because is very easy just to record and play with some awesome tools. You easily face:
   1. Record & play scripts without any flexibility
   2. No reuse of code
   3. No documentation
   4. More refactor time when QA’s learn to code to be able to gain flexibility
   5. Spaghetti code on early coded stages
   6. Weird names on variables from the code
   7. No modularity
   8. Long scripts
5. Hurry up Tim, the end is near! As a manager you realize you need to show progress on automation, so you just push your team to “automate more and more, don’t spend time on refactors”. You know how this end… after few months, nobody cares about the red status on the automation suite… no one wants to refactor this huge monster
6. And many, many other things…

Now that you got this, still thinking that QA Automation is easy as ABC?

Autor

Jair Tabares Plebani
CIO & Founder at Mate Quality Services
Barcelona Area, Spain

Mate Quality Services (MQS) es una empresa de rápido crecimiento con sede en Uruguay que se especializa en control de calidad, auditoría de TI, gestión de proyectos y servicios de pruebas (testing), asegurando que se brinde la solución adecuada a sus clientes. Como líder de pensamiento e innovador en la industria de TI, Mate Quality Services agrega valor a lo largo de cada fase del desarrollo y gestión de los sistemas de TI, lo que mejora la calidad de las aplicaciones, reduce el tiempo de lanzamiento al mercado y reduce el costo total de propiedad.

Artículos publicados desde la página de Argentesting en LinkedIn

MQS – CORRESPONSAL DE ARGENTESTING EN LA EXPOQA – ÚLTIMO DÍA
MQS – CORRESPONSAL EN MADRID EN EXPOQA – DÍA 05-06-18
MQS – CORRESPONSAL EN MADRID EN EXPOQA
MQS SERÁ NUESTRO CORRESPONSAL EN LA EXPO:QA’18
MQS NUEVO SPONSOR GOLD DE ARGENTESTING ED 2018
TIPS DE PRODUCTIVIDAD. A COMPLETAR TAREAS!!!
IN CODE WE TRUST?