top of page

Rompiendo mitos: ¡La automatización de pruebas siempre mejora todo!

Foto del escritor: Ever CurielEver Curiel

Actualizado: 26 jun 2021

Uno de los mitos que andan en el mundo de la calidad de software, es que la automatización de pruebas es una bala mágica que elimina todos los problemas del software testing, sin embargo, esto no es tan real como parece...


Imagina que un día vas caminando por la calle y te encuentras a un viejo amigo que tenias mucho tiempo sin ver, se detienen a conversar y te cuenta sobre este increíble secreto que lo ha ayudado en su vida profesional, un gran gurú de las ciencias le confió ese secreto y desde entonces su vida ha sido más fácil. Tú, un poco incrédulo pero curioso, le comentas que te gustaría que te comparta ese secreto para aplicarlo en tu trabajo, al final, ambos son testers.


Tu amigo se muestra un poco renuente al principio, pero al final cede, saca una pequeña hoja del bolsillo izquierdo de su pantalón y un lapicero del bolsillo de su camisa, escribe una palabra y luego dobla el papel con cuidado y te lo entrega. Mirandote a los ojos te dice, solo debes abrirlo cuando estés ante un reto profesional, recuerdalo.


Dos semanas después te encuentras en tu trabajo en el kick off de un nuevo proyecto y te piden tu opinión en relación al proceso de aseguramiento de la calidad de software. Nervioso, recuerdas que aún tienes aquel papel doblado en el pantalón, lo sacas y cuando lo abres, esta escrito: AUTOMATIZA!


Te llenas de valor y das la respuesta del papel en la reunión...todos te miran por unos segundos y de repente, están de acuerdo contigo y muy felices, ¡eso querian oir! ¡Vaya! el gran secreto te ha salvado... ¿o no?


Por definición un mito es:


Historia imaginaria que altera las verdaderas cualidades de una persona o de una cosa (en este caso un procedimiento) y les da más valor del que tienen en realidad.

Sobre la automatización de pruebas al igual que muchas tecnologías y metodologías, se tejen redes de mitos a su alrededor. Es tanto así que luego de un tiempo se complica distinguir la verdad de lo que es solo una opinión errada y muchos terminan creyendo que es una respuesta milagrosa que aplica a todos los proyectos y situaciones que pueden surgir en el proceso de aseguramiento de la calidad de software. Ahí creo que radica un gran problema que pudiera afectar los equipos de profesionales que se dedican a SQA.


Por lo anteriormente mencionado, hoy quiero compartirles un análisis sobre uno de los mitos de la automatización de pruebas:


Las pruebas automatizadas siempre resultan en mejoras sobre la calidad de software.


Este es un mito que ha sido propagado de forma rápida y a veces involuntaria, donde los profesionales de la calidad de software asumen que la automatización de pruebas garantiza una mejora sobre los procesos de aseguramiento de la calidad y por ende trae como consecuencia que el nivel de calidad del producto de software crezca de forma automática.


Si eres parte del mundo de la calidad de software entonces sabes que el buzz del momento es automatización, en sus diferentes vertientes, frameworks, tecnologías y sabores. Pareciera que todo el impulso y hambre de conocimiento de los tester está enfocado en aprender a automatizar, es como si fuera la máxima expresión del conocimiento en relación al software testing.


Esto me acuerda a esa escena en la pelicula de matrix de 1999, donde Neo tiene que aprender a pelear y para ello lo conectan a "la matrix" en un programa de simulación de peleas y le descargan todos los conocimientos a su cerebro para que aprenda Kung Fu.


En nuestro caso particular haciendo un símil, pareciera que la mayoría de tester están gritando para que los conecten, poder descargar el conocimiento de automatización y luego abrir dramáticamente sus ojos y decir "Ya se automatizar"



No me malinterpreten, soy alguien que va en pro de la automatización con criterio, y claro que promulgo que las personas deben de obtener estos conocimientos, pero la verdad es que después de esta escena, Neo aún así fue vencido, porque ese conocimiento no era el "todo" para poder cumplir su misión. Era solo una parte importante de su set de conocimientos para convertirse en "El elegido".


Muchas veces, como si se tratara de un encantamiento cual cuento de hadas o de una varita mágica de Harry Potter, muchos equipos de calidad de software asumen erróneamente que la automatización de las pruebas trae mejoras por defecto sobre cualquier proyecto y que es una bala de plata que mata todos los problemas en relación a la calidad. Este es un error que le puede costar muy caro a un proyecto de software.


Dichos equipos pueden terminar con mentalidades como la de nuestro amigo imaginario al principio del articulo, donde aparentemente la respuesta a todo es...


  • Queremos que el proyecto salga rápido : Automatiza

  • Queremos que se pruebe todo : Automatiza

  • Necesitamos que se pruebe a profundidad los requerimientos: Automatiza

  • Hay que probar una aplicación que nadie conoce: Automatiza

  • Este proyecto es bien pequeño, no necesitamos... Automatiza!


¿Ven el problema?


Cuando un mito como este se asume como verdad y escala hasta integrarse en las líneas críticas de toma de decisión en una organización, puede tener un impacto negativo en los tiempos de entrega, presupuesto e incluso el nivel de aseguramiento de la calidad de software puede disminuir en lugar de aumentar. Esto ocurre porque se enfocan en automatizar algo que necesariamente no cumple con los criterios para ser automatizado (si, no todo se automatiza) o peor aún no se aseguran de que las bases analiticas que preceden dicha automatización sean tan sólidas como los deseos de automatizar.


En esa misma nota, cuando tomamos la automatización como único escudo insignia de nuestro equipo de calidad, pueden comenzar a darse casos que realmente, de forma personal, los encuentro preocupante. Por ejemplo, el equipo comienza a conectarse a "la matrix" y cada día aprenden más frameworks y tecnologías para automatizar, pero sus fundamentos en calidad de software y análisis no son sólidos ni tienen proyección a mejorar, ahora están convirtiéndose en programadores que conocen más frameworks pero no en mejores ingenieros de calidad. Terminan automatizando rápidamente unos casos de pruebas muy mal elaborados y con un nivel de análisis sobre el producto de software que deja mucho que desear.


De las peores cosas que les puede pasar a un equipo de calidad de software es descuidar la esencia del análisis sobre su trabajo y pensar que las tecnologías de automatización pueden cubrir la falta de pensamiento crítico a la hora de construir suite de pruebas que aseguren un nivel de calidad madura sobre el producto de software con el que están trabajando.


Se automatiza lo que que ha sido bien pensado, analizado y estructurado, es en ese momento cuando tendremos una oportunidad de que la automatización nos agregue valor en el tiempo.

Donde no hay un buen trabajo de análisis crítico sobre los requerimientos de un producto de software, no hay herramienta o proceso de automatización que por toque mágico mejore los resultados finales,

mientras más depende un tester de una herramienta para verificar la calidad de un software, mayor criterio analítico deberá tener el mismo para ser menos propenso a que los bugs que otro no capto afecte su trabajo.

Quiero cerrar el análisis y con suerte, la aclaración de este mito, compartiendoles las palabras de uno de mis public speaker favoritos, Jim Rhon, quien fuese un empresario estadounidense, autor y orador motivacional.



"La motivación no siempre es la respuesta a todo, si tienes a alguien tonto en tu equipo y lo motivas, ahora tienes a un tonto motivado, eso no es bueno para el equipo..."


Partiendo de esta gran cita, me gustaría ser un poco atrevido y traducir esta misma línea de pensamiento al contexto de la automatización de pruebas y establecer lo siguiente:

La automatización no siempre es la respuesta a todo, si tienes criterios difusos junto a una suite de prueba mal elaborada y la automatizas, ahora tienes un desastre automatizado, eso no es bueno para el equipo...

Espero que este escrito te haya arrojado un poco de luz sobre un mito tan comúnmente vendido y comprado. Como profesionales del aseguramiento de la calidad de software siempre procuremos no ser unidimensionales en cualquier aproximación que tomemos para solventar problemas y analicemos todo en el contexto del proyecto que nos toque trabajar.


Comments


  • Blanco Icono de Spotify

La escuela del testing todos los derechos reservados

bottom of page