Pruebas en Producción

Hola a todos, soy Talia y hoy vamos a hablar sobre cómo habilitar las pruebas en producción. Vamos a hablar sobre qué es la prueba en producción, cómo configurarla y los problemas comunes con los que generalmente nos encontramos. Esta es mi información de contacto, mi Twitter y mi correo electrónico, en caso de que tengan preguntas más adelante.

Pero un poco sobre mí, soy una defensora del desarrollo en Split y solía ser ingeniera de pruebas. Trabajé en QA y automatización de pruebas durante un tiempo antes de unirme a Split. Ser ingeniera de pruebas fue realmente difícil para mí porque la mayoría de los problemas con los que me encontré giraban en torno a la preparación y el uso de este entorno ficticio. La preparación no es lo mismo que la producción. Tenía tantos problemas y estos son algunos de los problemas con los que lidié que estoy segura de que la mayoría de ustedes también han lidiado. Si han trabajado con algún tipo de entorno de prueba, cualquier tipo de entorno de QA, cualquier cosa que no sea producción. Estos son algunos de los aspectos que me dificultaron mucho hacer mi trabajo. El primer problema fue la falta de coincidencia de datos. Los datos en la preparación no coinciden con la producción, lo que significa que los resultados de las pruebas no siempre coinciden. Solía trabajar muy duro para asegurarme de probar cada requisito del producto y revisaba la documentación con el donante del producto y trabajaba con mis desarrolladores para solucionar todos los errores, asegurarme de que mis pruebas de extremo a extremo pasaran y luego firmaba la función. Y tan pronto como se lanzaba a producción, había un error. Y es una sensación horrible cuando hay tanta presión sobre ti para asegurarte de que tu función funcione en un entorno ficticio.

Y luego, lo siguiente con la falta de coincidencia de datos que me sucedió fue algo llamado desviación de configuración. Y lo que esto significa es que supongamos que te llaman una noche porque hay un incidente en tu aplicación y miras los registros e identificas los problemas, pero para solucionarlo, debes actualizar una configuración específica en producción. Entonces haces el cambio en producción y vuelves a dormir. Y aunque solucionaste el problema, acabas de crear una brecha aún mayor entre tus entornos de preparación y producción. Esta brecha se llama desviación de configuración. Y muchas veces los entornos de preparación no son iguales que la producción debido a los cambios realizados durante la gestión de incidentes, lo que solo agrava la desviación de configuración. Y sentí que, ¿cuál es el punto de las pruebas en preparación si no me va a dar los mismos resultados que la producción? El siguiente problema que tuve fue que la preparación era muy lenta. Tenía un rendimiento muy malo. Y muchas veces, cuando estás escribiendo pruebas en preparación, a menudo tienes que agregar esperas porque las cosas tardan más en cargarse. Por ejemplo, haces clic en un botón. Espera 10 segundos a que suceda algo. Realiza esta acción. Espera otros 10 segundos a que suceda algo. Tu usuario no va a esperar 10 segundos para que aparezca algo a tiempo real. Eso es una locura. Entonces, ¿por qué hacer eso diferente en la preparación?

A nadie le importa si la preparación está caída. Otra cosa con la que tuve que lidiar es que me asignaban para probar diferentes problemas. Para probar diferentes tickets de corrección urgente, y estos eran solo correcciones críticas de errores que necesitaban ser lanzadas de inmediato a producción. Así que ingresaba a la preparación para probarlo, pero la preparación estaba caída. Así que tenía que contactar al chico de DevOps. Pero el chico de DevOps decía que tenía que abrir un ticket de TI. Y luego el ticket de TI tenía que ser escalado por mi gerente. Y mientras tanto, todo lo que intentaba hacer era probar este ticket para nuestro producto, y a nadie parecía importarle. No era una prioridad para nadie. Nadie va a recibir una llamada en medio de la cena de Acción de Gracias si la preparación está caída. Y estaba tan cansada de lidiar con un entorno de preparación realmente malo y una experiencia de pruebas realmente mala y ser ciega cuando las cosas no funcionaban. Y pensé que tenía que haber una mejor manera de probar software. Mis usuarios finales no van a ingresar a la preparación para usar mi aplicación. Van a ingresar a producción. Así que hice mucha investigación y averigüé qué están haciendo otras empresas. Y esto es lo que hacen las empresas. Es la norma que las empresas utilicen entornos de preparación, especialmente las empresas que todavía siguen el modelo en cascada. Lo siguiente es que la mayoría de las empresas utilizan más de un entorno de preparación. Entonces, preparación, preproducción, beta, la mayoría de las empresas tienen más de uno. Y empresas conocidas como Google, Facebook, Netflix, Twitter, todas están haciendo pruebas en producción. Y cuando leí eso, pensé, ¿qué es hacer pruebas en producción? ¿Cómo es posible eso? ¿Qué quieres decir con hacer pruebas en producción? Así que hacer pruebas en producción significa hacer pruebas de tus características y el entorno en el que vivirán tus características, no utilizando un entorno ficticio como la preparación y pensé, wow, esto es perfecto. Esto va a resolver todos mis problemas. Y también aprendí que hacer pruebas en prod no significa que solo hagas pruebas en prod, aún vas a utilizar la preparación para GDPR y temas relacionados con SOCKS y privacidad, y pensé, esto es perfecto porque lo que no puedo probar en producción, simplemente lo probaría en la preparación, pero esos flujos críticos de usuarios, los puedo ejecutar en producción y pensé que esto es genial. ¿Cómo lo hago? ¿Cuáles son los pasos para llegar allí? Y la respuesta fue los feature flags. Y un feature flag es básicamente una forma de separar la implementación del código del lanzamiento de características. Y la idea aquí es que implementas tu código en producción detrás de un feature flag, lo pruebas en prod y luego lanzas la característica con el clic de un botón tan pronto como esté libre de errores. Entonces, ¿cómo funciona? Así es más o menos cómo se ve esto. Nuestros desarrolladores crearían un feature flag desde la interfaz de usuario, y luego lo dirigirían a todos nuestros compañeros internos. Y lo que eso significa es que solo los usuarios que estén dentro del feature flag mientras el flag esté desactivado, podrán acceder a la característica. Entonces, aquí puedes ver a los desarrolladores, probadores, diseño de productos. Solo ellos podrán acceder a esta nueva característica mientras el feature flag esté desactivado.

Cuando el flag está desactivado, porque son los únicos a los que se dirige. Estas personas a la derecha, estos usuarios finales reales, no pueden ver nada relacionado con la característica porque no están incluidos en el flag de la característica. Y así, mientras el flag de la característica está desactivado, entras y pruebas todo. Entonces, pruebas toda tu funcionalidad, pruebas tu diseño, revisas todos los requisitos, te aseguras de que todo funcione. Si hay un error, no tiene impacto en tus usuarios finales, porque, nuevamente, no tienen acceso a él, no están incluidos. Entonces, cuando hay un error, lo envías de vuelta a tu equipo de desarrollo, lo corrigen, lo pruebas nuevamente, y ese proceso continuará hasta que tengas una característica libre de errores en producción. Y luego, una vez que sabes que tu característica funciona en producción, puedes activar el flag, sabiendo que tus características funcionan en producción al 100%, y no has roto nada que ya existía. Ahora tus usuarios están felices y están bailando.

porque tienen una característica perfecta. Y pensé, esto es maravilloso. Este es un gran proceso. El uso de flags de características es genial. Pero, ¿cómo se automatiza? No puedes probar manualmente cada característica cada vez que lanzas una nueva versión. Y con los flags de características, tienes esta complejidad adicional. Entonces, ¿cómo se automatiza? Y aquí hay dos opciones para la automatización, y voy a explicar ambas. La primera opción es dirigirse a los usuarios de prueba y automatizar los flujos con ellos. Esto significa que cuando te diriges a tus usuarios, también creas un robot de automatización, simplemente un usuario de prueba que se utilizará para ejecutar estas pruebas en producción. Entonces, cada vez que este usuario de prueba inicie sesión, tendrá acceso a esta nueva característica. Y lo bueno de esta opción es que la prueba continuará ejecutándose incluso cuando actives el flag de características, no tendrás que hacer ninguna configuración adicional. La única desventaja de este enfoque es que aumenta la fragilidad, porque si alguien elimina a ese usuario de la lista de destinatarios o de la lista de permitidos en la configuración del flag de características, entonces tus pruebas fallarán. Así que debes asegurarte de que si agregas a ese usuario, nadie lo eliminará de la configuración. La siguiente opción es anular tus flags de características y crear una abstracción personalizada de flags de características. Básicamente, esto significa que para cada característica, tienes tres pruebas. En la primera prueba, simulas el flag de características activado y durante esta duración de la prueba, si recibes alguna solicitud preguntando si el flag de características está activado, responderás que sí. Y luego ejecutas la prueba de esa manera. Y luego, en la segunda prueba, simulas el flag de características desactivado. Y si llega alguna solicitud de la prueba preguntando si el flag de características está activado, responderás que no y ejecutarás la prueba de esa manera. Y luego, en la última prueba, quieres validar que puedes pasar por todo el flujo, independientemente de si el flag está activado o desactivado. Con este enfoque, eres muy explícito en la prueba y la prueba se vuelve mucho más autoexplicativa y descriptiva. Cuando se ejecuta cualquier prueba utilizando flags de características, el sistema bajo prueba simulará todas las variantes en el experimento y, debido a que es simulado, reducirás la complejidad de los diferentes escenarios, lo que significa pruebas más rápidas. Básicamente, estás estableciendo el estado del flag durante la duración de la prueba. Y luego, cuando ejecutas tus pruebas en producción, debes asegurarte de que tus pruebas solo interactúen con otras entidades de prueba, ¿verdad? Esto es algo que muchas personas temen, es decir, no quiero afectar a personas reales y usuarios reales en producción. Entonces, lo que haces es tener un sistema de flags en el backend, algo como `es usuario de prueba igual a verdadero`, `es prueba igual a verdadero`, algo que identifique claramente todos tus objetos de prueba en producción, y de esa manera separas los datos reales de los datos de prueba en tu panel de datos. Por ejemplo, si estás utilizando Datadog o Looker o cualquier otra herramienta, cuando lleguen tus datos, puedes crear un panel de control en Datadog o Looker o la herramienta que estés utilizando y decir que todo lo que tenga lógica de negocio para usuarios de prueba estará en este grupo, y todos los datos reales estarán en este otro grupo. Y así es como puedes diferenciar entre datos reales y datos de prueba. Por ejemplo, mis interesados van a ver los datos reales, mientras que yo como probador y mis ingenieros y mi equipo de ingeniería van a ver los datos de prueba y ver si se encontraron errores, ver qué necesita ser actualizado en la prueba, como esos dos deben estar separados, y así es como los separas. Y lo bueno de esto es que las pruebas buscan cosas específicas

Los elementos de prueba específicos se identifican con estos atributos de prueba en producción. Por lo tanto, si la prueba no encuentra ese elemento de prueba en producción, fallará y recibirás una alerta. Esto puede ser algo como una etiqueta ARIA o un atributo de datos, simplemente algo que puedas decir, esto es un elemento de prueba y esto es un elemento real. Sin embargo, hay excepciones. Si tu software está integrado con un tercero, puede ser complicado de probar. Puedes crear un encabezado único en la solicitud de API que envías al tercero y decir, hey, cualquier solicitud que recibas con este encabezado es una prueba y quiero que la trates de otra manera. A veces tienes que hacer excepciones cuando estás probando en producción, tal vez enviar una confirmación por correo electrónico a un lugar específico en lugar de al usuario final. A veces tienes que hacer esos cambios, pero vale la pena cuando estás probando en producción, cuando estás probando en un entorno en vivo. Una pregunta que me hacen muchas veces es, ¿cómo sabes qué probar en producción? Hay dos lugares para comenzar. El primero es ir a tu persona de producto, ir a tu gerente de producto y preguntarles, ¿cuáles son los flujos de negocio más importantes en nuestro producto? Entonces, ¿qué características nos brindan el mayor valor comercial? ¿Qué nos genera más ingresos? ¿Cuál es lo más importante para nuestro producto que debemos asegurarnos de que funcione todo el tiempo? El siguiente lugar es ir a tu analista de datos, tu científico de datos y averiguar qué es lo que la gente hace más. Y ten en cuenta que estas son dos cosas diferentes. Entonces, ¿qué es lo que la gente hace más, que si se rompe, tendrás muchos problemas. Tendrás muchos problemas en producción. Entonces, entre esas dos listas, deberías tener una idea muy clara de por dónde empezar y qué flujos probar en producción. Y además de los flags de características, hay algunas otras dependencias que necesitas. Entonces, necesitarás un marco de automatización. No quieres ejecutar manualmente cada prueba. Quieres automatizar ese proceso porque necesitas saber cuándo algo falla y necesitas saberlo de inmediato. Y con la velocidad de la automatización, eso se vuelve muy fácil. Creo que eso es bastante autoexplicativo. También necesitas un programador de trabajos. Y repasaré algunas de mis recomendaciones. Pero necesitas un programador de trabajos para ejecutar tus pruebas de forma incremental. Y puedes tener dos conjuntos diferentes de pruebas. Tus pruebas más importantes que se ejecutan cada hora porque son críticas para el negocio. Y puedes tener pruebas nocturnas que se ejecutan cada noche porque son menos críticas. Lo siguiente que necesitas es una herramienta de alerta para avisarte cuando tus pruebas fallan. Y solo una herramienta de alerta que se pueda integrar con tu programador de trabajos y que diga, ya sabes, esta prueba falla, averigua qué está pasando. Estas son las herramientas recomendadas que he utilizado para probar en producción. Para la segmentación de usuarios, obviamente, recomiendo Split. Hay otras herramientas disponibles y estaré encantado de hablar sobre ellas.

Pero para un marco de automatización, mi favorito absoluto es el marco de robot. Y robot es una biblioteca de automatización basada en palabras clave. Si no lo has probado, deberías hacerlo. Cypress es una biblioteca de JavaScript. Hay algunas otras para JavaScript que he usado, como puppeteer, con las que he tenido algunos problemas en el pasado. Así que no recomendaría puppeteer. También está Protractor para aplicaciones Angular. Pero obviamente, mi favorito es robot. Funciona con la mayoría de las aplicaciones. Y luego, para tu programador de trabajos, tienes Jenkins y Circle CI, Travis, no tengo preferencia entre ninguno de estos. Para tus herramientas de alerta, tienes Pager Duty y Slack. Y nuevamente, puedes personalizarlos para decir, para esas alertas críticas para el negocio, quiero usar Pager Duty, y para esas advertencias o cosas que parecen extrañas en la prueba, usa Slack.

OK. Así que hemos pasado por el cómo, y este fue todo el proceso de prueba en producción. Hemos pasado de la A a la Z, cómo configurarlo, cómo asegurarte de que tus pruebas no interactúen con los usuarios finales reales, cómo diferenciar esos datos, cómo configurarlo con flags de características, y pensé que esto tiene total sentido para mí. Pero si es tan simple, ¿por qué no lo hace todo el mundo? ¿Por qué no prueba todo el mundo en producción? Y la verdad es que la gente tiene miedo. Las empresas no prueban en producción debido a este miedo y falta de confianza en sus sistemas, y por la misma razón, se niegan a invertir en las herramientas y cambios de proceso que generarán esa confianza. Tienen demasiado miedo de los riesgos, y hay algunas cosas que puedes hacer para mitigar los riesgos de la prueba en producción. La primera de ellas, de la que hemos hablado, es utilizar flags de características. Dirígete a tus compañeros internos, prueba con ellos, esto también se llama `dogfooding`, y luego activa la característica sabiendo que ya funciona y no has roto nada que ya existía. Lo siguiente que puedes hacer es un lanzamiento canario, que es simplemente una implementación porcentual, y te permite lanzar tu característica a un pequeño subconjunto de usuarios antes de lanzarla a toda tu base de usuarios, porque si algo sale mal, ¿preferirías que el 100% de tus usuarios se encuentren con el problema o solo el 1%? Lo siguiente que puedes hacer es comenzar con una prueba AA, lo que significa que brindas la misma experiencia a ambos conjuntos de usuarios, tanto dentro como fuera del flag de características, y te aseguras de que los datos que llegan sean los mismos para ambos. Y lo que esto hará es aumentar tu confianza en el sistema de flags de características. Y obviamente, comienza de forma pequeña. No empieces con tu flujo más complejo y decidas probar en producción. Quieres comenzar con algo simple. Y el resultado de la prueba en producción es que puedes lanzar más rápido porque solo presionas un botón y tu característica se lanza, no tienes que pasar por todo un ciclo de lanzamiento. Porque tu

El código está listo. Simplemente separas la implementación de la liberación. Y lo siguiente es que tienes una velocidad de desarrollo aumentada. Entonces, tus desarrolladores pasan más tiempo creando nuevas características y menos tiempo solucionando errores. Y esto simplemente conduce a una mayor confianza y felicidad del equipo. Y si no te he convencido de que esta es una buena idea, me gustaría que todos piensen en la última característica que su equipo implementó. ¿Está funcionando ahora mismo en producción? ¿Cómo lo sabes? Tus usuarios no te han informado nada, así que no lo sabes. Probar en producción es la única forma de saber que tus características están funcionando en producción en este momento. Y muchas veces, cambiar la cultura de pruebas de tu empresa es la parte más difícil de este proceso, por lo que superar ese miedo es una parte realmente importante de esto.

Lo que sugiero es comenzar a usar banderas de características, ir a Split.io, hacer clic en una cuenta gratuita para desarrolladores y comenzar a usar banderas de características para ver si funciona para ti. Y en caso de que no hayas prestado atención en absoluto durante los últimos 20 minutos, quiero que te lleves dos cosas. La primera es que a nadie le importa si tus características funcionan en el entorno de preparación. Nos importa si funciona en producción y la única forma de saber si funciona en producción es probarlo en producción.

Muchas gracias a todos por escuchar y estoy aquí para responder preguntas. Puedes seguirme en Twitter, enviarme un correo electrónico y gracias. Muchas gracias por esa charla. Gracias por tomarte el tiempo para hablar con nosotros. Tenemos algunas preguntas de nuestra audiencia. ¿Estás listo para comenzar? Sí, estoy listo. Hagámoslo. Bien. Entonces, RDM preguntó, Talia, ¿cómo tu equipo maneja errores críticos que afectan a todo el sitio o página? ¿Entonces, te refieres a después de todo el proceso de testing en producción y tenemos un error en producción? Si eso sucede y estás usando una versión de prueba, solo afectará a un pequeño porcentaje de tus usuarios. Pero lo más importante es que si usas banderas de características para probar esa característica con anticipación en producción, no tendrás esos problemas importantes en producción de todos modos. Podrás probar en el entorno en el que la característica vivirá. Entonces, no tendrás esas sorpresas. No tendrás esos problemas importantes en producción. Y si los tienes, las banderas de características tienen algo llamado un interruptor de apagado donde simplemente apagas la característica. Es como hacer clic en un botón y simplemente apagas la característica . Y no tienes que redistribuir ningún código. No tienes que revertir nada en GitHub. Es solo presionar el botón y la característica está apagada. Entonces, el daño es mínimo cuando usas banderas de características. Eso es increíble. Es una excelente manera de... Solo puedo pensar en todas las formas en que lo usaría, especialmente a veces, sí, si tienes la aplicación en la que trabajo, por ejemplo, tiene muchos errores que aparecen para cuentas específicas que son muy difíciles de probar localmente porque tendrías que probar todas, ya sabes, replicar todas las condiciones. Sí. Eso parece muy útil. Kran preguntó, los entornos en mi experiencia son tanto sobre la estructura de la empresa como sobre la tecnología. ¿Estás de acuerdo? Si es así, ¿qué tipo de cambios organizativos crees que serían necesarios para facilitar este enfoque?

Esa es una excelente pregunta. Esa es una pregunta realmente buena. Entonces, en términos de organización, siento que deben haber un par de cosas que deben estar en su lugar. Lo primero es que su equipo debe tener un marco de automatización sólido. Y hablé un poco de esto en mi charla, pero necesitas tener una práctica de pruebas sólida establecida con automatización en su lugar. No puedes simplemente comenzar a hacer pruebas en producción sin tener ninguna configuración de automatización. Eso es una gran parte de la cultura de pruebas de la empresa. Otra cosa es que las personas deben querer que esto suceda. Si tienes personas en tu equipo que están en contra de las pruebas en producción y realmente no entienden el valor, esas dos cosas que sugerí al final, como usar ejemplos de tu pasado, pregúntales, ¿recuerdas cuando probamos esta cosa en el entorno de preparación y funcionó perfectamente y luego tan pronto como lo lanzamos en producción hubo este problema? O piensa en momentos en los que tu entorno de preparación estaba caído y tuviste que probar algo y usa ejemplos de tu pasado. Y también, si no has ido a split.io, puedes crear una cuenta gratuita para desarrolladores y comenzar a usar nuestros SDK. Es súper útil. También tengo un montón de tutoriales allí. Entonces, sí, ahí es donde comenzaría. Pero también diré que siempre habrá personas que dirán que las pruebas en producción nunca funcionarán y que debes usar el entorno de preparación, y generalmente son esas personas mayores en las empresas que han estado allí durante como 20 años y no les gusta mucho el cambio. Así que ignora a esas pocas personas. En su mayor parte, esta es una práctica realmente innovadora. Y si se hace correctamente, puedes,

Quiero decir, los beneficios son simplemente infinitos. Sí, seguro. Sí, siempre es difícil impulsar ese cambio organizativo, cambiar la mentalidad de las personas, especialmente si han sido afectadas por lo que estás tratando de hacer. Pero las pruebas en producción son muy diferentes ahora que hace años. Sí, porque tenemos las herramientas que nos permiten hacerlo de manera segura, no solo estamos lanzando código a producción y diciendo, bueno, veamos qué sucede. Es muy seguro, muy planificado. Sí, ahora puedes hacerlo. Tom pregunta, ¿eliminas las banderas después de que se lanza y funciona una función? Sí. De hecho, escribí una publicación completa en el blog sobre cuándo eliminar una bandera de características y cuándo degradar una bandera de características. Entonces, básicamente, dependiendo del caso de uso para el que estés usando una bandera, es cuando sabes cuándo eliminarla. Pero para las pruebas en producción, una vez que una función se lanza por completo y se lanza al 100% de tu población y sabes que funciona, entonces puedes eliminar la bandera. Y no quieres tener banderas de características antiguas en tu base de código. Claro. Sí. William preguntó, esto, creo que es realmente interesante. Trabajo con muchas bibliotecas que tenemos que actualizar en varios productos. La pregunta de William me llamó la atención. Preguntó, ¿cómo gestionas las dependencias entre banderas de características? Básicamente, cuando estás dirigiendo tus bots de automatización dentro de tus banderas de características, te aseguras de dirigirte al mismo bot en las diferentes banderas de características que necesitas. Así que digamos que tienes, como, flujo de usuario 1 y flujo de usuario 2, y son, ya sabes, dos características diferentes, pero dependen una de la otra para funcionar. Entonces lo que haría es dirigirme a mi usuario de prueba en ambas banderas de características, para que cuando ese usuario ejecute la automatización para ambas banderas, cuando se ejecuten esas pruebas, sabrás si algo falla, porque es el mismo usuario que está ejecutando las pruebas. Genial. Eso es genial.

Giuseppe dijo que fue una gran charla. Estoy de acuerdo. Fue genial. ¿Esta práctica se combina generalmente con el desarrollo basado en tronco? Sí. Sí, sí, lo es. De acuerdo. Thomas preguntó, ahora estamos evaluando servicios de banderas de características, y estamos buscando uno que

Split admite múltiples dimensiones para describir usuarios. Dimensiones entre paréntesis. Por ejemplo, si queremos cambiar banderas para usuarios específicos en todos los niveles gratuitos versus clientes de nivel Pro o globalmente para todos los usuarios. ¿Split admite esto? Lo siento, ¿puedes repetir eso? Sí, fue una pregunta larga. Parece que Thomas está evaluando servicios de banderas de características y está buscando uno que admita múltiples dimensiones para describir usuarios. Por ejemplo, nos gustaría cambiar banderas para usuarios específicos en todos los niveles gratuitos versus clientes de nivel Pro o incluso globalmente para todos los usuarios, y están preguntando si Split admite esto. Sí. Con Split, lo que puedes hacer es segmentar la base de usuarios en diferentes categorías. Puedes tener usuarios gratuitos en un segmento, usuarios pagos en otro segmento y luego puedes agregar configuraciones dinámicas para decir, por ejemplo, para estos usuarios quiero mostrar esto y para este usuario quiero mostrar esto. Y puedes configurarlo como quieras. Mientras crees los diferentes segmentos de usuarios que necesitas, eso es totalmente posible en Split. Realmente sugiero que si no has iniciado sesión en split.io, crees una cuenta gratuita. Tenemos muchos SDK diferentes que puedes usar y estoy feliz de responder preguntas si tienen preguntas sobre diferentes tutoriales. Eso es genial. Muchas gracias Talia por unirte a nosotros y gracias por esa increíble charla. Gracias. Adiós.