Cómo Low-Code permite pruebas continuas en DevOps

Rate this content
Bookmark

Como industria, entendemos que la automatización de pruebas efectiva es un habilitador clave - o un inhibidor - para realizar el potencial de DevOps. Si bien la automatización es fundamental para innovar con velocidad y calidad, muy pocos de nosotros estamos satisfechos con los resultados. Esta charla cubrirá cómo las soluciones de automatización de pruebas de bajo código - como mabl - permiten a los equipos incrustar pruebas automatizadas directamente en el pipeline de desarrollo, estrategias para superar los desafíos tradicionales de la automatización de pruebas y cómo construir una base para una estrategia de pruebas eficiente y efectiva.

31 min
18 Nov, 2021

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.

Available in English

1. Introducción a Low Code y DevOps

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

QnA

Q&A sobre los resultados de la encuesta y el informe de cobertura de Mable

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.