Tomado de:
http://www.javiergarzas.com/2015/01/automatizacion-pruebas.html
Excelente post de la página de Javier Garzas
Lo copio, pues lo considero de colección
--------
Hoy en día muchas empresas software, por su negocio quieren ser ágiles. Quieren sacar productos más rápido al mercado y adelantarse a la competencia, mejorando para ello la calidad de su proceso, producto y equipos software.
Una de las claves para agilizar ese proceso, detectar errores antes, en puntos del desarrollo en los que nos cueste menos solucionarlos y así desarrollar con más seguridad, es la optimización y automatización de ciertos procesos y pruebas (muy relacionado con
Integración Continua).
Sé que no es un cambio sencillo y que automatizar pruebas tiene un coste (lo vivo en el día a día, ya que Integración Continua, testing ágil, automatización de pruebas, son campos en los que trabajo en dentro
233 Grados de TI.).
No obstante, creo que con recursos limitados, sin automatizar ciertas pruebas es complicado llegar al testing ágil.
Dentro de este día a día, me da cada vez más la impresión, de que al igual que ocurre con la calidad de software en general, en ciertas ocasiones no se tiene muy claro qué implica la automatización de pruebas. Ni qué implica el
testing ágil.
De ahí que escuche cosas como:
– “Para el mes que viene estará todo automatizado, ¿no?”
– ¡Ah, genial! Si automatizamos las pruebas…¡Nos ahorraremos a los testers manuales!
– ¡Sí, automaticemos pruebas! Tú enséñanos a automatizar pruebas con eso de
Selenium, que le das al botoncito, tocas cuatro cosas y vas grabando lo que haces.
Pero la automatización de pruebas implica más que eso. Ahora verás por qué.
¿Automatizaremos todo? ¡Así nos ahorraremos el testing manual! ¿No?
Lo que automatizamos son chequeos, comprobaciones que los testers manuales previamente han detectado antes: ciertas pruebas de
regresión,
smoke test etc.
En este enfoque de testing, durante la evolución de un sistema, un caso de prueba comienza siendo manual, para luego ser automatizado.
Así los testers manuales pueden dedicarse a buscar otros bugs más complejos o testear nuevas funcionalidades.
Incluso puede haber ocasiones en las que automatizar alguna prueba o generar las condiciones necesarias para ello sea tan costoso, que sea más rentable mantenerla manual.
¿Y por dónde empezamos a automatizar?
Y dentro de lo que es el testing, existen distintos tipos de pruebas, cada una orientada a detectar y prevenir ciertos tipos de errores en el software.
Probablemente lo que primero suele venirnos a la cabeza cuando oímos hablar de automatización de pruebas son automaciones de “
record & play”, por ejemplo con herramientas tipo
Selenium IDE, que te permiten simular y grabar tus interacciones con la interfaz de la plataforma, con el navegador web etc.
Depende de qué plataforma, a primera vista pueden resultar las más sencillas de automatizar.
Es cierto que son automatizaciones necesarias, pero no son las que más retorno de inversión aportan, ni las que deberían automatizarse en mayor cantidad.
Principalmente, porque la interfaz de usuario es la parte más propensa a cambios de toda la aplicación, y para automatizar pruebas y tener fiabilidad sobre lo que estamos ejecutando necesitamos cierta estabilidad: un cambio en la interfaz podría hacer fallar la prueba automática, y en ese caso, tendríamos que readaptarla para que volviera a funcionar.
Por eso este tipo de pruebas suelen tener un coste de mantenimiento mayor que el resto.
Sí que tenemos que automatizar las pruebas de interfaz, pero mi consejo es que lo hagas después de haber automatizado otras partes más estables de la aplicación, el núcleo en sí, que aporta más retorno de inversión.
Por ejemplo, un buen primer paso es automatizar los test de API (funciones, elementos que ofrecemos desde nuestro software para que otro software, u otras partes del nuestro, puedan interactuar con él).
Hay varios niveles a la hora de automatizar pruebas. El secreto está en automatizar en el grado adecuado y en los niveles adecuados para nuestra aplicación.
Pirámide de Cohn.
La pirámide de pruebas de Mike Cohn, descrita en su libro Succeeding with Agile, ha sido un referente en este campo durante mucho tiempo.
En ella Cohn establece que hay varios niveles de pruebas, y señala el grado en el que deberíamos automatizarlas. Lo ideal sería:
– Muchos tests unitarios automáticos, porque un primer punto primordial para detectar fallos es a nivel de desarrollador. Si una funcionalidad en este punto falla, podrían fallar pruebas de los siguientes niveles: integración, API etc.
– Bastantes tests a nivel de API, integración de componentes, servicios, que son los más estables y candidatos a automatizar.
– Menos tests de interfaz gráfica automatizados. Ya que estos tests son variables, lentos en su ejecución y con muchas dependencias con otros componentes.
Aún así, en este punto, no suelo utilizar esas herramientas de record & play para automatizar pruebas de interfaz de usuario, ya que el código autogenerado por algunas de ellas no es muy mantenible (existen alternativas como
Selenium WebDriver, que hace lo mismo pero programando tu el código).
– Un nivel estable de pruebas automáticas, que vayan detectando los testers manuales y se vayan automatizando paulatinamente, para que llegue un momento en el que invirtiendo los mismos recursos logremos cada vez una cobertura mayor de pruebas.
Mala estrategia de automatización: el patrón del “cono de helado”
En la automatización de pruebas hay que tener cuidado, ya que en ciertas ocasiones se tiende a perder el foco y a invertir en automatización en el nivel y grado no adecuado.
Una mala estrategia en estos casos, es lo que llamamos el patrón “del cono de helado”.
Como ves es lo contrario a la pirámide de Cohn: centramos el foco en muchas pruebas manuales y en automatizar pruebas de interfaz de usuario, y nada de pruebas unitarias. Con todos los problemas que acarrea no detectar errores en los otros niveles y dejarlo todo para la parte más visible de la aplicación.
Además ten en cuenta, que una buena estrategia de automatización de pruebas conlleva más cosas que solo automatizar las pruebas en sí: crear un buen framework de automatización, parametrizar los tests, las ejecuciones para los distintos entornos, lanzar los test con distintos datos de prueba y gestionar dichos datos, sistemas de logs, buenos reportes con información que sirvan para obtener conclusiones, montar una buena infraestructura contra la que lanzar esos tests, paralelizarlos etc.
