En la era de los DevOps, los Full-Stack y las metodologías ágiles donde el rol de QA es uno más del equipo, el tener pruebas automatizadas es algo que suele ser normal dentro del stack tecnológico de cualquier empresa. Cada día vemos más y más herramientas más fáciles de utilizar para agilizar el proceso de pruebas, tener resultados y detectar defectos lo antes posible.
Pero aunque toda esa teoría está muy bien y todos la sabemos, debemos tener en cuenta algo que nadie te dice, y es el preparar las bases o el stack tecnológico necesario para realizar una buena implantación del proceso de automatización de pruebas.
¿Cuáles son las cosas principales en las que debemos pensar para empezar el proceso de automatización y tener una buena base?
¿Por qué necesitamos automatizar?
La razón fundamental por la que se elige automatizar pruebas es para agilizar la ejecución de pruebas, sobre todo en las pruebas de regresión. La automatización nos ayuda a realizar pruebas repetitivas sobre páginas (entendiendo como página una de las pantallas de nuestra aplicación), pruebas sobre secciones que no suelen o no van a cambiar en un periodo de tiempo considerable, y, que si cambian, los cambios van a ser mínimos. Por eso es indispensable tener bien definido el plan de pruebas de regresión antes de comenzar y saber qué casos de prueba son aquellos potenciales para empezar con la automatización.
Conocer la aplicación que vamos a automatizar.
Otra de las cosas más importantes y que debemos tener en cuenta antes de empezar es conocer nuestra aplicación. Primero debemos saber en qué tecnología está desarrollada y con qué lenguaje de programación, ya que esto nos hará decantarnos por unas herramientas de automatización u otras. También debemos conocerla, no sólo a nivel técnico ni de programación, sino a nivel funcional. ¿Nuestra aplicación cambia a menudo?, ¿Tiene secciones que no cambian?, ¿Tenemos un plan de pruebas funcional ya creado con todos los flujos principales para realizar las pruebas de regresión?. Todo esto va relacionado con el primer punto que hemos comentado de la razón por la que hemos elegido empezar a automatizar.
Conocer el alcance de lo que queremos automatizar.
Cuando pensamos en automatizar pruebas y no lo hemos hecho antes, nos pensamos que con una barita mágica vamos a empezar a grabar acciones y que todo se va a poder automatizar, eso, es falso.
La automatización es un proceso que requiere una gran inversión (sobre todo inicial) y que debemos tener en cuenta que no es algo que se pueda usar siempre en el 100% de los casos, sino que tendremos excepciones y pruebas que debemos seguir realizando a mano. Para no engañarnos a nosotros mismos, ni a nuestros clientes, debemos tener bien presente qué secciones son potenciales a automatizar de nuestra aplicación y cuántas pruebas vamos a poder realizar en esas secciones de forma automática (teniendo en cuenta que, si una prueba se realiza y nuestra aplicación cambia, debemos realizar mantenimiento sobre esa prueba y actualizarla).
Tener en cuenta el tiempo inicial y la inversión que nos va a suponer.
Aunque a la larga la automatización es un proceso que nos va a ayudar y mucho, ya hemos comentado que la inversión inicial que requiere es alta, sobre todo en preparar el entorno, conocer herramientas de pruebas, integrar las pruebas con las herramientas de integración continua...
Debemos tener bien claro cuál va a ser el ROI y el Payback de nuestro proceso de automatización y que tanto la organización como tus clientes lo conozcan. Para visualizar un poco todo esto y entender mejor este proceso, os dejo un artículo de QA Técnico (así como una gráfica bastante visual) para comprender el ROI y Payback de las pruebas automáticas y entender mejor por qué necesitamos la automatización.
Elegir la mejor herramienta.
Otra de las bases que debemos tener clara y elegir correctamente es la herramienta que vamos a utilizar para realizar las pruebas automáticas. Por ejemplo, si tenemos una web y queremos automatizar pruebas funcionales, debemos ver qué herramientas nos pueden servir para ello, la principal herramienta de automatización web es Selenium (y también una de las más sencillas de aprender y en la que la comunidad tiene más apoyo). También están surgiendo nuevas herramientas basadas en Javascript como Jasmine, Nigthwatch... que pueden ser una solución útil para empezar nuestras pruebas automáticas.
Si queremos automatizar pruebas móviles, el rey de los frameworks disponibles (y mi favorito con diferencia) es Appium, una herramienta Open Source con bastante documentación y actividad de la comunidad y que sirve para automatizar pruebas tanto para iOS como para Android en aplicaciones nativas e híbridas. También para movilidad hay otras opciones, sobre todo para aplicaciones nativas, por ejemplo Espresso o Barista (para Android) o XCTest o KIF (para iOS).
Tiempo de los desarrolladores y cambio de mentalidad.
Una de las cosas que nadie cuenta en la automatización de pruebas y que es muy importante es la ayuda de los desarrolladores en este proceso. Para poder automatizar, los elementos de la pantalla con los que queremos interactuar deben tener un identificador único para poder trabajar con ellos (comprobar que son visibles, clickables, clickar en ellos, etc). Para ello tanto para web como para movilidad (especialmente para movilidad), el equipo de desarrollo ha de ayudar a la persona de QA que se dedique a la automatización, primero dedicando tiempo para poner estos identificadores únicos, y después a ayudarle a mejorar y encontrar elementos que pueden ser difíciles de acceder (sobre todo en movilidad). Esto va a requerir un compromiso y un cambio de mentalidad en el desarrollo para el equipo encargado de la aplicación como para la persona de QA dedicada a realizar los test automáticos.
Herramientas de Integración Continua.
Cuanto tengamos elegido tanto el framework como las pruebas y queramos empezar a realizarlas, debemos pensar también en tener preparado un buen entorno de integración continua.
¿Por qué necesitamos un entorno de integración continua? Primero para la compilación/despliegue de nuestras aplicaciones (tanto en movilidad como en web) para realizar este proceso sin error humano y de forma más rápida y segundo para poder conocer en todo momento la aplicación (número de versión y build concreto) que estamos probando.
Además de para el proceso de desarrollo, las herramientas de Integración Continua como Jenkins, Docker, Kubernetes... nos van a ayudar en el proceso de ejecución de pruebas. Para esto debemos tener un entorno limpio (de ahí la importancia de Docker en todo este proceso) donde poder lanzar las pruebas cada noche (para llegar a primera hora y encontrarnos las regresiones) sobre las aplicaciones que queramos automatizar. Estas herramientas no sólo nos ayudan a ser más ágiles sino a tener más visión (y más rápida) de los resultados de las diferentes ejecuciones de las pruebas automáticas que estemos haciendo.
Aunque suene a un proceso largo y, como hemos comentado, la inversión inicial es alta, la automatización te da, no sólo un beneficio a largo plazo para los desarrolladores y QA sino un cambio de mentalidad en todo el proceso tanto de desarrollo como de pruebas dentro de una metodología de desarrollo ágil.
Pero aunque toda esa teoría está muy bien y todos la sabemos, debemos tener en cuenta algo que nadie te dice, y es el preparar las bases o el stack tecnológico necesario para realizar una buena implantación del proceso de automatización de pruebas.
¿Cuáles son las cosas principales en las que debemos pensar para empezar el proceso de automatización y tener una buena base?
¿Por qué necesitamos automatizar?
La razón fundamental por la que se elige automatizar pruebas es para agilizar la ejecución de pruebas, sobre todo en las pruebas de regresión. La automatización nos ayuda a realizar pruebas repetitivas sobre páginas (entendiendo como página una de las pantallas de nuestra aplicación), pruebas sobre secciones que no suelen o no van a cambiar en un periodo de tiempo considerable, y, que si cambian, los cambios van a ser mínimos. Por eso es indispensable tener bien definido el plan de pruebas de regresión antes de comenzar y saber qué casos de prueba son aquellos potenciales para empezar con la automatización.
Conocer la aplicación que vamos a automatizar.
Otra de las cosas más importantes y que debemos tener en cuenta antes de empezar es conocer nuestra aplicación. Primero debemos saber en qué tecnología está desarrollada y con qué lenguaje de programación, ya que esto nos hará decantarnos por unas herramientas de automatización u otras. También debemos conocerla, no sólo a nivel técnico ni de programación, sino a nivel funcional. ¿Nuestra aplicación cambia a menudo?, ¿Tiene secciones que no cambian?, ¿Tenemos un plan de pruebas funcional ya creado con todos los flujos principales para realizar las pruebas de regresión?. Todo esto va relacionado con el primer punto que hemos comentado de la razón por la que hemos elegido empezar a automatizar.
Conocer el alcance de lo que queremos automatizar.
Cuando pensamos en automatizar pruebas y no lo hemos hecho antes, nos pensamos que con una barita mágica vamos a empezar a grabar acciones y que todo se va a poder automatizar, eso, es falso.
La automatización es un proceso que requiere una gran inversión (sobre todo inicial) y que debemos tener en cuenta que no es algo que se pueda usar siempre en el 100% de los casos, sino que tendremos excepciones y pruebas que debemos seguir realizando a mano. Para no engañarnos a nosotros mismos, ni a nuestros clientes, debemos tener bien presente qué secciones son potenciales a automatizar de nuestra aplicación y cuántas pruebas vamos a poder realizar en esas secciones de forma automática (teniendo en cuenta que, si una prueba se realiza y nuestra aplicación cambia, debemos realizar mantenimiento sobre esa prueba y actualizarla).
Tener en cuenta el tiempo inicial y la inversión que nos va a suponer.
Aunque a la larga la automatización es un proceso que nos va a ayudar y mucho, ya hemos comentado que la inversión inicial que requiere es alta, sobre todo en preparar el entorno, conocer herramientas de pruebas, integrar las pruebas con las herramientas de integración continua...
Debemos tener bien claro cuál va a ser el ROI y el Payback de nuestro proceso de automatización y que tanto la organización como tus clientes lo conozcan. Para visualizar un poco todo esto y entender mejor este proceso, os dejo un artículo de QA Técnico (así como una gráfica bastante visual) para comprender el ROI y Payback de las pruebas automáticas y entender mejor por qué necesitamos la automatización.
 |
| ROI y Payback de la automatización de pruebas. |
Elegir la mejor herramienta.
Otra de las bases que debemos tener clara y elegir correctamente es la herramienta que vamos a utilizar para realizar las pruebas automáticas. Por ejemplo, si tenemos una web y queremos automatizar pruebas funcionales, debemos ver qué herramientas nos pueden servir para ello, la principal herramienta de automatización web es Selenium (y también una de las más sencillas de aprender y en la que la comunidad tiene más apoyo). También están surgiendo nuevas herramientas basadas en Javascript como Jasmine, Nigthwatch... que pueden ser una solución útil para empezar nuestras pruebas automáticas.
Si queremos automatizar pruebas móviles, el rey de los frameworks disponibles (y mi favorito con diferencia) es Appium, una herramienta Open Source con bastante documentación y actividad de la comunidad y que sirve para automatizar pruebas tanto para iOS como para Android en aplicaciones nativas e híbridas. También para movilidad hay otras opciones, sobre todo para aplicaciones nativas, por ejemplo Espresso o Barista (para Android) o XCTest o KIF (para iOS).
Tiempo de los desarrolladores y cambio de mentalidad.
Una de las cosas que nadie cuenta en la automatización de pruebas y que es muy importante es la ayuda de los desarrolladores en este proceso. Para poder automatizar, los elementos de la pantalla con los que queremos interactuar deben tener un identificador único para poder trabajar con ellos (comprobar que son visibles, clickables, clickar en ellos, etc). Para ello tanto para web como para movilidad (especialmente para movilidad), el equipo de desarrollo ha de ayudar a la persona de QA que se dedique a la automatización, primero dedicando tiempo para poner estos identificadores únicos, y después a ayudarle a mejorar y encontrar elementos que pueden ser difíciles de acceder (sobre todo en movilidad). Esto va a requerir un compromiso y un cambio de mentalidad en el desarrollo para el equipo encargado de la aplicación como para la persona de QA dedicada a realizar los test automáticos.
Herramientas de Integración Continua.
Cuanto tengamos elegido tanto el framework como las pruebas y queramos empezar a realizarlas, debemos pensar también en tener preparado un buen entorno de integración continua.
¿Por qué necesitamos un entorno de integración continua? Primero para la compilación/despliegue de nuestras aplicaciones (tanto en movilidad como en web) para realizar este proceso sin error humano y de forma más rápida y segundo para poder conocer en todo momento la aplicación (número de versión y build concreto) que estamos probando.
Además de para el proceso de desarrollo, las herramientas de Integración Continua como Jenkins, Docker, Kubernetes... nos van a ayudar en el proceso de ejecución de pruebas. Para esto debemos tener un entorno limpio (de ahí la importancia de Docker en todo este proceso) donde poder lanzar las pruebas cada noche (para llegar a primera hora y encontrarnos las regresiones) sobre las aplicaciones que queramos automatizar. Estas herramientas no sólo nos ayudan a ser más ágiles sino a tener más visión (y más rápida) de los resultados de las diferentes ejecuciones de las pruebas automáticas que estemos haciendo.
Aunque suene a un proceso largo y, como hemos comentado, la inversión inicial es alta, la automatización te da, no sólo un beneficio a largo plazo para los desarrolladores y QA sino un cambio de mentalidad en todo el proceso tanto de desarrollo como de pruebas dentro de una metodología de desarrollo ágil.
Comentarios
Publicar un comentario