{"id":14466,"date":"2022-12-23T14:47:42","date_gmt":"2022-12-23T17:47:42","guid":{"rendered":"https:\/\/cl.abstracta.us\/blog\/?p=14466"},"modified":"2024-04-02T09:19:11","modified_gmt":"2024-04-02T12:19:11","slug":"automatizacion-shift-left-testing","status":"publish","type":"post","link":"https:\/\/es.abstracta.us\/blog\/automatizacion-shift-left-testing\/","title":{"rendered":"La importancia de la automatizaci\u00f3n en shift left testing"},"content":{"rendered":"\n

\u00bfCu\u00e1les son los beneficios del Shift Left Testing con la automatizaci\u00f3n de validaciones? \u00bfEs posible realizar Shift Left Testing sin automation? Encuentra las respuestas en este art\u00edculo, adem\u00e1s, 5 tips para implementar una estrategia Shift Left Testing de modo exitoso.<\/strong><\/h3>\n\n\n
\n
\"\"
Foto de Jan van der Wolf en Pexels<\/em><\/figcaption><\/figure><\/div>\n\n\n

Tal como ya ha quedado establecido en un\u00a0art\u00edculo<\/a> previo, shift left testing y shift right testing no son pr\u00e1cticas antag\u00f3nicas, sino complementarias, dado que plantean amplificar el foco de las pruebas en distintas direcciones<\/strong>. En este art\u00edculo, nos enfocaremos en shift left testing. Si bien no es la respuesta a todos los problemas de desarrollo de software,\u00a0en Abstracta consideramos crucial comenzar a realizar testing lo antes posible en el ciclo de desarrollo de un producto.<\/strong><\/p>\n\n\n\n

La explicaci\u00f3n de esto es simple: es m\u00e1s rentable revelar y corregir los defectos y otros problemas antes que despu\u00e9s. Tambi\u00e9n respalda el esp\u00edritu de \u201cfallar r\u00e1pido y arreglar r\u00e1pido\u201d, lo cual ayuda a eliminar las inestabilidades del c\u00f3digo y a mejorar la calidad.<\/p>\n\n\n\n

Asimismo, facilita el agregado de validaciones en las distintas etapas del desarrollo de producto, no solo resolviendo los problemas de hoy, sino que mejorando el proceso y evitando posibles errores a futuro.<\/p>\n\n\n\n

\u00bfC\u00f3mo implementar shift left testing?<\/strong><\/h2>\n\n\n\n

Para la implementaci\u00f3n de shift left testing, es conveniente tambi\u00e9n trabajar en la automatizaci\u00f3n de validaciones en un marco de Continuous Integration, e idealmente en un marco pr\u00e1ctico de\u00a0CI\/CD<\/a>.<\/strong><\/p>\n\n\n\n

Gracias a implementar integraci\u00f3n continua, incluyendo pruebas automatizadas en un pipeline, podemos obtener feedback de las mismas en cada incremento de producto. Esto b\u00e1sicamente implica automatizar en mi proceso de construcci\u00f3n de software la ejecuci\u00f3n de pruebas autom\u00e1ticas y ganar la habilidad de detener este proceso cuando ciertas pruebas fallan.<\/p>\n\n\n\n

De este modo, es posible detectar errores m\u00e1s temprano y disminuir los costos de la creaci\u00f3n de software, con la posibilidad de repetirlo la cantidad de veces que sea necesario hasta que no fallemos m\u00e1s, para lograr un incremento de producto dado en nuestro sprint.<\/p>\n\n\n\n

La pr\u00e1ctica de shift left testing se beneficia mucho de la automatizaci\u00f3n debido a que automatizar nos permite ganar tiempo\u00a0<\/strong>validando cosas que ya sabemos (por eso es bueno hablar de validaciones autom\u00e1ticas y no pruebas autom\u00e1ticas). Esto nos da tiempo para hacer un mejor testing manual y descubrir lo que no sabemos, as\u00ed como conocer los riesgos y problemas que pueden impactar al usuario final y pasar inadvertidos.<\/p>\n\n\n\n

\u00bfQu\u00e9 tan temprano comenzar a probar?<\/strong><\/h2>\n\n\n\n

Muchas veces nos han preguntado para qu\u00e9 asociarse con Abstracta o requerir de nuestros servicios de testing si a\u00fan no hay un producto terminado. Podr\u00eda parecer que es muy ineficiente involucrar el testing desde fases tan tempranas del ciclo de desarrollo, pero es al rev\u00e9s. Cuanto m\u00e1s tarde se hallen los bugs, m\u00e1s caros resultan.<\/p>\n\n\n\n

Seg\u00fan Business Wire<\/a>, el 88% de los estadounidenses tiene sentimientos negativos hacia las marcas con sitios web y Apps m\u00f3viles de bajo rendimiento. Estos sentimientos negativos est\u00e1n asociados a la molestia, la frustraci\u00f3n, la desconfianza y el enfado.<\/p>\n\n\n\n

Como evidencia de ello, el informe \u201cThe Cost of Poor Software Quality in the US\u201d <\/strong>CISQ<\/strong><\/a> 2020 revel\u00f3 que el coste total de la mala calidad del software en Estados Unidos fue de 2,08 billones de d\u00f3lares (T) en 2020.<\/strong><\/p>\n\n\n\n

En este contexto, muchas personas que se encuentran alineadas a la idea del shift left testing se preguntan si es posible realizar pruebas en etapas tempranas y cr\u00edticas para la definici\u00f3n del producto, como las etapas de dise\u00f1o y desarrollo, o si es necesario utilizar un enfoque diferente.\u00a0\u00bfQu\u00e9 tan a la izquierda se puede ir? En mi opini\u00f3n, considero que depende de tus necesidades, contexto, equipo y m\u00e1s.<\/strong><\/p>\n\n\n\n

Sin dudas, es importante validar el dise\u00f1o y la arquitectura de una aplicaci\u00f3n, pero muchas veces hay errores que se hacen notorios con el tiempo. Por ejemplo, a veces puede tomar un par de a\u00f1os notar el impacto de que hiciste un dise\u00f1o o arquitectura incorrectos para la escala (volumen de usuarios o de datos) que tiene que atender el sistema.<\/p>\n\n\n\n

Sin embargo, siempre es importante tener instancias de validaci\u00f3n y feedback desde el d\u00eda cero. Realizar testing de software desde el inicio puede disminuir mucho los costos y riesgos, aumentar la eficiencia, la calidad e incluso ser una ventaja competitiva.<\/strong><\/p>\n\n\n\n

Cuando hablamos de considerar el testing en etapas m\u00e1s tempranas, hay que pensar en varias cosas. Primero en todo lo relacionado al testing funcional (testing exploratorio combinado posiblemente con casos de prueba, gesti\u00f3n de incidentes, requerimientos y criterios de aceptaci\u00f3n, etc.)<\/p>\n\n\n\n

\u00bfCu\u00e1ndo es recomendable el testing automatizado?<\/strong><\/h2>\n\n\n
\n
\"\"
Foto de Miguel \u00c1. Padri\u00f1\u00e1n<\/em><\/figcaption><\/figure><\/div>\n\n\n

Luego, es recomendable definir qu\u00e9 automatizar, para lo cual se suele utilizar modelos como la pir\u00e1mide de automatizaci\u00f3n pensando cubrir los distintos niveles, priorizando las pruebas que entreguen mayor ROI en menor tiempo en cada fase del desarrollo. Adem\u00e1s, podemos pensar en realizar una evaluaci\u00f3n<\/a> de otros atributos de calidad, por ejemplo con pruebas no funcionales, como performance, usabilidad, accesibilidad y seguridad.<\/p>\n\n\n\n

Por ello, la automatizaci\u00f3n es un aliado fundamental a la hora de seguir un enfoque de shift left testing. Sin dudas, dise\u00f1ar buenas estrategias de pruebas, que contemplen las automatizaciones adecuadas, es crucial para crear cada vez mejor software y de manera m\u00e1s eficiente.<\/p>\n\n\n\n

5 claves para implementar exitosamente una estrategia de shift left testing<\/strong><\/h2>\n\n\n\n