Acelerando la Calidad para Cientos de Aplicaciones React con Capas de Pruebas Automatizadas

Hablemos sobre pruebas. Y este es un estudio de caso de la empresa en la que trabajo y el producto en el que estoy trabajando. Y déjame empezar con una confesión. Desarrollamos aplicaciones, y durante mucho tiempo, fuimos lentos. Nuestro ciclo de lanzamiento, ya sabes, esta cosa donde planeas, desarrollas, pruebas cosas, y las lanzas a los usuarios finales para nosotros, hace como dos años era aproximadamente de tres meses. Y eso es bastante doloroso para un ingeniero ver que tu cambio está llegando a los usuarios en tanto tiempo.

No estoy seguro de quién de ustedes comparte este dolor, pero vamos a conocernos mejor, conocernos mejor. Entonces, ¿quién siente este dolor ahora? ¿O sintió este dolor en el pasado? Oh, ho, ho, tengo a las personas adecuadas aquí. Por favor levanta la mano si tu ciclo de entrega es de alrededor de un mes. Bien, bien. Y por favor levanta la mano si es como un sprint de dos semanas. Oh, agradable, agradable, agradable. ¿Y quiénes son los felices que pueden lanzar en menos de una semana o continuamente? No está mal, no está mal. Bien.

Sí, así que toda la charla será sobre cómo en la empresa pasamos de aquí a aquí. Y permíteme presentarme. Soy Bogdan. Soy un ingeniero principal en Zatu. Estoy organizando el meetup de React Berlin. Soy padre de una adolescente y esto no es... Esto es difícil. Y un hijo gemelo. Soy dueño de un Australian Shepherd y soy compañero de mi esposa en cada aventura que ella nos lleva. Y el producto en el que estoy trabajando, y esto es importante para darte un contexto porque todas las decisiones que hemos tomado básicamente provienen de la complejidad y mucha optimización. Pero realmente, primero necesitas entender el producto para entender lo que aplicamos.

Así que el producto, somos Zatu y se trata de streaming. Zatu proporciona una experiencia de streaming fácil, sin importar el dispositivo. Podría ser que estás viendo tu partido de fútbol de tu equipo favorito en tu dispositivo móvil mientras viajas en el tren. Podría ser que te reúnas en la sala de estar en Navidad para ver alguna película navideña como un duro de matar. Podría ser que estés viendo automovilismo mientras viajas por Europa.

O tomando tu café y mirando lo que Trump hizo hoy en tu refrigerador. Y esta es realmente una historia real. No sobre Trump, sino sobre el refrigerador. Pusimos nuestra aplicación en el refrigerador y sorprendentemente funcionaba. PWA es increíble. Como ves, hay muchos dispositivos diferentes, muchas plataformas diferentes a las que estamos apuntando. Y esto es todo un zoológico de tecnologías. Y estamos usando diferentes proyectos para hacer que las aplicaciones funcionen.

Así que los proyectos en nuestro entendimiento son algo en nuestro monorepo que podemos construir aplicaciones desde. Y nuestra pila todavía está algo mezclada entre web y nativo. Como Android con Kotlin, Apple con Swift, y web con JavaScript y React. Actualmente estamos cambiando a algo más universal porque no estoy seguro si has oído que Amazon acaba de lanzar un Vega OS que es muy React Native primero. Y esto también nos impulsa como pioneros a integrarnos con ellos y construir aplicaciones para ellos. Así que estamos cambiando toda la pila nativa y web a React Native.

Toda la charla podría surgir de eso, pero no me centraré en eso y te guiaré a través del soporte al cliente. Y los clientes son algo diferente del proyecto. Los clientes representan como una plataforma objetivo o sistema operativo como TVOS, Android TV, Fire TV, WebOS, iOS, Android, lo que sea. Navegadores de Windows diferentes, Chromium, si es que hay otros navegadores vivos estos días. Y más allá de eso, no solo somos Zatu como un producto B2C, también hacemos etiquetado blanco y producimos aplicaciones para diferentes inquilinos como Einstein en Alemania, Air TV en Irlanda, Monaco TV en Mónaco, Zalt, Suiza, creo, Huawei en Países Bajos, y así sucesivamente. Y por supuesto, Zatu, del cual principalmente sabemos. Y esto nos da toda una matriz.

Así que tenemos pocos proyectos, tenemos múltiples clientes, tenemos docenas de inquilinos, y todos juntos, nos da como cientos de aplicaciones que nos gustaría entregar a nuestros usuarios. Y cientos de aplicaciones nos dan cientos de problemas. Y a esta escala, siempre surgía la pregunta de cómo asegurar una garantía de calidad rápida y confiable para que podamos enviar sin problemas.

El gran problema que teníamos era una garantía de calidad manual porque se convirtió con la cantidad de aplicaciones en crecimiento, en un cuello de botella, no realmente una red de seguridad. No escala. No podíamos simplemente contratar personas añadiendo más y más plataformas. El ciclo de retroalimentación era bastante malo. Intentamos incluso externalizarlo, pero aún así, había una coordinación interminable sobre qué plataforma funciona, cuál no. La velocidad de aceptación no era buena. Y por el factor humano, como una garantía de calidad manual es propensa a errores.

Así que lo que hicimos aquí fue hacer un cambio bastante grande y redefinir la garantía de calidad en el sentido de nuevas responsabilidades y automatización de pruebas. Y ampliamos las responsabilidades de la garantía de calidad más allá de los roles tradicionales. Así que los ingenieros de QA pasaron a roles enfocados en la ingeniería. Y las pruebas se compartieron entre todas las disciplinas, incluyendo diseño, incluyendo propiedad del producto, y por supuesto, ingeniería.

Y la columna vertebral de esta automatización, lo que lo hizo posible fue la automatización de pruebas. Pero no importa cómo delegues a la automatización, todavía hay algunos otros problemas que podrían surgir, como la retroalimentación de calidad retrasada, especialmente si estás probando demasiado tarde en el proceso, cuando los errores están apareciendo en la línea de meta mucho después de que hayas cometido el código. Y esto no es realmente bueno porque siempre implementas correcciones de errores bajo cierta presión. Estás perdiendo contexto porque estás cambiando a otra tarea y así sucesivamente.

Y al consolidar una gran cantidad de cambios y probarlos en el lote, es bastante difícil saber qué contribución causó qué error. Así que lo que hicimos aquí, implementamos un enfoque de shift-left, que es bastante sencillo. Es mover tu objetivo de prueba desde la derecha hasta la izquierda en una forma muy simple. Así que tenemos este main, donde todos contribuyen. Hay características que están contribuyendo a main, y hay algunos lanzamientos que estás etiquetando, o si estás usando una estrategia basada en trunk, estás bifurcando desde allí.

Y así para nosotros, siempre estuvo allí, como en la etapa de lanzamiento. Así que lo que sugiere el enfoque de shift-left es probar lo antes posible. Así que lo cambiamos a la etapa de características. Y luego sobre la automatización, así que las pruebas automatizadas son muy diversas. Podemos aplicar y probar diferentes aspectos. Hay un montón de diferentes tecnologías. Y te mostraré algunas que estamos usando personalmente. Para una prueba estática, esta que analiza la base de código sin ejecutarlas, como linters, verificadores de tipos, estamos usando ESLint, estamos usando SwiftLint, StyleLint, Rubocop, los chicos de Ruby son raros con los nombres, Hint, HTML, Printer, TypeScript, que es una gran red de seguridad cuando se trata de la calidad del código, Kotlin detect.

Hay algo específico, lo llamamos una especie de capa de construcción. Básicamente es cuando simplemente ensamblas en tu aplicación. Y para nosotros en React Native, React Stack, básicamente puedes ejecutar tu aplicación con Webpack y el Metro Bundler asegurando que en el momento en que desees lanzar, se va a construir.

Hay una capa de pruebas unitarias, como una prueba de entrada y salida básicamente. No necesito explicar las pruebas unitarias. Estamos usando Jest, estamos usando React Testing Library. Jest test runner es genial. Estamos tratando de integrar ahora JUnit para esta capa de pruebas nativas.

Y hay una capa de pruebas de sistema. Sistema probablemente nuestra palabra interna. Puedes reconocerlo por función de integración de extremo a extremo o lo que sea. ¿Por qué no podemos llamarlo pruebas de extremo a extremo? Porque consideramos las pruebas de sistema o integración algo que estamos evaluando en un entorno altamente simulable y en los simuladores, no en los dispositivos reales. Porque cuando se trata de TV, por ejemplo, es un poco difícil de probar. Y esta es una historia muy diferente.

Entonces, en la prueba del sistema, todavía tenemos algo de legado de Cypress después de su cambio de hacer todo e introducir pruebas de componentes y ser un poco poco confiable, así que lo cambiamos a Playwright. Y tenemos Appium, donde hay algo muy interesante que estamos haciendo aquí. Estamos escribiendo pruebas para Playwright, conectándolo a Appium y evaluándolos tanto en la web como en el nativo, en el lado de Android, en el lado de Vega, TV como núcleo. Y de extremo a extremo, como una prueba de extremo a extremo real contra el dispositivo objetivo. Y hay muy pocas tecnologías que realmente proporcionan esta capacidad.

Así que estamos utilizando pruebas de barrido con cajas de caramelos que realmente toman como un D-pad de TV y emulan clics reales en los dispositivos reales. Y ves, ya he categorizado este test en las capas. Y este es otro enfoque donde las pruebas en múltiples capas pueden ayudarte a entender qué tecnologías elegir. Y esta pirámide que te estoy sugiriendo es muy representativa. Así que recomendaría construir capa por capa si no tienes todas ellas. Y no te apresures a, por ejemplo, escribir pruebas de extremo a extremo o pruebas unitarias si no cubres como tu base, tu capa de prueba del sistema, porque la capa de prueba estática. Porque las pruebas estáticas son súper baratas, cubren mucho, son rápidas.

Así que reconocer las capas de prueba. Eso en sí mismo, las pruebas automatizadas son buenas, las herramientas son geniales. Pero ejecutarlas eficientemente es todo un desafío. Así que necesitas responder muchas preguntas como, ¿ejecuto las pruebas localmente versus CI? ¿Ejecuto todo o parte de ello? Cuando una prueba falla, ¿qué haces? ¿Fallas toda la ejecución? Y así sucesivamente. ¿Qué variación de aplicación usar? ¿Pruebo solo un tipo de aplicación en una plataforma o en todas las plataformas y así sucesivamente? Así que lo que necesitas es básicamente definir tu estrategia primero antes de siquiera ejecutarla. Este es un ejemplo de nuestra documentación que responde a todas estas preguntas y es una guía para nuestros ingenieros, nuestros DevOps, todos los que participan en el aseguramiento de calidad, cómo implementarlo, cómo vivirlo, cómo desarrollarlo. Puedes llevarlo a algo más concreto donde puedas establecer algún esquema de cómo las cosas están orquestadas. Y este es un ejemplo para pull request, el objetivo en nuestro desarrollo principal, y todo el asunto. No entraré en detalles, me llevaría una eternidad. Así que realmente necesitas una estrategia de ejecución para utilizar las pruebas eficientemente. Pero aún no es suficiente. Realmente necesitas asegurarte de que tus pruebas sean rápidas y confiables. Y aquí hay algo más concreto para acelerar las prácticas y cómo las hicimos bastante receptivas. Básicamente las hicimos rápidas al almacenar en caché lo que pudimos y ejecutando lo que importaba. ¿Qué significa esto? Comencemos con el almacenamiento en caché. Así que todos conocen esta famosa cita sobre las dos cosas más difíciles en programación, como nombrar cosas y almacenar en caché. Si logras lidiar con el caché, ese es el objetivo. Así que un ejemplo muy simple de ASLint.

Es muy fácil de implementar. Solo necesitas una bandera de caché y eso es todo. Está haciendo el trabajo por ti. Puedes, por supuesto, especificar algo más a eso, como una ubicación de caché, por ejemplo, en CI para alimentar tu rama objetivo con eso, así que estás usando este caché también. O implementar una estrategia de caché dependiendo de cuán preciso quieras ser con este caché.

Pero un ejemplo concreto de nuestra ejecución que se llamaba start para nosotros en CI antes, porque no introdujimos almacenamiento en caché en CI, era aproximadamente alrededor de un minuto. Para una base de código enorme con múltiples proyectos. Y se redujo a cuatro segundos. Por supuesto, depende de la cantidad de cambios que produzcas, ¿verdad? Así que este es un ejemplo muy ligero cuando estoy afectando un modelo. Pero es muy comparable.

No solo puedes almacenar en caché tus frameworks, puedes almacenar en caché tu entorno. Por supuesto, está Docker donde recomendamos este. Pero también Docker viene con el costo de DevOps, y realmente necesitas un equipo. Y si tu proyecto no es tan grande, o es realmente uno de tecnología web, realmente no necesitas Docker. Solo necesitas almacenar en caché tus modelos de nodo. Y este es un ejemplo de GitHub. Este es el flujo de trabajo de GitHub y las acciones de GitHub que hacen este trabajo por ti.

Aquí hay un ejemplo de ejecución sin almacenamiento en caché, o con almacenamiento en caché roto, de hecho. Y tenemos muchos modelos de nodo. Y para nosotros, sin almacenamiento en caché, la instalación de modelos de nodo toma alrededor de dos minutos. Y después de implementar el almacenamiento en caché, se reduce a 26 segundos.

Al final, la retroalimentación de la capa estática, incluyendo todas las herramientas que mencioné, para nosotros, para cualquier contribución que no afecte a gran escala, es de alrededor de tres minutos. Lo cual no está mal. Y si estás prestando atención a lo que está escrito aquí, podrías decir, Bogdan, ¿por qué nos mientes? Android Lint nunca terminará en ocho segundos, ¿verdad? Y esto es cierto.

Y aquí es donde me dirijo a otra práctica que puedes introducir, que es el reconocimiento de cambios. Así que básicamente prueba lo que afectaste. Y podría aplicarse a muchos niveles. Y el más básico, cuando tomas en el Git, y solo div 3 y ves la lista de los archivos que fueron afectados, y simplemente corta todo lo que no necesitas.

No se trata más de la capa estática, sino más de construir una capa o una prueba unitaria o de integración. Así que otro ejemplo concreto aquí, tenemos miles de proyectos que usualmente se construyen con cada cambio. Y después de reconocer qué proyectos fueron afectados, puedes reducirlo solo a los proyectos que fueron afectados.

Es un gran ahorro de tiempo. Y el reconocimiento del sistema de archivos es bueno, pero a veces no es suficiente, especialmente para las pruebas de integración. Allí, necesitamos ir realmente más a fondo y reconocer tus modelos afectados.

Es mucho más difícil de hacer porque no hay herramientas estándar para eso. Por ejemplo, desarrollamos, con la ayuda del compilador de TypeScript, analizamos el trío y lo comparamos con los cambios de Git y realmente lo conectamos entre el código y la prueba mediante un ID de prueba. Así que si se explica en palabras simples, verificamos en qué componentes fueron afectados y si estos componentes son llamados desde pruebas, por ejemplo, tienes un ID de botón de prueba cuando intentas construir una consulta para ejecutar la prueba.

Entonces, si hay una prueba asociada con eso, vamos a ejecutarlas. Y algunos ejemplos concretos para eso. Aquí tenemos alrededor de 600 suites de pruebas para pruebas de integración ejecutándose en Playwright. Pero digamos que solo afectamos a algún, no sé, un modelo. Y al reconocer que solo hay un modelo y tal vez dos, tres, cuatro, diez pruebas asociadas con ellos, podemos reducir este tiempo significativamente.

Es un gran ahorro de tiempo, especialmente si deseas recibir retroalimentación rápidamente. Los resultados, para nosotros, bajamos de horas a minutos para el tiempo de aceptación de PR. Dejamos de desperdiciar nuestros recursos de CI y pagar por ello y ejecutamos solo lo que importa. Y de un ciclo de lanzamiento de tres meses, pasamos a lanzamientos basados en sprints.

Y sobre eso, me gustaría compartir algunos puntos clave contigo, y espero que al menos uno pueda ser aplicado. Así que invierte en la automatización de pruebas, por favor. Cambia a la izquierda si es posible. Comienza simplemente antes. Elige tus capas de prueba. Y no te apresures por algo que es complejo. Intenta obtener las cosas más básicas y primeras. Ejecuta esta estrategia de pruebas. Decide dónde ejecutar qué. Tal vez, tal vez para PRs que están dirigidos a master, realmente no necesitas ejecutar todo, ¿verdad?

Pero tal vez durante tu monitoreo nocturno, te gustaría ver el panorama completo o para tus lanzamientos probar en su totalidad o ejecutar la capa de prueba de extremo a extremo, que es súper costosa allí. Y acelerar con almacenamiento en caché y reconocimiento de cambios.

Sobre eso, gracias por tu atención. Gracias. ¿Has considerado usar TurboRepo? Es increíble en almacenamiento en caché y actualizaciones incrementales. No realmente. Está bien. No realmente. Lo que me gustaría ver, lo que está proponiendo.

La cosa es por qué no estamos adoptando algunos enfoques estándar es más sobre la esencia de nuestro proyecto. Somos multiplataforma, y es difícil, no sé, no podemos usar Expo, por ejemplo, porque estamos siendo pioneros en algún sistema que Amazon hizo hace un año y es como que nadie sabe sobre eso. Así que es un poco difícil usar algo como lo que impulsa la industria. Así que tenemos muchas cosas personalizadas.

Así que tenemos muchas cosas personalizadas. Entendido. Entendido. Alguien dijo, me gustan las imágenes de Ghibli. A mí también me gustan. Son muy geniales. Oh, hay una historia sobre eso. ¿Sí? Sí. Sabes, este hype de la AI y las imágenes de Ghibli, fue hace un año, en realidad. Y la primera vez que hice una presentación fue hace un año, en realidad. Y no ha cambiado mucho desde entonces. Todavía, en realidad, en un año. Así que todas las prácticas que compartí, puedes aplicarlas. Creo que las aplicarás, podrás aplicarlas en uno, dos, tres años hasta que AI reemplace.

También vi que tenías alrededor de 630 pruebas de Playwright de extremo a extremo. Más. ¿Incluso más? Sí, por supuesto. Pero entonces, ¿tu pirámide sigue siendo una pirámide? ¿Cuántas pruebas unitarias y pruebas estáticas tienes? Oh, Jesús. Bueno, las estáticas obviamente cubren todo. Sí. Así que incluso esta prueba desagradable ignora que la gente está usando. Las pruebas unitarias actualmente tienen alrededor del 50% de cobertura. Solo porque comenzamos tarde y nunca consideramos la capa de pruebas unitarias como algo significativo, solo estamos usando entrada-salida. Pero luego comenzamos a ir por la capa de componentes y así sucesivamente. Para pruebas de extremo a extremo, para integración, Cypress Playwright, una gran cantidad, miles de pruebas. Y también, como dije, tenemos una configuración de múltiples proyectos.

Así que dependiendo del proyecto, varía. Pero también tenemos múltiples equipos y varía cuán bien el equipo invierte en la cobertura. Así que cientos y miles. Por eso tuvimos que optimizar.

No podemos simplemente ejecutarlos todos. Sí, tiene sentido. Muy bien.

Veamos. ¿Fue un éxito el traslado de los equipos de QA a ingeniería? ¿Y cómo los apoyaste durante esta transición? Oh, esa es una pregunta difícil. Así que, en primer lugar, no fue idea mía. ¿No? Está bien. Me lavo las manos. Lo intentamos.

Básicamente, nuestros ingenieros de QA se enfrentaban a esta elección donde o bien recibían el paquete si no estaban de acuerdo con esta transición y nos separábamos en muy buenos términos. Y a quienes decidimos intentar y hacer la transición, hubo muchos casos. En primer lugar, fue paso a paso. Como QA manual primero pasó a prueba de ingeniería de software, y luego prueba de ingeniería de software pasó a React. Y ahora con esta transformación, estamos haciendo esta transición de ingenieros de React Native, React a React Native. Así que siempre es como un flujo, es una cuestión de adaptación. Pero tenemos muchas historias de éxito.

Y mi trabajo personal como ingeniero principal es apoyarlos y esa transición para explicar las herramientas y guiarlos con el ejemplo. Sí. ¿Tienen sesiones de intercambio de conocimientos o presupuestos de formación para escalar? Sí, por supuesto. Masterclasses. Encuentros internos y demás. Muy bien. Genial.

Veamos. ¿Cómo manejan las pruebas que actualmente no pueden ser automatizadas? Así que las pruebas de accesibilidad del front-end, por ejemplo, no se pueden realizar de manera confiable. La accesibilidad puede ser parcialmente automatizada.

Hay dolores, pero sí, eso es cierto, especialmente en nuestro mundo donde estamos trabajando con televisores y los televisores no son la historia más fácil de automatizar. Hay una capa de trabajo manual. Pero como dije, compartimos esta responsabilidad entre todos nosotros. Así que todos están probando la característica, incluyendo diseño de producto e ingeniería. Y si necesita hacerse manualmente, todos lo hacen manualmente. Y esta es otra motivación, de hecho, para invertir en automatización.

Una vez que lo haces una vez, no quieres hacerlo dos veces. ¿Todavía tienen muchos dispositivos físicos ya que están operando con mucho hardware? Muchísimos. Sí. Veamos.

¿Cómo asocian las pruebas con los archivos fuente? Las pruebas de extremo a extremo o las pruebas fuera de proceso pueden no tener una importación obvia que declare la dependencia. Nunca digo que sea una imagen 100% precisa. Correcto. Pero este ID, básicamente cualquier elemento interactivo dentro de tu aplicación tiene algún ID de prueba o debería tenerlo. Así que si estás tratando de alcanzarlos por, no sé, consulta, ir a la izquierda, derecha, arriba, o tratando de obtener por nodos dom. Es mejor asignar algún ID único o en este caso, el ID de prueba no es realmente único.

Podría haber una lista repetitiva. Pero todos los elementos interactivos tienen algunos marcadores. Y esto está un poco en la zona gris entre las pruebas de caja negra y algún tipo de entorno de mercado donde el punto de conexión es realmente este ID de prueba. Así que realmente puedes reconocer este ID de prueba. ¿Fue afectado por tus cambios de código? Y este ID de prueba aparece en tus pruebas. Así que si fue afectado, ejecutas la prueba. ¿Cómo lo estamos haciendo exactamente? TypeScript. TypeScript está construyendo tu árbol de modelos de todos modos. Y simplemente tomamos este árbol de TypeScript, lo comparamos con los cambios de git y realmente construimos una lista de las pruebas que nos gustaría ejecutar. Muy bien. Genial.

¿Cómo garantizas que los datos simulados estarán sincronizados, por ejemplo, con los cambios de API del backend? No lo haces. Simplemente lo manejas. Necesitas entender por qué estamos usando simulaciones. Cuál es el propósito de simular. No hacer solicitudes de red. Tener un entorno completamente controlable. Y este es un tipo de prueba muy diferente. Por eso no lo llamamos prueba de integración. La integración es como una prueba de sistema en un entorno altamente simulable, más emuladores. Pero lo que nos da es solo una visualización, ¿verdad? Súper rápido. ¿De acuerdo? Porque puedes omitir este inicio de sesión de solicitud de red, por ejemplo, haciendo muchas cosas. Por supuesto, no será un escenario preciso de extremo a extremo que enfrentará el usuario. Pero cubre alrededor del 95% de todos los problemas. Y para estos escenarios cruciales que realmente necesitas asegurar que funcionen, como autenticación, pagos, y así sucesivamente, sí. Ahí usas pruebas reales, sin simulaciones, dispositivos reales para asegurar que esto suceda. Entendido.

¿Quién es responsable de actualizar las simulaciones? ¿Es la persona del backend que hace el cambio de API? No. Afortunadamente, lo que me gusta de mi empresa es que el backend y el frontend están estrictamente separados. Solo hay una capa P y esta documentación de acuerdo. Así que si el backend está rompiendo algo, simplemente están lanzando una nueva interfaz para nosotros. Y es responsabilidad del frontend cambiar a ellos. Y cuando cambian a ellos, cuando cambiamos a ellos, básicamente estamos actualizando nuestras simulaciones o deprecando o introduciendo nuevas. Así que sí, no hay cambios disruptivos en eso. Y es más responsabilidad del frontend porque son pruebas de frontend. Muy bien.

¿Tus pruebas son alguna vez inestables? ¿Y qué haces si lo son? ¡Sí! Sí, por supuesto. Esa es la verdad. Ese es el dolor. Ese es el mayor dolor. Así que es una historia sin fin.

Estás probando, todo funciona en tu máquina local, estás en CI, todo es inestable, o fue estable durante una semana, ahora se ha ido. Así que, en primer lugar, lo que nos ayuda es la estrategia que estamos considerando para dominar es siempre liberable. ¿Qué significa? Así que si algo sale mal, retrocedemos. Así que tenemos esta hermosa herramienta llamada Git. Nos permite viajar en el tiempo. Así que si hay alguna prueba inestable, dos escenarios. O la vamos a omitir, o la revertiremos, dependiendo de la urgencia, severidad, y así sucesivamente. Y luego, obviamente, el Ticket se reabrirá y el equipo responsable de esta prueba la volverá a trabajar. Entendido.

Así que no hay tonterías, no hay reintentos, ¿lo manejas? Depende de... Lo intentamos. Eso depende. Si tienes suficiente tiempo para estabilizar tu lanzamiento, por ejemplo, está bien, puedes simplemente hacer algunos ajustes. Pero si tienes una hora antes, solo sé práctico. Sí. Muy bien. Muchas gracias, Bogdan. Gracias por compartir. Por favor, den otro aplauso para Bogdan.