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?
Como comenté en ¿Cómo enfoco el testing de forma ágil?, el objetivo de la automatización de pruebas no es eliminar por completo el testing manual, ni suplantar a los testers manuales.
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?
Por otra parte, la calidad del software tiene muchos ámbitos (Calidad del software es mucho más que el testing).
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.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
En este artículo tienen toda la razón, ya que la mayoría considera que las pruebas funcionales son las únicas que se pueden automatizar con herramientas como Selenium, Selenide, QTP, etc; pero hay que tener en cuenta que las pruebas unitarias a nivel de clases críticas, que tienen bastante dependencia en las funcionalidades de los aplicativos, es necesario validar su comportamiento con los tantos cambios que sufren. Hoy en día vivimos en una era donde los conceptos de SOA, MicroServicios, ESB, toman mayor fuerza, por ende, el automatizar la validación de estos se hace necesario.
Gracias por sus constantes aportes en esta materia.
Saludos
Interesante artículo
Ahora existen diversos tipos de pruebas que son necesarias y fundamentales en el desarrollo de software. Como indicas, los programadores deberían ser responsables del código que generan. He ahí la importancia de las pruebas unitarias que todo developer debe realizar. La detección temprana de errores ha demostrado que es mucho menos costosa que una en una etapa tardía.
Interesante artículo y un buen punto de partida para cuando se plantea automatizar parte del proceso de pruebas. Muchas veces vemos que se habla de automatización porque «es algo que está de moda», lo cual lleva a las compañías a tomar decisiones apresuradas, decisiones que tarde o temprano tendrán consecuencias que a veces resultan nefastas. Definitivamente es clave saber donde realizar verdaderos esfuerzos para automatizar y hacer que esta actividad sea generadora de valor para el proceso mismo de desarrollo y que los resultados obtenidos contribuyan a la toma de decisiones informadas.
En alguna parte leí una vez ,algo que decía: «Tenga cuidado, el hecho de tener un martillo en la mano, no convierte todas las cosas en un clavo».
Ínteresante artículo, por favor una ayuda,
ustedes me pueden ayudar que aplicación puedo utilizar para hacer automatización a aplicaciones de escritorio.. Gracias
Yo he usado Sikuli, es fácil de usar y se basa en el reconocimiento visual de los componentes de cualquier interfaz. La implementación de los script de sikuli se basa en actionScript, es decir, click(imagen indicando donde), write(imagen indicando donde).
Muy interesante tu articulo, tiene todos los temas básicos para iniciarnos en el mundo de las pruebas automatizadas.
En el mundo de la automatización de pruebas, es muy común para pruebas GUI o de interfaz de usuario usar el framework Selenium. Comparto link donde se encuentran todos los tutoriales de selenium en español. http://www.tutorialselenium.com
Coincido totalmente con el autor. Quisiera comentar que, en mi experiencia; desde que utilizamos pruebas psicotécnicas en mi empresa, ha habido mejores resultados con los trabajadores; pues hemos podido contratar equipos más capacitados para el cargo, y con aptitudes que
aportan mucho a toda el área. Gracias infinitas por compartirnos esta información