Pruebas en Producción

Rate this content
Bookmark
29 min
24 Jun, 2021

Video Summary and Transcription

La charla de hoy discute el concepto de pruebas en producción, incluyendo los desafíos con los entornos de preparación y la falta de coincidencia de datos. Se destaca el uso de banderas de características como solución para habilitar las pruebas en producción. Se enfatiza la automatización como componente clave para las pruebas eficientes de banderas de características. Los beneficios de las pruebas en producción son el aumento de la velocidad y la confianza del desarrollador. También se abordan los requisitos organizativos y la resistencia a las pruebas en producción. La charla concluye discutiendo la gestión de banderas de características y la segmentación de usuarios en los servicios de banderas de características.

Available in English

1. Introducción a las pruebas en producción

Short description:

Hoy vamos a hablar sobre cómo habilitar las pruebas en producción, incluyendo qué es la prueba en producción, cómo configurarla y los problemas comunes. Como antigua ingeniera de pruebas, me enfrenté a desafíos con los entornos de preparación y la falta de coincidencia de datos. Los datos en el entorno de preparación no siempre coinciden con la producción, lo que lleva a resultados de prueba que no se alinean. Además, la desviación de configuración crea una brecha entre la preparación y la producción, lo que hace que las pruebas en preparación sean menos confiables. Además, los entornos de preparación a menudo tienen un rendimiento lento, lo que no refleja con precisión las interacciones del usuario 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?

2. Desafíos de las pruebas y la solución: Feature Flags

Short description:

Me enfrenté a desafíos con un entorno de preparación deficiente y una mala experiencia de pruebas. Las pruebas en producción significan probar características y su entorno, no utilizar un entorno ficticio como la preparación. Grandes empresas como Google, Facebook, Netflix y Twitter están realizando pruebas en producción. Los feature flags separan la implementación del código del lanzamiento de características, lo que permite lanzamientos sin errores con solo hacer clic en un botó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.

3. Testing Features and Turning on Flags

Short description:

Probar todo mientras el flag está desactivado asegura que cualquier error encontrado no afectará a los usuarios finales. El equipo de desarrollo puede corregir los errores y volver a probar hasta que la característica esté libre de errores en producción. Activar el flag después de las pruebas garantiza que la característica funcione sin romper nada existente.

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.

4. Automating Feature Flag Testing

Short description:

El uso de flags de características es un gran proceso, pero ¿cómo se automatiza? Hay dos opciones: dirigirse a los usuarios de prueba y automatizar los flujos con ellos, o anular los flags de características y crear una abstracción personalizada de flags de características. Dirigirse a los usuarios de prueba requiere crear un robot de automatización que ejecute pruebas en producción. La desventaja es que aumenta la fragilidad si el usuario se elimina de la configuración. Anular los flags de características implica simular el estado del flag activado y desactivado en pruebas separadas, asegurando que todo el flujo funcione independientemente del estado del flag. Las pruebas en producción solo deben interactuar con entidades de prueba, separando los datos reales de los datos de prueba mediante un sistema de flags en el backend.

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

5. Testing Elements and Tools

Short description:

Cuando se realiza la prueba en producción, es importante identificar los elementos de prueba y distinguirlos de los elementos reales. Pueden ser necesarias excepciones al integrarse con software de terceros. Para determinar qué probar en producción, consulte con los gerentes de producto para identificar los flujos de negocio críticos y con los analistas de datos para comprender el comportamiento del usuario. Además de los flags de características, los marcos de automatización, los programadores de trabajos y las herramientas de alerta son esenciales para una prueba eficiente y efectiva en producción.

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.

6. Automation Frameworks and Mitigating Risks

Short description:

Pero para un marco de automatización, mi favorito absoluto es el marco de robot. Funciona con la mayoría de las aplicaciones. Para tu programador de trabajos, tienes Jenkins y Circle CI, Travis. Para tus herramientas de alerta, tienes Pager Duty y Slack. Las empresas no prueban en producción debido al miedo y la falta de confianza en sus sistemas. Mitiga los riesgos de la prueba en producción utilizando flags de características, lanzamiento canario y prueba AA. Comienza de forma pequeña y separa la implementación de la liberación.

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

7. Benefits of Testing in Production

Short description:

La velocidad de desarrollo aumentada conduce a una mayor confianza y felicidad del equipo. Probar en producción es la única forma de saber si las características están funcionando en producción. Cambiar la cultura de pruebas es la parte más difícil del proceso.

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.

QnA

Using Feature Flags and Handling Bugs

Short description:

Comienza a usar banderas de características y prueba en producción para asegurarte de que tus características funcionen en el entorno real. Las banderas de características te permiten probar las características con anticipación y evitar problemas importantes en producción. Si ocurre un error, las banderas de características tienen un interruptor de apagado para desactivar la característica al instante. Esto minimiza el daño y evita la redistribución de código. El uso de banderas de características es una excelente manera de manejar errores que son difíciles de replicar en las pruebas locales. La estructura de la empresa juega un papel importante en la creación de entornos de prueba. Puede ser necesario realizar cambios organizativos para facilitar un enfoque de prueba en producción.

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?

Organizational Requirements and Benefits

Short description:

En términos de organización, es crucial tener un marco de automatización sólido y una práctica de pruebas establecida. Es importante abordar cualquier resistencia a las pruebas en producción utilizando ejemplos del pasado y enfatizando el valor. Ignora a aquellos que se oponen a la práctica debido al miedo o la resistencia al cambio. Las pruebas en producción son un enfoque innovador con beneficios infinitos.

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,

Testing in Production and Feature Flag Management

Short description:

Las pruebas en producción son muy diferentes ahora que hace años. Tenemos las herramientas que nos permiten hacerlo de manera segura. La eliminación de banderas después de que se lance y funcione una función depende del caso de uso. La gestión de dependencias entre banderas de características implica dirigirse a los mismos bots de automatización. Las pruebas en producción generalmente se combinan con el desarrollo basado en tronco. Se están evaluando servicios de banderas de características que admiten múltiples dimensiones para describir a los usuarios.

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

Servicios de Banderas de Características y Segmentación de Usuarios

Short description:

Thomas está evaluando servicios de banderas de características y quiere saber si Split admite cambiar banderas para usuarios específicos en diferentes niveles o globalmente. Split te permite segmentar la base de usuarios en diferentes categorías y agregar configuraciones dinámicas para cada segmento. Es posible crear diferentes segmentos de usuarios y configurarlos en Split. Talia sugiere crear una cuenta gratuita en split.io para explorar los SDK disponibles y hacer preguntas sobre tutoriales.

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.

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.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
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
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.
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
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.