Video Summary and Transcription
La charla de hoy discute cómo Low Code permite pruebas continuas y DevOps, enfatizando la importancia de la automatización de pruebas y las desventajas de los enfoques aislados. La próxima era de la ingeniería de calidad tiene como objetivo superar los desafíos de la automatización incorporando aprendizaje automático y automatización inteligente. El proceso de desarrollo involucra pruebas locales, solicitudes de extracción y pruebas exhaustivas para garantizar la calidad antes de la fusión. Herramientas de bajo código como Mable ayudan a democratizar las pruebas y lograr una mayor cobertura de pruebas. El informe de cobertura de Mable incluye métricas de rendimiento y resultados de pruebas, lo que facilita y accesible las pruebas para cualquier miembro del equipo.
1. Introducción a Low Code y DevOps
Hoy hablaremos sobre cómo Low Code permite la prueba continua y DevOps. La automatización de pruebas es fundamental para tener éxito en DevOps. Los enfoques aislados no funcionan. La automatización de bajo código elimina los silos y produce mejores resultados en los esfuerzos de ingeniería de calidad.
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.
2. Quality Engineering and Test Automation
La ingeniería de calidad es un habilitador para las principales tendencias en el desarrollo de software. La automatización de pruebas es crucial para implementar cambios con confianza. Sin embargo, muy pocos equipos han logrado el nivel necesario de automatización. Sin ella, existe el riesgo de cuellos de botella y una capacidad limitada para verificar los cambios. La próxima era tiene como objetivo superar estos desafíos incorporando inteligencia en el proceso de automatización.
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.
3. Automatización Inteligente e Implementación Organizativa
La construcción de modelos de aprendizaje automático y su integración en el plano de control permite el potencial en la automatización. El low-code es un principio fundamental de la ingeniería de calidad, que permite la participación de más personas. Separar la intención de la implementación permite la automatización inteligente. Las actualizaciones de auto curación actualizan automáticamente las pruebas en función de la información aprendida. Mable permite importar pruebas existentes de Selenium e incorporar inteligencia en la ejecución. La implementación organizativa y la adaptación de las soluciones en los lugares y roles adecuados son cruciales para el éxito.
sucediendo en tiempo real cuando estás en la carretera. Y luego tenemos que construir modelos de aprendizaje automático y otros modelos en su lugar para tomar decisiones inteligentes. Y una vez que puedas hacer todo eso, puedes conectar ese cerebro al plano de control que automatiza realmente la conducción, y ahí tenemos potencial. Y de manera efectiva, con la automatización de pruebas, ¿no es así? Y estamos diciendo, mira, no se trata solo de los controladores que pueden mover un navegador, mover una aplicación móvil o interactuar con una API. Una vez que entiendes la intención de la automatización, debes recopilar los datos, analizar los datos y tomar buenas decisiones para que esa automatización sea efectiva. Y aquí es donde el low-code es realmente un principio fundamental de la ingeniería de calidad, y si no nos enfocamos en el low-code, es probable que limitemos la cantidad de personas y roles que realmente pueden participar en la calidad en nuestros equipos.
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.
4. Development Process and Pull Requests
Hoy vamos a hablar de cada una de las etapas diferentes del proceso de desarrollo. Comencemos con la base de código en la máquina de un desarrollador. Queremos tener cambios funcionales y una cobertura de pruebas integral. Los desarrolladores deben ejecutar pruebas iniciales localmente utilizando herramientas como Navel o Jest. Los ingenieros de calidad también pueden probar los cambios localmente. Crear una rama para pruebas relacionadas en Navel asegura la preparación. Es importante evaluar el trabajo de pruebas restante y considerar agregar pruebas adicionales. El punto crucial es la solicitud de extracción, donde se proponen cambios para fusionar en la rama principal. Es crucial realizar pruebas suficientes antes de implementar o fusionar.
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.
5. Merging and Deployment Stage
El primer objetivo es evitar fusionar cualquier cosa que detenga el flujo de trabajo. También es importante contar con una cobertura de pruebas integral y garantizar el éxito a largo plazo del equipo. El uso de un marco de bajo código como Mable permite que cualquier persona participe en la revisión lógica de las pruebas. El conocimiento especializado es crucial para la reutilización, configuración, desmontaje y las mejores prácticas de cobertura de pruebas. La colaboración incluye la ejecución de pruebas de regresión en el flujo de trabajo y la revisión de todas las pruebas antes de fusionar en la rama principal. La etapa de implementación asegura que no se permitan defectos en producción.
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.
6. Comprehensive Testing and Quality Understanding
Queremos asegurarnos de tener pruebas integrales y una comprensión más amplia de la calidad. Podemos identificar y solucionar rápidamente problemas con pruebas fallidas. Crear problemas en JIRA a partir de los resultados de las pruebas proporciona toda la información necesaria para los desarrolladores. Podemos detectar problemas de calidad incluso cuando las pruebas pasan, como errores de JavaScript y enlaces rotos. El monitoreo del tiempo de carga de la página ayuda a identificar problemas de rendimiento. Las pruebas basadas en datos permiten una expansión fácil de la cobertura sin escribir código. Bibliotecas como Faker y Math.js permiten la aleatorización de datos para escenarios de prueba realistas. Es crucial realizar pruebas en diferentes dispositivos, incluyendo móviles, para aplicaciones responsivas.
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.
7. Pruebas móviles y herramientas de bajo código
En 2020, más del 60% de las visitas a sitios web en Estados Unidos se originaron en dispositivos móviles. Mable permite validar la experiencia del usuario en aplicaciones responsivas. Las herramientas de bajo código, como Mable, ayudan a todo el equipo a participar en la calidad y lograr una mayor cobertura de pruebas. Al incorporar el aprendizaje automático y la inteligencia, las pruebas pueden desarrollarse junto con la aplicación. La democratización de las pruebas permite que todos construyan y mantengan pruebas en todo el ciclo de desarrollo.
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.
Q&A sobre los resultados de la encuesta y el informe de cobertura de Mable
Gracias a todos por su tiempo hoy. Discutamos los resultados de la encuesta. La mayoría de las personas tienen algo de DevOps con automatización. Es un viaje para lograr más automatización y eficiencia en los flujos de trabajo. Tenemos una pregunta de Jumuru sobre el informe de cobertura de Mable para tareas de integración. Nuestra cobertura incluye cobertura de página y de lanzamiento, proporcionando métricas sobre rendimiento y resultados de pruebas. La siguiente pregunta es de Elias.
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
Implementando el Proceso en Empresas Pequeñas
El proceso puede funcionar para empresas pequeñas, especialmente si trabajan en estrecha colaboración con su equipo de desarrollo. Mable tiene como objetivo hacer que las pruebas sean fáciles y accesibles para cualquier miembro del equipo.
Elias. ¿Crees que este proceso funcionará en una empresa pequeña? ¿El proceso que nos has presentado hoy? Sí, creo que esa es una excelente pregunta. Aquí en Mable, definitivamente tenemos empresas más pequeñas. Tenemos varias startups que utilizan nuestro producto, incluso con equipos de control de calidad de dos personas. Sin duda, creo que es posible, especialmente si trabajas en estrecha colaboración con tu equipo de desarrollo, incorporar esto a lo largo de todo tu proceso. Sin duda, es factible. Una gran parte de nuestro objetivo en Mable es hacer que las pruebas sean lo más fáciles posible y accesibles para cualquier miembro de tu equipo. Sin duda, creo que es posible implementarlo en tu empresa, independientemente de su tamaño.
Manejo de Cambios Pequeños en la Interfaz de Usuario y Subconjuntos de Pruebas
En Mable, tenemos el concepto de etiquetar pruebas, lo que te permite ejecutar un subconjunto de pruebas basado en características o entornos específicos. Esta es una gran solución para manejar cambios pequeños en la interfaz de usuario y ahorra tiempo al ejecutar solo las pruebas relevantes. Comenzar con una SmokeTestSuite que cubra los escenarios principales garantiza una prueba eficiente.
Estoy de acuerdo con eso. La siguiente pregunta que tenemos aquí de Mikus. ¿Ejecutan todas las pruebas de extremo a extremo incluso si hay un cambio pequeño en la interfaz de usuario? ¿Cómo manejan esas situaciones? ¿Es posible ejecutar un subconjunto del conjunto de pruebas para que no tarde demasiado en ejecutarse? Sí, absolutamente. En Mable, en realidad tenemos este concepto de etiquetado. Puedes etiquetar tu prueba, ya sea para una característica específica, un entorno específico, cualquier cosa en esa línea. Si estoy haciendo un cambio pequeño en un formulario, puedo decir fácilmente, `OK, solo me importa la prueba relacionada con esta página` y luego ejecutar ese subconjunto. Aún puedes adaptarlo y personalizarlo según tus necesidades. Creo que es una gran solución y muy útil para muchos casos de uso. Por lo general, quieres ejecutar, por ejemplo, una SmokeTestSuite primero, que cubre todos los escenarios principales, y luego después de que eso pase, ejecutas el resto. De lo contrario, si falla, no tiene sentido.
Ejecución de Pruebas Localmente con Mable
Puedes ejecutar pruebas localmente utilizando la interfaz de línea de comandos de Mable, sin necesidad de comunicarte con la nube o Mable. Te brinda la opción de ejecutar pruebas en tu entorno local o en un sitio disponible públicamente, sin ejecutar nada en la nube. Esta es una excelente manera de probar cambios localmente sin acceder a la aplicación o la nube.
ejecutar un conjunto más grande. ¿Verdad? Correcto. Otra pregunta aquí, ¿podré ejecutar las pruebas localmente sin ningún requisito de comunicarme con la nube o Mable? Sí. De hecho, ofrecemos, como mencioné durante mi charla, tenemos la interfaz de línea de comandos de Mable, así como nuestro ejecutor de CI. Nuestra interfaz de línea de comandos, te brinda la opción de ejecutar pruebas localmente, ya sea en tu entorno local o en un sitio disponible públicamente. No requiere ejecutar nada en la nube. Es una forma realmente genial. De hecho, lo he usado personalmente. Y estábamos realizando algunos cambios de accesibilidad en nuestro sitio para probar en mi rama de desarrollo local sin necesidad de ingresar a la aplicación o a la nube para esos propósitos también.
Reduciendo el Costo de Mantenimiento y Automatizando las Pruebas
Utilizar Mable para reducir el costo de mantenimiento es un desafío fundamental en el espacio de las pruebas. Incorporar inteligencia en el pipeline, capturar las intenciones de las pruebas y garantizar la robustez y la resistencia son clave. Mable utiliza su propio producto para probar la producción frente al desarrollo y el desarrollo frente a la producción. Soluciones de bajo código como la interfaz de línea de comandos y el ejecutor de CI de Mable ayudan a automatizar las pruebas en etapas tempranas del desarrollo, acortando los ciclos de retroalimentación.
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.
Comments