Cómo Low-Code permite pruebas continuas en DevOps

Hola a todos. Bienvenidos. Hoy hablaremos sobre cómo Low Code permite la prueba continua y DevOps. Es genial estar aquí con todos ustedes hoy. Mi nombre es Juliet McVail, y soy Gerente de Producto en Navel, que es una solución de prueba de bajo código inteligente. Llevo aproximadamente 2 años y medio en Navel, y actualmente soy la Gerente de Producto de nuestro equipo de pruebas de navegador y API. Y eso realmente se enfoca en la creación y ejecución de pruebas tanto en el navegador como en las API.

Entonces, en esta charla, me enfocaré en tres puntos clave. El primero es que la automatización de pruebas es realmente fundamental en cualquier esfuerzo para tener éxito en DevOps. El segundo es una afirmación de que los enfoques aislados para la automatización de pruebas no funcionan. Y finalmente, que la automatización de bajo código nos permite eliminar estos silos y producir mejores resultados en nuestros esfuerzos de ingeniería de calidad. Así que vamos a sumergirnos.

Primero y ante todo, es realmente emocionante ser alguien que se centra en la ingeniería de calidad porque hay tantas tendencias críticas en la industria. Y también nos estamos dando cuenta de que la ingeniería de calidad desempeña un papel fundamental en esto para habilitar la innovación. Ya sea que esté buscando ampliar su adopción de ágil o DevOps, tal vez su equipo quiera migrar a la nube o avanzar hacia la izquierda. La ingeniería de calidad es realmente un habilitador para todas estas tendencias clave. Y en última instancia, lo que estamos tratando de hacer en el software hoy en día es acelerar el ritmo de la innovación con calidad. Realmente queremos una alta velocidad y rendimiento en estos pipelines, y queremos poder crear e implementar cambios constantemente. Ya sea a través de código o configuración, o actualizaciones, o incluso lidiar con un cambio que está ocurriendo con sus socios integrados, porque es probable que consuma muchos servicios a través de API de terceros. Y queremos poder abrazar ese cambio con velocidad y rendimiento. Y ahora eso también debe estar bajo la atenta mirada de un sistema que pueda garantizar la calidad. Y ahí es donde entra en juego la automatización de pruebas. Y sabemos que tenemos éxito en la implementación de la automatización de pruebas cuando tenemos un alto nivel de automatización, pero también tenemos una gran confianza en nuestra capacidad para implementar cambios con buena calidad. Este es realmente un punto interesante. Y también es el problema que vimos en el informe de DevOps del año pasado. Sabemos que tenemos un bajo nivel de, cuando tenemos un bajo nivel de automatización de pruebas, también tenemos relativamente poca confianza en nuestra capacidad para implementar cambios. Y a medida que aumenta ese nivel de automatización de pruebas y despliegue, podemos ver que la confianza también aumenta. Y esto es realmente clave a medida que nos acercamos a un modelo de pruebas continuas. Porque a pesar de que sabemos que queremos llegar a este alto nivel de automatización, para tener confianza al lidiar con todos esos cambios, muy pocos equipos han alcanzado el nivel de automatización necesario para implementar con confianza. Y tenemos trabajo por hacer para llegar allí. Y realmente, el riesgo aquí es que si no lo logramos, no logremos esta visión de esos pipelines de alta velocidad y alta calidad. Porque lo que tenemos que hacer aquí es reducir la velocidad para gestionar la calidad. Y eso significa que tenemos una capacidad limitada para verificar esos cambios desde una perspectiva de control de calidad. Y este es el riesgo de que terminemos teniendo este cuello de botella, a pesar de que ha habido tanta innovación en este aspecto. En realidad, no podemos tener ese rendimiento.

Entonces, cuando hablo de intención, me refiero realmente a probar las cosas que buscarías si lo hicieras manualmente, y podemos separar eso de la automatización. Entonces, cuando la intención se manifiesta en la propia prueba, la automatización puede impulsar la ejecución de la misma. Y en realidad dejamos que Mable se encargue de esta parte. Entonces, cuando permitimos que los equipos se centren en la intención y la funcionalidad que desean compartir, les presentamos una interfaz de low-code y luego dejamos que el sistema se encargue de esa implementación. Y lo que eso significa es que no solo los desarrolladores, sino también los probadores manuales, los propietarios de productos, el personal de soporte y otros pueden participar en la calidad, y no terminamos en silos.

Otro aspecto de esto es que una vez que separas la intención de la implementación, podemos construir un sistema muy inteligente. Como ejemplo, digamos que la intención de una prueba es enviar un formulario y hay un botón de enviar en ese formulario. Tal vez mi equipo esté buscando hacer algunos cambios y terminen cambiando el ID de ese botón de enviar. Con soluciones de automatización de pruebas más tradicionales, una prueba fallará porque se basó en el ID para localizar el botón. Pero en esta nueva era, dado que estamos recopilando tanta información mientras ejecutamos las pruebas, el sistema sabe que aunque el ID haya cambiado, el botón sigue estando allí y realmente podemos localizarlo utilizando numerosas técnicas y atributos diferentes. El sistema intentará localizar ese botón y continuar con la prueba. Y cuando podemos identificar correctamente que un elemento ha cambiado, actualizaremos automáticamente la prueba en función de la información que aprendimos. Y eso es lo que llamamos auto curación. Por lo tanto, podemos lograr esto al separar la intención de la implementación, permitir que el sistema se encargue de esa implementación y permitir que las personas expresen su intención con la menor cantidad de código posible. Lo otro importante a tener en cuenta es que muchos equipos han pasado años desarrollando marcos de automatización de pruebas basados en scripts sofisticados. Y no queremos perder ese trabajo. Y con Mable, puedes importar cualquier prueba existente de Selenium que tu equipo pueda tener y exportar esas pruebas a Selenium IDE. Esto realmente te permite evitar el bloqueo del proveedor y aprovechar el arduo trabajo que ha realizado tu equipo e incorporar inteligencia y aprendizaje automático en la ejecución de estas pruebas. Y eso es realmente el lado tecnológico del low-code más la inteligencia. Y eso nos da la capacidad de resolver muchos de los problemas que hemos visto con la automatización de pruebas en el pasado. Sin embargo, solo la mitad de la tecnología por sí sola es realmente insuficiente. Porque donde veremos los beneficios de esto es cuando podamos implementar estas soluciones a nivel organizativo. Y adaptarlas en los lugares correctos con los roles adecuados. Y si no lo hacemos, en realidad veremos muchos fracasos con estas iniciativas, a pesar de que la tecnología está ahí. Entonces, como has visto en DevOps, la visión aquí es realmente construir una automatización inteligente desde el principio hasta el final del pipeline.

Y eso comienza cuando estás trabajando en una rama local para una función o un cambio. Y eso realmente va hasta la producción y ese cambio realmente llega a la producción. Hoy vamos a hablar de cada una de estas diferentes etapas. Y te proporcionaré algunos ejemplos de lo que quiero decir cuando digo que realmente se trata de averiguar quién hará qué en esa etapa.

Entonces, comencemos con la base de código que está local en la máquina de un desarrollador. El objetivo de esta etapa es tener cambios funcionales. Por ejemplo, puedo crear una nueva función que deseo validar antes de fusionarla con la rama principal. En esta etapa, también queremos asegurarnos de tener una cobertura de pruebas integral. Por lo tanto, es posible que no probemos todos los escenarios para esta función, pero estamos probando el flujo principal. Desde una perspectiva de calidad, en esta etapa también queremos tener un plan. Queremos saber qué pruebas necesitamos hacer en el futuro, qué cobertura ya tenemos, cuál es el riesgo, y así sucesivamente, para que podamos permitir que nuestro equipo realice esos cambios.

Para dar algunos ejemplos, en esta etapa creemos que los desarrolladores que están realizando esos cambios deben ejecutar un conjunto de pruebas iniciales de extremo a extremo localmente. Si estás utilizando Navel, puedes usar la interfaz de línea de comandos de Navel, y si tu equipo ya está utilizando Jest, puedes automatizar esto a través de la interfaz de línea de comandos para que suceda en cada confirmación. Eso significa que si tienes un conjunto de pruebas relacionadas, puedes ejecutarlas de manera discreta. Tenemos algunas pestañas en segundo plano para informarte si tus cambios están rompiendo alguna prueba existente y si esas pruebas están encontrando defectos. Pero mientras aún estás trabajando localmente, el objetivo sería saber si estás rompiendo alguna de las tareas principales de tu aplicación y si esas pruebas te ayudan a descubrir si estás introduciendo regresiones. Este proceso puede ocurrir de manera fluida ejecutando esas pruebas en la línea de comandos automáticamente. Y lo que es realmente importante destacar es que esto no se limita solo a los desarrolladores de tu equipo. Si tienes un ingeniero de calidad que trabaja en conjunto con un desarrollador, ese desarrollador puede enviar su rama directamente a GitHub, y el ingeniero de calidad puede descargar esa rama, ejecutarla localmente y comenzar a sentirse más cómodo con esos cambios. Además, durante esta fase, también podemos crear una rama para ese conjunto de pruebas en Navel y probar esos cambios que estarán relacionados con la rama de código. Como puedes ver en este ejemplo específico, tengo mi rama y tengo algunas pruebas que he creado o modificado para que estemos listos cuando lleguemos al siguiente paso. Y antes de hacer eso, también querremos saber cuánto trabajo queda desde una perspectiva de pruebas en relación con esta función. Por ejemplo, si estuviera trabajando en una función de Espacio de trabajo, querría saber qué otras pruebas están relacionadas con esta función. Es probable que tenga que cambiar alguna de esas pruebas para tener una cobertura de pruebas adecuada. Y en la siguiente etapa, ¿quiero agregar pruebas adicionales aquí? Con una herramienta como Mable, ya tenemos una función de cobertura donde puedes buscar básicamente por página y ver qué pruebas tienes relacionadas con esa página. ¿Son buenas esas pruebas? ¿Tienen suficientes afirmaciones? ¿Validan eficazmente la funcionalidad de esa página? Puedes usar esa función cuando estemos en la etapa de codificación para tener una idea de qué cambios puedes querer hacer a medida que avanzamos.

Entonces pasemos a lo que creo que es el punto más crucial en el proceso para un equipo orientado a DevOps. Y ese es el momento de una solicitud de extracción. Es decir, tengo un conjunto de cambios, tanto desde una perspectiva de pruebas como desde una perspectiva de código, que propongo fusionar en nuestra rama principal. También tenemos algunos objetivos aquí. El primero es que no quiero implementar o fusionar algo de inmediato sin suficientes pruebas.

Porque una vez que llegamos a esa rama principal, por defecto y en la mayoría de los equipos, está en camino hacia el resto de un proceso automatizado para nuestro flujo de trabajo. Por lo tanto, el primer objetivo aquí realmente es no fusionar algo que sabemos que va a detener nuestro flujo de trabajo. Y al salir de esta etapa, también queremos asegurarnos de tener una cobertura de pruebas integral que esté relacionada con mi cambio. Y finalmente, y quizás de manera más sutil, también queremos saber que estamos preparando al equipo para el éxito a largo plazo. Hablaré más sobre eso en un momento. Pero antes de todo eso, asegurémonos de no romper nada antes de fusionar esto en la rama principal.

En este ejemplo particular, digamos que tenemos un conjunto de pruebas de humo de Mable que se ejecutan automáticamente y de forma continua como parte de nuestro proceso de compilación. Tan pronto como envíes tu solicitud de extracción, se ejecutarán un conjunto de pruebas de humo sin interfaz gráfica. Y si la compilación falla, no podrás fusionar esa solicitud de extracción ni obtener la aprobación. Así que sabrás que estás pasando esas pruebas básicas y todo está automatizado.

Como otro ejemplo, cuando hablé de una cobertura de pruebas efectiva, el uso de un marco de bajo código como Mable permite que cualquier persona participe en la revisión y proporcionar comentarios sobre la lógica de las pruebas. ¿Está estructurada correctamente la prueba? ¿Estamos validando completamente la funcionalidad con las afirmaciones correctas? Y puedes ver aquí que es intuitivo. Cualquiera puede revisar esta prueba y entenderla. No es necesario entender necesariamente los matices del marco o tener un trasfondo de desarrollo. Por lo tanto, realmente podemos evitar los silos aquí también. Pero también hay un área en este tipo de automatización donde el conocimiento especializado es definitivamente importante, especialmente en enfoques de reutilización, configuración, desmontaje, entornos y las mejores prácticas generales de cobertura de pruebas. Y eso es importante para asegurarnos de prepararnos para el éxito a largo plazo. Y este es un momento en el que realmente puedes tener experiencia en automatización en el equipo. Tal vez tengas un líder central de automatización que también participe aquí, y pueden trabajar con tus diversos equipos para asegurarse de que no estemos incurriendo en deuda técnica.

Otra cosa que podemos hacer en esta etapa, desde una perspectiva de colaboración, es ejecutar las pruebas de regresión que se hayan creado antes de esta versión. Y podemos hacer todo eso directamente en nuestro flujo de trabajo. Entonces, si tu equipo utiliza entornos de vista previa o entornos efímeros, donde subes tus cambios para la solicitud de extracción, podemos ejecutar esos conjuntos completos de pruebas de regresión y pruebas en varios navegadores en esa etapa. Y de esta manera, podemos obtener toda esa información dentro del contexto de la solicitud de extracción en sí. Y antes de aprobar ese cambio o fusionar esos cambios en la rama principal, puedo y también puedes revisar todas las pruebas que se han realizado en todo el código, incluido si validamos nuestros escenarios principales. Y también puedes hacer clic directamente en los detalles desde la solicitud de extracción también.

Luego, pasaremos a nuestra etapa de implementación. Y digamos que sabemos que todo parece estar bien en cuanto a la funcionalidad principal en el código. Hemos fusionado esos cambios en nuestra rama principal. Ahora todo esto realmente está en nuestro flujo de trabajo automatizado. Y por lo tanto, el objetivo aquí es asegurarnos de no permitir defectos en producción.

Queremos asegurarnos de tener pruebas integrales relacionadas con nuestros cambios antes de que se implemente cualquier de esto. Y también queremos tener una comprensión más amplia de la calidad más allá de aprobar o fallar. Y eso incluye una comprensión integral del cambio y su impacto en la calidad en general.

Entonces, también hay un par de ejemplos aquí. El primero es en esa etapa, asegurémonos de poder identificar problemas y solucionarlos lo más rápido posible. Digamos que aquí tenemos una prueba fallida y habilitada. En realidad, tenemos un botón donde puedes crear un problema en JIRA directamente desde los resultados de tu prueba. Y cuando creas ese problema en JIRA por una falla en la prueba o un informe de error, puedes ver que automáticamente se completa toda la información que un desarrollador necesita para entender el problema. Y eso incluye la captura de pantalla, el archivo HAARF, la instantánea del DOM para asegurar que haya una comprensión del estado del producto durante esa falla de prueba. Y esto también te permite evitar cualquier ida y vuelta innecesaria entre compañeros durante el proceso de solución de problemas e investigación.

Entonces, a continuación, pasemos de las pruebas aprobadas y fallidas a desarrollar realmente una visión compartida en todo el equipo en términos de calidad. Tal vez detectemos automáticamente otros problemas de calidad, incluso cuando las pruebas pasan, como errores de JavaScript en nuestra consola después de nuestra última implementación, ¿tenemos enlaces rotos en la aplicación que formaban parte de esas pruebas? Y para cada prueba, también podemos ver en todos los pasos cuál fue el tiempo total de carga de la página y cómo está evolucionando. Entonces, en esta prueba en particular, podemos ver que tardó aproximadamente un 20% más de tiempo de lo que normalmente tarda, lo que nos permite identificar tendencias y problemas de rendimiento temprano.

Entonces, aquí hay un ejemplo de lo que podemos hacer en esta etapa para enfocarnos realmente en expandir la cobertura. Es probable que todos estén familiarizados con el concepto de pruebas basadas en datos. Y una vez que tu prueba realmente existe, con solo unos pocos clics, puedo agregar una variedad de diferentes escenarios que quiero probar utilizando tablas de datos habilitadas. Y eso no requiere escribir ningún código. Y realmente me permite multiplicar la cobertura que tengo. Entonces, agregar nuevos escenarios es tan simple como agregar una nueva fila a esta tabla y escribir valores adicionales. Y nuevamente, esto se enfoca en hacer que las pruebas sean más accesibles. Incluso como una persona de producto, puedo contribuir fácilmente a esto. Otra aspecto emocionante de esto es que sin escribir ningún código, también puedes aprovechar bibliotecas como Faker o Math.js. Y esto te permite aleatorizar tus datos para aumentar la cobertura de prueba creando datos realistas que puedes adaptar a tus casos de uso o escenarios específicos. Lo cual es especialmente útil si estás probando varios campos de entrada o buscando generar datos de prueba. Y también podemos ampliar la cobertura en diferentes dispositivos. Tal vez esté buscando probar una aplicación responsiva. Entonces, no solo nos enfocamos en probar en los principales navegadores. También estamos probando en diferentes dispositivos. Y revisando esos cambios en un servicio de pruebas inteligente para confirmar que mi aplicación responde adecuadamente. Y realmente, probar en dispositivos móviles es más crítico que nunca.

En 2020, más del 60% de las visitas a sitios web en Estados Unidos se originan en dispositivos móviles. Y históricamente, las pruebas móviles no son una tarea fácil. Mable permite que tu equipo valide la experiencia del usuario en aplicaciones responsivas y brinde una experiencia fluida para tus usuarios, independientemente del dispositivo que utilicen. Y, con los beneficios del bajo código, este es otro buen ejemplo en el que no es necesario tener una experiencia de automatización altamente especializada. Por lo tanto, espero que estos sean algunos buenos ejemplos de cómo herramientas inteligentes de bajo código como Mable pueden ayudar a que todo el equipo participe en la calidad, lo cual te ayudará a obtener una cobertura de pruebas automatizadas y la confianza que necesitas para innovar rápidamente. Y muchos equipos están en este camino actualmente. También nos entusiasma mucho ver cómo muchos equipos obtienen un beneficio de orden de magnitud en términos de lograr una mayor cobertura de pruebas y reducir la carga de mantenimiento asociada con las pruebas y, en general, reducir la cantidad de esfuerzo que dedican a las pruebas de regresión. Esto es realmente hacia donde estamos trabajando. Buscamos facilitar la transición a DevOps mediante la integración profunda de las pruebas en tus flujos de trabajo, asegurándonos de que sea rápido y flexible para todo el equipo que trabaja con pilas modernas, ya sea que estés ejecutando en CI/CD, utilizando frameworks de aplicaciones de una sola página o de otra manera, para que todos en el equipo puedan participar en la calidad. También queremos asegurarnos de que las pruebas que construimos sean robustas y confiables. Al incorporar el aprendizaje automático y la inteligencia en la automatización, las pruebas pueden seguir desarrollándose junto con tu aplicación. Y una vez que tengamos todas estas piezas clave, estamos democratizando las pruebas para permitir que todos construyan y mantengan pruebas en todo el ciclo de desarrollo.

Así que muchas gracias a todos por su tiempo hoy. Estoy deseando escuchar todas sus preguntas. Hola, Juliette. Gracias por la conferencia. Fue increíble. Es un placer estar aquí. Discutamos un poco sobre los resultados de la encuesta. Tenemos los resultados de la encuesta en pantalla y parece que la mayoría de las personas o la mayoría tienen algo de DevOps con automatización y hay un porcentaje menor para las otras respuestas. ¿Cuál es tu conclusión al respecto?

Sí, sabes, es realmente interesante. Siento que ves a mucha gente aquí que se encuentra más en ese grupo intermedio. Y siento que viaje es realmente el término correcto para esta experiencia, porque realmente lleva mucho tiempo y energía conciliar estos diferentes conjuntos de herramientas e implementar herramientas y automatización. Así que creo que esto es realmente indicativo de muchas personas que ahora están avanzando en ese viaje y avanzando en ese proceso de lograr más automatización, más eficiencia en sus flujos de trabajo.

Sí, exactamente. A medida que avanzamos en esa dirección, creo que es una buena señal, ¿verdad?

Sí, absolutamente. Creo que es una de esas cosas en las que nunca estás completamente terminado. Siempre estás trabajando en ello. Así que espero que mi charla haya proporcionado alguna idea de cómo puedes comenzar a moverte en esa dirección también, especialmente si estás en esa etapa aspirante. Exactamente, sí. Tenemos algunas preguntas de la audiencia. Y la primera es de Jumuru. Me disculpo por no saber cómo pronunciar tu nombre. ¿Puede Mable darme algún informe de cobertura de tareas de integración? Y si es así, ¿cómo se calcula?

Sí, esa es una pregunta realmente interesante. Nuestra implementación actual de cobertura en Mable es específica para todas tus pruebas dentro de Mable. Ofrecemos tanto pruebas de navegador como pruebas de API, si estás buscando integrar pruebas de esa manera. La forma actual en que funciona nuestra cobertura es que ofrecemos tanto cobertura de página como cobertura de lanzamiento. ¿Cómo estás probando las páginas de tu aplicación? ¿Estás validando aspectos en esa página utilizando afirmaciones y diferentes tipos adicionales de validación? Y luego, nuestro lanzamiento más reciente es la cobertura de lanzamiento. Por lo tanto, utiliza tus pruebas existentes de Mable para determinar cuántas pruebas se ejecutan para este lanzamiento actual, ya sea en un período de tiempo o algo similar, cuántas de esas pruebas pasaron y fallaron. También te proporcionamos métricas adicionales sobre rendimiento e información en esa línea para darte una mejor comprensión de cómo están progresando tus lanzamientos con el tiempo. Genial. Y la siguiente pregunta es de

Eso es genial de escuchar. Entonces, el siguiente es de Kacper. Has mencionado que utilizando Mable, puedes reducir el costo de mantenimiento. Pero en realidad, la opinión pública es un poco diferente sobre ese tema. Incluso juzgando por la diapositiva de la presentación anterior, que es la que muestra la presentación de QLAB, creo que ¿cuál es tu opinión al respecto? ¿Cómo asegurarse de que el costo de mantenimiento sea bajo al usar Mable? Perdón, ¿puedes repetir esa última oración? ¿Cuál es tu opinión al respecto? ¿Cómo asegurarse de que el costo de mantenimiento sea bajo al usar Mable? Creo que es una gran pregunta. Es uno de esos desafíos fundamentales que siento dentro del espacio de las pruebas. Sabes, a medida que continúas intentando moverte más rápido y optimizar estos procesos, ¿cómo mantienes, cómo el equipo de QA se mantiene al ritmo de esos cambios también? Así que aquí en Mable, nos enfocamos realmente, ya sabes, en, cuando hablamos de incorporar inteligencia en el pipeline. Entonces, cuando hablamos de machine learning, inteligencia artificial, estos conceptos de auto-curación, y ciertamente es algo que, ya sabes, es un viaje también. No creo que nadie lo esté haciendo perfectamente, pero, ya sabes, realmente nos enfocamos en cómo podemos capturar tu intención mientras estás creando esas pruebas, asegurarnos de que sean robustas y resistentes a medida que tu aplicación cambia. Entonces, la idea aquí es, ya sabes, hablé de esto en mi charla también, pero si haces un pequeño cambio en tu interfaz de usuario, tus pruebas no deberían romperse. Así que siento que eso es cuando comenzamos a hablar de cómo, ya sabes, estamos obteniendo una mejor comprensión de esas atributos que son específicos de tu aplicación y realmente obteniendo una mejor comprensión de, ya sabes, lo que realmente significa estar en el estado correcto y estar interactuando con lo correcto. Entonces, la idea aquí es que, ya sabes, a medida que continúas haciendo esos cambios, también podemos mantenernos al día con la evolución allí.

Una curiosidad que tengo yo mismo, cuando hablo con personas que desarrollan productos que se utilizan para el desarrollo de software, ¿las personas dentro de Mable utilizan Mable para probar los productos que construyen? Sí. Esa es una gran pregunta. Lo llamamos Mable en Mable. Tenemos nuestro propio espacio de trabajo dentro de Mable que utilizamos para probar la producción frente al desarrollo y el desarrollo frente a la producción. Ejecutamos esas pruebas todos los días. De hecho, somos uno de los clientes más grandes de Mable de esa manera, porque lo usamos en todo nuestro pipeline para probar nuestro propio producto, lo cual es realmente genial poder hacer eso. Sí. Creo que es bueno porque así estás probando tu propio producto y sientes los problemas de tus propios usuarios. Y encuentro eso súper interesante, he trabajado en empresas donde pude hacer eso y lo encuentro súper, súper genial.

Otra pregunta que tenemos aquí es, ¿cómo puede una solución de bajo código ayudar a automatizar las testing en etapas tempranas del desarrollo? Sí, claro. Intentaré ser breve. Aquí en Mable, hablamos a menudo sobre la importancia de desplazar las testing hacia la izquierda y acortar realmente los ciclos de retroalimentación en las primeras etapas del proceso de desarrollo. Como mencioné antes, tenemos varias herramientas diferentes para ayudarte a hacer eso. La primera es nuestra interfaz de línea de comandos, que te permite ejecutar cualquier prueba de Mable localmente para obtener una retroalimentación rápida durante el desarrollo. También te ofrecemos la opción de utilizar nuestro ejecutor de CI para ejecutar esas pruebas localmente en vistas previas o entornos efímeros durante el proceso de compilación. Ahí es cuando también puedes usar etiquetas para asegurarte de que estás apuntando a un subconjunto de tu aplicación que sea relevante para tu PR, pero realmente asegurándote de que puedas obtener esa retroalimentación temprano en el ciclo de vida del desarrollo antes de llegar a tu rama principal. Genial. Juliette, fue maravilloso tenerte aquí con nosotros. Muchas gracias. Muchas gracias a ti. Ha sido un placer.