Desde hace más de 20 años, cuando recién iniciaban las transformaciones tecnológicas y operativas en los negocios, en Software Testing Bureau, ya nos especializamos en acompañar y asesorar a clientes de diversas industrias a probar sus soluciones, haciendo esta tarea de forma más eficiente y profesional.
Creemos firmemente que la optimización de resultados es a través de la automatización de pruebas de software. Con ellas los negocios pueden entregar a sus clientes soluciones probadas y confiables de forma más ágil, permitiendo implementar una mejora continua de cada proceso para darles la seguridad que se merecen.
Luego de años de trabajo, nos dimos cuenta que la automatización es generalmente aceptada, pero que aún hay muchos entornos en los que la consideran costosa o compleja. Es cierto que la automatización requiere planificación, pero no tener automatización puede ralentizar innecesariamente los ciclos de desarrollo:
Con esta nota me propongo derribar falsos paradigmas y temores que giran en torno a la automatización.
EL MITO
“El testing manual va camino a desaparecer” ES FALSO
LA VERDAD: El testing manual sigue siendo vigente y útil en muchos casos. En los proyectos ambas modalidades van de la mano y tienen criterios específicos dónde puede aplicarse mejor uno que otro. En general, los casos automatizados se implementan para pruebas complejas, o repetitivas, o aquellas de funcionalidad crítica, que requieran ser probadas siempre antes de cada liberación. Emplear la automatización en estos casos garantiza el ROI de la inversión en la construcción de la automatización y permite al equipo de pruebas ocuparse de la planificación, de la estrategia y de otras tareas. Es decir que se maximiza la capacidad de trabajo.
Existen herramientas de automatización, como STELA, que facilitan la creación de pruebas automatizadas desde los requerimientos sin requerir una aplicación funcional para comenzar a crear las automatizaciones, lo que permite tener un set de pruebas automatizadas desde el primer sprint.
EL MITO
“Grabar y reproducir es una forma fácil de hacer automatización” ES FALSO
LA VERDAD: Grabar y reproducir es una práctica poco eficiente para proyectos de vida media o larga. Esta práctica genera automatizaciones poco mantenibles y endebles, las que finalmente terminan siendo descartadas con poco uso en corto tiempo, generando un retorno de inversión negativo. Para proyectos con una vida media de 6 meses o más, es mejor invertir en la documentación del caso como paso previo a la creación de las automatizaciones. Sin embargo, existe la falsa creencia de ser una modalidad práctica para automatizar. Nuestra recomendación es que debería utilizarse únicamente como prueba de concepto para una herramienta o para proyectos de corta vida 0-3 meses y donde los activos de prueba generados no tengan un valor para entregarse al cliente o mantenerlos en la organización.
EL MITO
“La automatización es solamente para proyectos maduros con pocos cambios” ES FALSO
LA VERDAD: Existen herramientas que permiten construir automatizaciones de forma ágil, fácil y escalable, donde los cambios pueden incorporarse de forma sencilla. Es cierto que la automatización genera ROI cuando la misma se ejecuta repetidas veces a lo largo de la vida del proyecto y por eso existe la creencia que solamente se puede obtener el ROI con sistemas estables. Con algunas herramientas cada cambio en la aplicación requería obligatoriamente el mantenimiento de la automatización correspondiente y la dedicación de recursos especializados y costosos para hacerlo, pero actualmente existen tecnologías con motores de IA y la aplicación de técnicas de Visión Artificial que permiten una vida útil más alta de las automatizaciones sin requerir mantenimiento.
Hay herramientas muy potentes que son cero código, como STELA, que además incorporan ambas tecnologías, permitiendo generar pruebas automatizadas desde el inicio de los proyectos y asegurando un gran retorno de inversión, ya que su mantenimiento es muy sencillo o mantienen activas en muchos casos de forma automática, durante toda la vida del proyecto.
EL MITO
“Solo empresas grandes pueden implementar la automatización en sus proyectos” ES FALSO
LA VERDAD: Es cierto que las empresas con mayor porte son las que suelen implementar automatización de pruebas, ya que son las que poseen mayor terreno recorrido y posiblemente, capital para invertir. Pero lo cierto es que existen herramientas que sin ser open source, tampoco son costosas, ya que son muy fáciles de utilizar, no requieren recursos técnicos especializados, ni programación, haciendo que la automatización pueda estar al alcance de cualquier tipo de empresa y proyecto.
EL MITO
“Generar pruebas automatizadas requiere de un equipo especializado de programadores” ES FALSO
LA VERDAD: Existen herramientas que no requieren programación ni código, con las que los perfiles funcionales pueden automatizar. Las herramientas cero código como STELA pueden ser usadas por personas que no sepan programar, lo que permite ahorrar costos de RRHH, incrementando el ROI de la automatización. Esto a su vez permite accionar el Testing en diversas áreas de la organización, ampliando la capacidad a perfiles no técnicos de probar y verificar aquellos aspectos claves del negocio en diversos escenarios. De esta forma se habilita que los tester puedan provenir de áreas diferentes a TI y que su aporte genere valor en las instancias más tempranas de los proyectos. Pero hay un paradigma que cuesta desmitificar, donde se cree que la automatización solo puede hacerse por programadores o personal muy especializado. Esta creencia limita la posibilidad de considerar la potencia de la automatización como un modelo de testing viable para muchas industrias y negocios, sin importar su tamaño.
EL MITO
“Encarar un proyecto de automatización es más costoso y engorroso que hacer pruebas manuales” ES FALSO
LA VERDAD: Los pasos a seguir en una buena gestión del testing son los mismos. El tiempo dedicado a la construcción de la automatización con una herramienta amigable como STELA, es ampliamente compensado con el ahorro de tiempo de su ejecución, en relación a la prueba manual. El proceso para generar buenas pruebas que permitan liberar un software bien probado es el mismo, tanto si la ejecución de las pruebas es manual o automatizado y consiste de los siguientes pasos: