Desde aquí, vamos a ayudarte a poner tus ideas en orden y a que el camino hacía la automatización sea más sencillo y amigable para ti.
La introducción a la automatización puede ser muy sencilla, pero con un orden, unas reglas y, sobre todo, paciencia.
El primer paso, es tener un tiempo estipulado para dedicar a automatizar. Como ya os comento, la paciencia es uno de los requisitos indispensables y para ello, es necesaria una inversión de tiempo inicial bastante grande para poder dar los pasos adecuados.
Cuando trabajamos con un equipo de pruebas, lo ideal, es que esto esté en manos del responsable y que estipule unas normas y unos tiempos de dedicación para ello. Si no, será prácticamente imposible el poder tener una curva de aprendizaje adecuada. Cuando nos involucramos con automatización, un paso sencillo y contundente, que nos llevará a ganar un tiempo muy valioso, es el de realizar pruebas de este tipo para elementos de riesgo menor, cosa que nos llevará a ganar mucho tiempo y poder concentrarnos, al menos en el inicio, en funcionalidades de mayor criticidad o con una prioridad de negocio alta.
Cuando tengamos la funcionalidad menor ya automatizada, iremos automatizando la de mayor y así ir ganando tiempo en general. Otro punto de vista, es el de verificar que elementos de alto riesgo son factibles de automatizar para poder probarlos regularmente y crear un ciclo de confianza con cada despliegue. La decisión vendrá dada por un estudio total del producto que estemos probando y, sobre todo, de las necesidades que tendremos o tendrá el equipo de QA en ese momento.
En un proyecto que hicimos hace un tiempo, tuvimos una experiencia de este tipo. La carga de trabajo era manual en el 100%, pero llegó un momento en el que las entregas de desarrollo superaban la carga de trabajo que podíamos asumir. Esto, unido a que la dirección no quería ampliar al equipo, nos llevó a realizar un esfuerzo “extra” por automatizar una batería crítica de regresión para que los despliegues entre entornos fueran seguros y al menos, tuviéramos la tranquilidad de que los componentes más importantes, estuvieran controlados.
Esto nos dio la confianza de seguir automatizando, funcionalidad tras funcionalidad e hizo que tuviésemos una batería de pruebas enorme y funcionando, lista para ejecutar, una vez tras otra. El siguiente paso, fue el de integrarla en Jenkins y de esta manera, no nos teníamos que preocupar ni de lanzar las pruebas, ni siquiera, de estar atentos al despliegue.
Lo esencial, es que, al comenzar con la automatización, hay que considerar las necesidades del equipo y el de mantener un equilibrio entre esto y el trabajo diario para que sigamos manteniendo los estándares de calidad por encima de todo. El objetivo principal, a nivel general, es que el esfuerzo invertido en automatizar, tiene que respaldarse por todo el equipo y que este, se concentre en crear pruebas que respalden al equipo y sirvan para descender la carga de trabajo repetitiva.
Una vez que tenemos esto ya planteado y estamos mentalizados, es hora de elegir una herramienta adecuada y que cubra nuestras necesidades. Para ello, tenemos que hacernos una serie de preguntas que nos irán acotando la decisión y enfocando para seleccionar la más adecuada para nuestro proyecto.
El primer paso, es tener un tiempo estipulado para dedicar a automatizar. Como ya os comento, la paciencia es uno de los requisitos indispensables y para ello, es necesaria una inversión de tiempo inicial bastante grande para poder dar los pasos adecuados.
Cuando trabajamos con un equipo de pruebas, lo ideal, es que esto esté en manos del responsable y que estipule unas normas y unos tiempos de dedicación para ello. Si no, será prácticamente imposible el poder tener una curva de aprendizaje adecuada. Cuando nos involucramos con automatización, un paso sencillo y contundente, que nos llevará a ganar un tiempo muy valioso, es el de realizar pruebas de este tipo para elementos de riesgo menor, cosa que nos llevará a ganar mucho tiempo y poder concentrarnos, al menos en el inicio, en funcionalidades de mayor criticidad o con una prioridad de negocio alta.
Cuando tengamos la funcionalidad menor ya automatizada, iremos automatizando la de mayor y así ir ganando tiempo en general. Otro punto de vista, es el de verificar que elementos de alto riesgo son factibles de automatizar para poder probarlos regularmente y crear un ciclo de confianza con cada despliegue. La decisión vendrá dada por un estudio total del producto que estemos probando y, sobre todo, de las necesidades que tendremos o tendrá el equipo de QA en ese momento.
En un proyecto que hicimos hace un tiempo, tuvimos una experiencia de este tipo. La carga de trabajo era manual en el 100%, pero llegó un momento en el que las entregas de desarrollo superaban la carga de trabajo que podíamos asumir. Esto, unido a que la dirección no quería ampliar al equipo, nos llevó a realizar un esfuerzo “extra” por automatizar una batería crítica de regresión para que los despliegues entre entornos fueran seguros y al menos, tuviéramos la tranquilidad de que los componentes más importantes, estuvieran controlados.
Esto nos dio la confianza de seguir automatizando, funcionalidad tras funcionalidad e hizo que tuviésemos una batería de pruebas enorme y funcionando, lista para ejecutar, una vez tras otra. El siguiente paso, fue el de integrarla en Jenkins y de esta manera, no nos teníamos que preocupar ni de lanzar las pruebas, ni siquiera, de estar atentos al despliegue.
Lo esencial, es que, al comenzar con la automatización, hay que considerar las necesidades del equipo y el de mantener un equilibrio entre esto y el trabajo diario para que sigamos manteniendo los estándares de calidad por encima de todo. El objetivo principal, a nivel general, es que el esfuerzo invertido en automatizar, tiene que respaldarse por todo el equipo y que este, se concentre en crear pruebas que respalden al equipo y sirvan para descender la carga de trabajo repetitiva.
Una vez que tenemos esto ya planteado y estamos mentalizados, es hora de elegir una herramienta adecuada y que cubra nuestras necesidades. Para ello, tenemos que hacernos una serie de preguntas que nos irán acotando la decisión y enfocando para seleccionar la más adecuada para nuestro proyecto.
- - En primer lugar, tenemos que saber, ¿quién está diseñando las pruebas?
- - En segundo lugar, ¿Qué tipo de pruebas se van a ejecutar?
- - En tercer lugar, ¿Hay algún tipo de presupuesto para esta labor?
Por último y si no existe presupuesto, ¿la herramienta Open Source tiene una comunidad adecuada y que pueda solventar nuestras dudas?
Desde mi punto de vista y con mi experiencia en diferentes proyectos, os puedo decir, que el punto más importante es: herramienta gratuita o de pago.
A nivel global, hay herramientas gratuitas que tienen una comunidad enorme y son el estándar en el mercado, como Selenium, pero si hablamos de herramientas de pago, contamos con UFT, por ejemplo, que es una de las más potentes que conozco y su versatilidad está por encima de cualquiera.
Ahora bien, cuando nos involucramos en un proyecto, la mayoría de las veces, tenemos restricciones presupuestarias, por lo tanto, solemos seleccionar Selenium como estándar, ya que cuenta con una de las mayores comunidades y solventaremos la mayoría de posibles “problemas” que podamos encontrarnos con preguntas hacía ella. También, lo que suelo hacer, es preguntar en las diferentes comunidades de QA por este tipo de herramientas y si alguien las ha utilizado y que experiencias han tenido.
Como siempre, las necesidades de cada proyecto son únicas y hay que tener en cuenta que pueden ser diferentes de las descritas aquí, por lo tanto, como digo, hay que estudiar cada caso y sobre todo ser consciente de que lo más importante es considerar lo que se quiere automatizar y comprender el objetivo común del proyecto y de lo que se pretende con él.
Evidentemente, el siguiente paso lógico es el de escribir la primera prueba sobre la funcionalidad que definamos o consideremos.
Lo primero, es ir separando o dividiendo los casos de prueba que se quieren automatizar, en paquetes pequeños, que nos permitan avanzar, paso a paso, y despacio, evidenciando que no hemos roto nada de lo realizado y pudiendo dar marcha atrás de manera sencilla. Además, si no realizamos este tipo de acción y automatizamos caminos completos, las pruebas serán bastante inútiles ya que, si algo falla en un camino largo, el resto de cosas, por las que, seguramente se pueda seguir probando, quedarán inutilizadas y ya se marcarán como falladas, haciéndonos perder capacidad y alcance.
Una buena práctica que podemos poner en funcionamiento es el de ir ejecutando esos pequeños trocitos, una vez finalicemos uno nuevo, así, iremos comprobando que no rompemos nada y vamos dando pasitos de manera segura.
Otra buena práctica que hay que realizar, casi de manera obligatoria es la de “montar y desmontar” el juego de datos en la prueba. Una prueba completa y funcional debería de ser capaz, por ejemplo, de dejar limpio el registro de base de datos que hemos creado y así no ensuciar los entornos y que siempre estén funcionales, limpios y sin problemas. Ahora, con Docker, esto se puede solventar, levantando el entorno limpio una y otra vez, pero perdemos buenas prácticas y no todo el mundo trabaja sobre estas tecnologías, por lo tanto, mi recomendación viene siempre por hacerlo bien.
La idea principal es la de realizar pruebas seguras, que no sean frágiles y, sobre todo, sencillas de ejecutar para que los tiempos sean los adecuados.
A nivel de buenas prácticas, nos debemos de realizar algunas preguntas que nos ayudarán a saber como hacer las pruebas, como enlazarlas y como hacer que sean más eficientes y ágiles:
Desde mi punto de vista y con mi experiencia en diferentes proyectos, os puedo decir, que el punto más importante es: herramienta gratuita o de pago.
A nivel global, hay herramientas gratuitas que tienen una comunidad enorme y son el estándar en el mercado, como Selenium, pero si hablamos de herramientas de pago, contamos con UFT, por ejemplo, que es una de las más potentes que conozco y su versatilidad está por encima de cualquiera.
Ahora bien, cuando nos involucramos en un proyecto, la mayoría de las veces, tenemos restricciones presupuestarias, por lo tanto, solemos seleccionar Selenium como estándar, ya que cuenta con una de las mayores comunidades y solventaremos la mayoría de posibles “problemas” que podamos encontrarnos con preguntas hacía ella. También, lo que suelo hacer, es preguntar en las diferentes comunidades de QA por este tipo de herramientas y si alguien las ha utilizado y que experiencias han tenido.
Como siempre, las necesidades de cada proyecto son únicas y hay que tener en cuenta que pueden ser diferentes de las descritas aquí, por lo tanto, como digo, hay que estudiar cada caso y sobre todo ser consciente de que lo más importante es considerar lo que se quiere automatizar y comprender el objetivo común del proyecto y de lo que se pretende con él.
Evidentemente, el siguiente paso lógico es el de escribir la primera prueba sobre la funcionalidad que definamos o consideremos.
Lo primero, es ir separando o dividiendo los casos de prueba que se quieren automatizar, en paquetes pequeños, que nos permitan avanzar, paso a paso, y despacio, evidenciando que no hemos roto nada de lo realizado y pudiendo dar marcha atrás de manera sencilla. Además, si no realizamos este tipo de acción y automatizamos caminos completos, las pruebas serán bastante inútiles ya que, si algo falla en un camino largo, el resto de cosas, por las que, seguramente se pueda seguir probando, quedarán inutilizadas y ya se marcarán como falladas, haciéndonos perder capacidad y alcance.
Una buena práctica que podemos poner en funcionamiento es el de ir ejecutando esos pequeños trocitos, una vez finalicemos uno nuevo, así, iremos comprobando que no rompemos nada y vamos dando pasitos de manera segura.
Otra buena práctica que hay que realizar, casi de manera obligatoria es la de “montar y desmontar” el juego de datos en la prueba. Una prueba completa y funcional debería de ser capaz, por ejemplo, de dejar limpio el registro de base de datos que hemos creado y así no ensuciar los entornos y que siempre estén funcionales, limpios y sin problemas. Ahora, con Docker, esto se puede solventar, levantando el entorno limpio una y otra vez, pero perdemos buenas prácticas y no todo el mundo trabaja sobre estas tecnologías, por lo tanto, mi recomendación viene siempre por hacerlo bien.
La idea principal es la de realizar pruebas seguras, que no sean frágiles y, sobre todo, sencillas de ejecutar para que los tiempos sean los adecuados.
A nivel de buenas prácticas, nos debemos de realizar algunas preguntas que nos ayudarán a saber como hacer las pruebas, como enlazarlas y como hacer que sean más eficientes y ágiles:
- - En primer lugar, ¿Las pruebas deben de depender la una de la otra a nivel de datos?
- - En segundo lugar, ¿hemos creado logs o registros suficientes para comprobaciones en el caso de que exista algún error o problema?
- - Por último, ¿las pruebas son mantenibles y fáciles de modificar o actualizar si nos encontramos con un cambio grande en el software?
Basándonos en la primera pregunta, evidentemente y sin entrar en ningún tipo de discusión, las pruebas no pueden depender unas de otras, tienen que ser independientes, si o si, pero esto no quiere decir que, a nivel de datos, puedan tener ciertas “dependencias” o compartir el uso de algunos datos entre ellas.
Sobre todo, también tenemos que tener claro que no debemos de limitar nuestras pruebas a los caminos felices, si no que, unas buenas pruebas automáticas tienen que cubrir todo lo posible y las combinatorias adecuadas para detectar defectos complejos o en sitios más inesperados.
Por último, a nivel de descripción de pruebas, siempre hay que dar la mayor información para que las personas que no han creado la prueba o que la van a ejecutar, si existe algún tipo de problema o van a actualizarla o modificarla por algún cambio, tengan claro que realiza, cuales son los pasos o que puedan tener toda la información detallada y bien estructurada. No tengamos miedo a introducir descripciones completas y con frases completas. Siempre hay que pensar que, en algún momento, otra persona, llegará a las pruebas que hemos realizado y tendrán que “pegarse” con ellas, así que, todo lo que podamos facilitar la vida, siempre será bueno.
La idea de este artículo es el de dar una serie de ideas o patrones para comenzar a automatizar o dar el salto a ello, pero siempre teniendo en cuenta que cualquier proyecto es un mundo y no tienen porque encajar ni valer, sobre todo, debemos de plantearnos que lo que consideremos mejor para hacer, seguramente sea lo adecuado y no debemos de dejar llevarnos por modas, por tecnologías super novedosas o por tendencias que seguramente acabarán desapareciendo y nos dejarán con tecnologías sin comunidad, sin servicio y difíciles de mantener y continuar.
Por lo tanto, es mejor, valorar lo que ya está asentado en el mercado que ir siempre a lo último, dar bandazos y nunca llegar a nada.
La automatización es el paso lógico para todo profesional que quiera seguir avanzando en el mundo de la calidad y el que nos puede potenciar tanto a nivel de experiencia, como a nivel de visibilidad en el mercado, por lo tanto, merece la pena intentarlo y dar el paso.
Sobre todo, también tenemos que tener claro que no debemos de limitar nuestras pruebas a los caminos felices, si no que, unas buenas pruebas automáticas tienen que cubrir todo lo posible y las combinatorias adecuadas para detectar defectos complejos o en sitios más inesperados.
Por último, a nivel de descripción de pruebas, siempre hay que dar la mayor información para que las personas que no han creado la prueba o que la van a ejecutar, si existe algún tipo de problema o van a actualizarla o modificarla por algún cambio, tengan claro que realiza, cuales son los pasos o que puedan tener toda la información detallada y bien estructurada. No tengamos miedo a introducir descripciones completas y con frases completas. Siempre hay que pensar que, en algún momento, otra persona, llegará a las pruebas que hemos realizado y tendrán que “pegarse” con ellas, así que, todo lo que podamos facilitar la vida, siempre será bueno.
La idea de este artículo es el de dar una serie de ideas o patrones para comenzar a automatizar o dar el salto a ello, pero siempre teniendo en cuenta que cualquier proyecto es un mundo y no tienen porque encajar ni valer, sobre todo, debemos de plantearnos que lo que consideremos mejor para hacer, seguramente sea lo adecuado y no debemos de dejar llevarnos por modas, por tecnologías super novedosas o por tendencias que seguramente acabarán desapareciendo y nos dejarán con tecnologías sin comunidad, sin servicio y difíciles de mantener y continuar.
Por lo tanto, es mejor, valorar lo que ya está asentado en el mercado que ir siempre a lo último, dar bandazos y nunca llegar a nada.
La automatización es el paso lógico para todo profesional que quiera seguir avanzando en el mundo de la calidad y el que nos puede potenciar tanto a nivel de experiencia, como a nivel de visibilidad en el mercado, por lo tanto, merece la pena intentarlo y dar el paso.
Comentarios
Publicar un comentario