Pages Menu
Categories Menu

Posted by on Jul 3, 2015 in General | 2 comments

¿Para automatizar pruebas necesitas saber programar?

En ciertas empresas cada vez más se escucha hablar de la automatización de pruebas (recuerda el post de “Vamos a automatizar pruebas”. ¿Qué significa esto? ¿Realmente por dónde deberíamos empezar a automatizar?), mientras que en otras ya es algo casi imprescindible, en mi opinión, siempre complementario al testing manual.

Para mí el dilema organizativo viene cuando se quiere empezar automatizar pruebas, pero partimos de la base de que en los equipos todos los testers son manuales (aunque no les importaría meterse en el mundillo de la automatización).

Entonces, ¿qué hacemos? ¿Qué empiecen a aprender a automatizar ellos solos? ¿Compramos una herramienta de record & play (éstas con las que puedes grabarte interactuando con la aplicación y así generar una prueba automatizada, sin saber programar, por ejemplo Selenium IDE u otras de pago), y nos olvidamos de jaleos de programación?

En mi opinión, poner a automatizar pruebas a testers manuales que no saben programar, sin ningún tipo de apoyo, guía o mentoring es un error. Y un error más grande aún es basar tus pruebas automáticas solo en una herramienta de record & play, sin pensar en el diseño de las pruebas, en su mantenimiento, sin definir una estrategia de automatización de pruebas, sin priorizar los componentes a automatizar, los tipos de pruebas, etc.

Para automatizar pruebas necesitas saber programar.

Desde mi experiencia, la automatización de pruebas requiere habilidades de programación, y normalmente suelo descartar el uso en exclusivo de una herramienta de record & play.

¿Por qué? Porque tener una batería de pruebas automatizadas es muy útil, pero a la vez es un tema que requiere bastante esfuerzo, sobre todo en su mantenimiento.

Nuestras pruebas automáticas no son personas, ejecutan los chequeos que les hemos programado, y son muy dependientes del software que prueban y de los datos de prueba. Si la parte del software que testea una prueba cambia, cosa normal y frecuente, el test automático fallará y tendremos que modificarlo.

Por ejemplo, imaginemos que hemos automatizado un proceso de compra en la web de Amazon con descuento, ya que en una de las etapas intermedias introducimos un código promocional en un espacio reservado para ello.

Ahora, por decisiones de negocio, en la nueva versión de la web se ha eliminado el espacio para introducir el código promocional, o aparece al final del proceso de compra (distinto a como habíamos programado el test). En este caso el test fallará y tendremos que cambiarlo.

¿Y si utilizo ciertos datos para mis tests automáticos y por el motivo que sea tengo que empezar a usar otros distintos? ¿Tengo que ir cambiando uno a uno los datos en los casos de prueba?

Además, normalmente necesitaré ejecutar los tests para varios entornos, varios navegadores, agruparlos por tipos y solo ejecutar algunos…¿Voy a cambiar todo eso test a test?

Estos son algunos ejemplos que demuestran que los tests automáticos tienen que ser lo más mantenibles posible: tienen que programarse para poder ser cambiados en el futuro fácilmente, con el menor coste. Y también tienen que ser parametrizables.

Aunque es cierto que cuando defines tu estrategia de automatización de pruebas uno de los criterios es empezar por las partes más estables del software, los tests tal cual los has programado hoy no van a funcionar siempre, están muy sujetos a cambios, porque el software que prueban también está sujeto a modificaciones.

Un buen diseño de pruebas y un buen framework de automatización que les den soporte son imprescindibles. Además de que hay técnicas de programación, patrones para automatización de pruebas, Orientación a objetos, abstracción, etc. que ayudan a diseñar las pruebas automáticas facilitando en la medida de lo posible los cambios que tengan que hacerse.

El problema es que la mayoría de herramientas de record & play generan tests muy frágiles, muy dependientes de los datos (muchas veces hardcodeados, insertados directamente en los scripts que generan), poco mantenibles, con código repetido, difíciles de integrar con tests de otras herramientas y con otras tecnologías.

Usar una herramienta de este tipo a corto plazo puede parecer genial, porque podemos automatizar ciertas pruebas rapidísimo, como churros. A largo plazo, tendremos muchas pruebas muy difíciles de cambiar, y con cada cambio invertiremos muchísimo tiempo y esfuerzo. Además, en muchas ocasiones esto puede hacer que introduzcamos fallos en las propias pruebas al cambiarlas.

En cambio, con gente que tenga una buena base de programación, y diseñando un framework de automatización y pruebas automáticas con el objetivo de que sean mantenibles y escalables, podemos ahorrarnos mucho coste de mantenimiento y facilitar los cambios a largo plazo.

¿Y qué hago entonces?

Si estás en el caso que comentaba al principio del post, queréis automatizar pruebas pero todos los testers del equipo son manuales, te preguntarás…¿Por dónde debemos empezar?

En el post del viernes que viene, te daré los consejos que mejor me han funcionado para fomentar perfiles mixtos, es decir, que los testers manuales poco a poco empiecen a aprender a automatizar pruebas, a la par que siguen diseñando y ejecutando pruebas manuales.

Ana M. del Carmen García Oterino

Ana M. del Carmen García Oterino

Ingeniera Software QA at BQ
https://www.linkedin.com/in/amgarciao

Apasionada por la calidad del software (procesos, producto y equipos) y buenas prácticas en general.

Especializada en testing, automatización de pruebas e integración continua.
Ana M. del Carmen García Oterino

2 Comments

  1. Estoy totalmente de acuerdo con el artículo. Si queremos diseñar nuestro propio framework de automatización será necesario saber programar, esto para mi es la base de una buena automatización.

  2. Hola, me encanto tu post. Ahora, que software libre puedo usar para codificar pruebas?

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This