Cómo Low-Code permite pruebas continuas en DevOps

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at TestJS Summit 2021, check out the latest edition of this JavaScript Conference.

FAQ

La automatización de pruebas permite a las pequeñas empresas acelerar su ciclo de desarrollo, mejorar la calidad del software y reducir los costos asociados con el mantenimiento manual de pruebas, haciéndolas más competitivas y ágiles en el mercado.

Low Code es una solución que facilita la creación y ejecución de pruebas de software con menos código, lo que optimiza tanto la prueba continua como las prácticas de DevOps, permitiendo una mayor eficiencia y colaboración en el desarrollo y mantenimiento de software.

La automatización de pruebas es fundamental en DevOps porque permite realizar despliegues más frecuentes y con mayor confianza, al asegurar que las nuevas características o cambios no rompan funcionalidades existentes, mejorando así la calidad y velocidad de las entregas.

Low Code permite que personas de diversos perfiles, como probadores manuales, desarrolladores y personal de soporte, participen activamente en el proceso de calidad sin necesidad de avanzados conocimientos de programación, lo que reduce los silos y fomenta un enfoque más integrador en la calidad del software.

La auto curación en pruebas automatizadas se refiere a la capacidad de un sistema de ajustar y corregir automáticamente las pruebas basadas en los cambios detectados en la aplicación, como modificaciones en la interfaz de usuario, asegurando que las pruebas permanezcan efectivas sin intervención manual constante.

Mable permite importar pruebas existentes de Selenium y exportarlas a Selenium IDE, facilitando la integración de trabajos previos en un nuevo entorno de bajo código, lo cual ayuda a preservar la inversión en pruebas ya desarrolladas y mejora la capacidad de incorporar inteligencia y aprendizaje automático.

Juliette MacPhail
Juliette MacPhail
31 min
18 Nov, 2021

Comments

Sign in or register to post your comment.
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

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Elevando Monorepos con los Espacios de Trabajo de npm
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Elevando Monorepos con los Espacios de Trabajo de npm
Top Content
NPM workspaces help manage multiple nested packages within a single top-level package, improving since the release of NPM CLI 7.0. You can easily add dependencies to workspaces and handle duplications. Running scripts and orchestration in a monorepo is made easier with NPM workspaces. The npm pkg command is useful for setting and retrieving keys and values from package.json files. NPM workspaces offer benefits compared to Lerna and future plans include better workspace linking and adding missing features.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Automatizando Todo el Código y las Pruebas con GitHub Actions
React Advanced 2021React Advanced 2021
19 min
Automatizando Todo el Código y las Pruebas con GitHub Actions
Top Content
We will learn how to automate code and testing with GitHub Actions, including linting, formatting, testing, and deployments. Automating deployments with scripts and Git hooks can help avoid mistakes. Popular CI-CD frameworks like Jenkins offer powerful orchestration but can be challenging to work with. GitHub Actions are flexible and approachable, allowing for environment setup, testing, deployment, and custom actions. A custom AppleTools Eyes GitHub action simplifies visual testing. Other examples include automating content reminders for sharing old content and tutorials.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
TestJS Summit 2023TestJS Summit 2023
148 min
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
Top Content
Workshop
Filip Hric
Filip Hric
Probablemente conozcas la historia. Has creado un par de pruebas y, como estás utilizando Cypress, lo has hecho bastante rápido. Parece que nada te detiene, pero luego - prueba fallida. No fue la aplicación, no fue un error, la prueba fue... ¿inestable? Bueno sí. El diseño de la prueba es importante sin importar la herramienta que utilices, incluyendo Cypress. La buena noticia es que Cypress tiene un par de herramientas bajo su cinturón que pueden ayudarte. Únete a mí en mi masterclass, donde te guiaré lejos del valle de los anti-patrones hacia los campos de pruebas estables y siempre verdes. Hablaremos sobre los errores comunes al escribir tu prueba, así como depurar y revelar problemas subyacentes. Todo con el objetivo de evitar la inestabilidad y diseñar pruebas estables.