Tus pruebas carecen de visión: Agregando Eyes a tu marco de automatización

Hola a todos. La charla de hoy trata sobre las pruebas visuales. Pero primero, comencemos con un pequeño juego de quién lo hizo.

Claramente alguien en esta habitación asesinó al Lord Smythe, quien a las 3:34 de esta tarde fue brutalmente golpeado hasta la muerte con un objeto contundente. Quiero que cada uno de ustedes me diga dónde estaban exactamente en el momento en que se cometió este acto infame.

Yo estaba puliendo el latón en el dormitorio principal. Yo estaba untando mantequilla en los bollos de Su Señoría abajo en la cocina, señor. Yo estaba plantando mis petunias en el cobertizo de herramientas. Agente, arreste a la Lady Smythe. ¿Pero cómo lo supo? Señora, como cualquier horticultor le dirá, no se plantan petunias hasta que termine mayo. Llévensela. Así es, señora. Es solo una cuestión de observación. La verdadera pregunta es qué tan observadora fue usted.

Claramente alguien en esta habitación asesinó al Lord Smythe, quien a las 3:34 de esta tarde fue brutalmente golpeado hasta la muerte con un objeto contundente. Quiero que cada uno de ustedes me diga dónde estaban exactamente en el momento en que se cometió este acto infame. Yo estaba puliendo el latón. En el dormitorio principal. Yo estaba untando mantequilla en los bollos de Su Señoría abajo en la cocina. Pero yo estaba plantando mis petunias en el cobertizo de herramientas. Agente, arreste a la Lady Smythe. ¿Alguno de ustedes notó alguna de las diferencias? ¿Quizás la más grande donde el hombre muerto se levantó y se fue caminando? Probablemente no. Y eso se debe a que todos sufrimos de lo que se llama ceguera involuntaria. La ceguera involuntaria es cuando algo nuevo e inesperado entra en tu campo de visión y tú no lo ves porque estás tan enfocado en otra cosa. Y esto es especialmente cierto cuando hablamos de pruebas de nuestro software. Estamos enfocados en la característica que hemos escrito y queremos que funcione, y nos estamos perdiendo todo lo que está sucediendo a su alrededor. Entonces, ¿cómo compensamos esto típicamente? Automatizamos la prueba. Porque si automatizamos la prueba, sabemos que todos nuestros pasos se registrarán, y todas nuestras verificaciones se verificarán, y podemos garantizar que esas cosas sucederán cada vez. Pero, ¿qué pasa con las cosas inesperadas, verdad? Lamento decirte que cuando automatizas tu prueba, en realidad estás escribiendo en el guion la ceguera involuntaria, y te pierdes otras cosas que pueden estar sucediendo en tu aplicación, como la apariencia, ¿verdad? Usando las herramientas de automatización tradicionales, automatizamos esas pruebas.

Está buscando en el DOM, y es ahí donde se está interrogando para darnos la respuesta a nuestras preguntas. Por ejemplo, ¿este texto está presente en esta pantalla? Busca en el DOM. El texto está presente. Nos dice que sí, la prueba pasa. Pero, ¿qué pasa si ese texto es del mismo color que el fondo y nuestros usuarios no pueden verlo? ¿Qué pasa si se desborda de los bordes de la página, ¿verdad? ¿Qué pasa si está cubierto por algún otro elemento, y por lo tanto nuestros usuarios no pueden leerlo o interactuar con él, si es un botón o algo así?

Estos son errores visuales. Y cuando hablo de errores visuales y pruebas visuales para solucionar errores visuales, muchas veces la gente dice, oh, eso es interesante. Ya sabes, y lo considera como algo agradable de tener, pero déjame decirte, los errores visuales están presentes en todas las aplicaciones, grandes o pequeñas. Permíteme darte un par de ejemplos. Aquí está Cineworld. Cineworld es la segunda cadena de cines más grande del planeta. Y tenían un error visual en la página que te pregunta si quieres almacenar la información de tu tarjeta de crédito. Esto se ve un poco extraño. Ja ja, podemos reírnos de ello, ¿verdad? Estas etiquetas no están alineadas con los botones, pero déjame hacerte otra pregunta. ¿Almacenarías tu información de tarjeta de crédito en esta página? Yo no lo haría. ¿Por qué no? Bueno, como Kim ha insinuado en este tweet, parece que no han probado su aplicación. Y si miras esto, piensas, oh chico, si se les pasó esto, quién sabe qué más se les pasó, ¿verdad, en el backend con mi tarjeta de crédito. Así que no, por supuesto que no, no voy a almacenar mi información de tarjeta de crédito en esta pantalla. Pero tengo una teoría. Creo que probaron esto. De hecho, creo que automatizaron la prueba para esto. Si automatizaron la prueba para esto, entonces con la consulta del DOM, estas etiquetas están ahí, los botones de radio están ahí. No es un problema interactuar con ellos. Pero desde la perspectiva del usuario, esto es realmente malo, ¿verdad? Pierdes confianza en la aplicación.

Aquí hay otro ejemplo, OpenTable. OpenTable se utiliza para hacer reservas en restaurantes. Solía vivir en Carolina del Norte hace un par de años y volví a visitar y quería quedar con algunos de mis amigos. Fui a hacer una reserva de buen tamaño en uno de mis lugares de barbacoa favoritos. Carolina del Norte es conocida por la barbacoa. El lugar de barbacoa era The Pit y yo estaba haciendo una reserva para siete personas. Me dieron algunas horas para elegir y seleccioné el horario de las 7 pm.

Cuando seleccioné este espacio, apareció un modal y me tomó un minuto entender, qué se supone que debo hacer aquí porque no hay nada en el centro, ¿verdad? Mientras seguía mirando un poco, noté que aquí en esta esquina, puedo ver un par de botones de selección, pero esto me confundió aún más. ¿Qué estoy seleccionando? ¿Por qué hay dos de ellos que no están alineados y no hay nada aquí que me diga qué estoy seleccionando? Así que hice lo que cualquiera de ustedes haría. Abrí Chrome DevTools y comencé a investigar el DOM para tratar de entender qué estaba pasando. Y cuando hice eso, me di cuenta de que las etiquetas realmente estaban allí. Simplemente estaban lo más lejos posible de los botones. Así que siendo quien soy, completé mi reserva y pude disfrutar de la barbacoa, pero no pude evitar pensar en los muchos, muchos clientes que no son ingenieros y que no tienen idea de qué son las Chrome DevTools. No están buscando en el DOM para hacer una reserva en tu aplicación. No, simplemente la cierran. Y si son millennials como yo, seguramente no te van a llamar por teléfono, simplemente pasan a otro restaurante, ¿verdad? Así que piensa en cuánto negocio se perdió debido a este error visual.

Esto es lo que más ocurre. Esto también le sucede a tus empresas de tecnología favoritas. Como Amazon, en su vista móvil, alguien no solo quería comprar algo, sino que quería aumentar la cantidad, es decir, multiplicar la cantidad de dinero que querían gastar en su cara con este error visual. Esto es específicamente en el marketplace de Facebook. Entonces vas al marketplace, intentas comprar algo, mira el texto aquí y cómo simplemente se va por el costado de la página y se superpone en las imágenes. Esto es muy difícil de leer. Esto no me da ganas de gastar dinero, ¿verdad? Pero si consultara el DOM y preguntara si ese texto está presente, diría, sí, claro que sí. Así es como este tipo de cosas llega a producción.

Instagram, este es uno de mis favoritos porque se trata de contenido patrocinado. Es decir, alguien pagó a Instagram para obtener una ubicación premium para su anuncio y esto es lo que obtuvieron en su lugar. Todo el texto está amontonado uno encima del otro, ¿verdad? Nuevamente, consultando el DOM, ¿está presente este texto? ¿Está presente este texto? ¿Está presente este texto? Sí, sí, sí, envíalo, ¿verdad? Twitter, lo mismo. Texto superpuesto, una prueba automatizada no podría detectarlo. Google, incluso Google, por Dios. Este no es tan malo como los otros, pero hey, es un punto de compra. Y así que algún ingeniero de Google muy bien pagado tiene que dejar de innovar nuevas funciones para ir y arreglar esto. Afortunadamente, no tenemos que vivir así, gente.

La validación visual se puede automatizar. Entonces, ¿qué es exactamente la validación visual o las pruebas visuales? Las pruebas visuales son cuando escribes tu primera prueba para una función, ya sabes, la primera vez, y verificas que sí, esto se ve exactamente como quiero que se vea. En ese momento, podemos tomar una captura de pantalla de tu aplicación. Y luego, en cada ejecución de regresión, tomamos otra captura de pantalla, y las comparamos. Si hay alguna diferencia, la prueba falla. Esto captura todo y elimina la ceguera involuntaria, ¿verdad? Pero ten cuidado. Las pruebas visuales no son algo nuevo. De hecho, han estado presentes en la industria desde hace tiempo, pero la técnica que muchos proveedores estaban utilizando no era ideal para las pruebas, ¿verdad? Entonces, la forma en que la mayoría de las soluciones de pruebas visuales compararán las imágenes es píxel a píxel. Bueno, eso es extremadamente inestable, déjame mostrarte. Aquí está Google y digamos que esa primera captura de pantalla es cuando nuestra prueba es perfecta, nuestra aplicación es perfecta. Y así es la captura de pantalla de referencia. En la segunda captura de pantalla, que es una ejecución de regresión, la comparamos en los campos de prueba de regresión. ¿Quién puede ver por qué? Sí, ese botón de búsqueda de Google está en negrita en la segunda captura. Bueno, cuando el cursor está sobre ese botón, eso es el efecto de desplazamiento.

Esta es una prueba automatizada, tal vez se esté ejecutando como parte de CI o algo así. Realmente no tenías control sobre dónde el cursor había aterrizado y, por lo tanto, ahora tu implementación está bloqueada, no es lo que quieres.

Aquí hay otro, ¿quién puede ver por qué falló este? Sí, debido a ese cursor detrás de la palabra `malo`. Los cursores parpadean. Entonces, si sucede tomar la captura de pantalla cuando el cursor está sólido y luego sucede tomar una captura de pantalla de regresión cuando no lo está, eso también puede causar un fallo.

No quieres que tus implementaciones se bloqueen por esto y tener que investigar por qué sucedió, tampoco quieres escribir código de automatización que intente evitar este tipo de cosas, ¿verdad? Afortunadamente, Applitools ha desarrollado un mejor enfoque para hacer esto utilizando el aprendizaje automático. Así que imita el ojo humano y el cerebro y es capaz de resaltar y detectar solo lo que importa en la prueba.

Tengo otro juego aquí. Todos ustedes no pueden jugar porque dejaron que el hombre muerto caminara en el primer juego. Pero en este, lo ejecuté a través de la comparación píxel a píxel y lo ejecuté a través del algoritmo de aprendizaje automático de Applitools para ver, ¿cuál es la diferencia y cómo lo detecta. Y este es el que usa la comparación píxel a píxel, nota que todo está resaltado aquí, como cada pequeño cambio de desplazamiento blanco, no está destinado a las pruebas. En comparación con cuando lo ejecuté a través del algoritmo de Applitools, resaltó las cosas que yo como ser humano habría resaltado, ¿verdad?

Entonces, bien, agreguemos esto a una prueba, una prueba existente. Aquí está nuestra aplicación en la prueba, una aplicación de una sola página, muy simple, ocho de mis libros favoritos sobre automatización de pruebas. Ingresas algún texto en ese campo y eso filtrará los libros, así que solo se mostrarán los que tengan `pruebas` en el título, ¿de acuerdo? Entonces aquí está la prueba para hacer esto. Esto está escrito en Cypress con JavaScript, pero Applitools tiene SDK para todas las diferentes herramientas de automatización y todos los diferentes lenguajes de programación. Entonces, si usas algo diferente, bien por ti, pero esto es JSConf, ¿verdad?

Entonces, bien, esto es Cypress JavaScript. Estamos consultando la palabra `prueba`. Esperamos que vuelvan estos cinco libros. Ingresamos eso en el campo, y luego tenemos dos validaciones aquí. Una valida que el número de libros que son visibles sea el mismo que el que esperamos, y cada uno de esos títulos que está en el array de libros esperados realmente sea visible, ¿de acuerdo?

Genial, ahora me pongo un poco loco con el CSS y quiero agregar un efecto de rebote, pero realmente no sé lo que estoy haciendo, pero está bien porque tengo pruebas, lo que significa que puedo hacer lo que quiera. Así que agrego la línea seis aquí a este CSS y lo confirmo, ¿verdad? Mi prueba me avisará si algo está mal. Nuevamente, aquí está mi prueba, mírala detenidamente. Y así es como se ve la aplicación con ese nuevo CSS. ¿Atrapará mi prueba esto? Veamos. Ejecuto esto con Cypress nuevamente, nota todo el verde aquí. No hay rojo, a pesar de que literalmente he volteado mi aplicación al revés. Ese es el problema. Por eso necesitamos pruebas visuales.

Entonces, ¿cómo lo agregamos? Muy simple. Tres líneas de código, casi como poesía, ¿verdad? A partir de la línea tres, usamos la API de Applitools y se integra muy bien con Cypress.

Así que mira aquí, se convierte en un comando lateral. Decimos, abre los ojos. Le damos el nombre de nuestra aplicación. La siguiente línea, esto es la magia, verifica la ventana, esto toma la captura de pantalla. Lo envía a la nube de Applitools. Applitools almacena todas tus imágenes en su nube para que no tengas que preocuparte por el espacio en disco ni nada por el estilo. Línea final, cierra los ojos. Hemos terminado aquí, amigos.

Así que ejecutamos esta prueba y ahora, nota que la prueba falla porque detecta, chica, volteaste tus libros al revés, ¿verdad? Y resalta todas las diferencias para mí, ¿de acuerdo? Esto es genial para eliminar la ceguera no intencional, ¿verdad, pero incluso podríamos limitarlo? ¿Qué tal si solo queremos un libro? Por ejemplo, mira la línea dos. Solo voy a buscar ágil testing, sabiendo que solo hay un libro que regresa. Y así no quiero probar toda la página porque podría haber mucho sucediendo en esta página que realmente no me importa y quiero limitarlo al libro. Para limitarlo, uso el mismo comando de verificación de ventana, pero paso un objetivo, que dice, quiero apuntar a una región específica y le doy el selector CSS para esa región, ¿de acuerdo? Ese es el ID. Y luego nota que la captura de pantalla solo capturará este libro, pero cuando lo limitamos de esta manera, debemos tener mucho cuidado porque podríamos reintroducir la ceguera no intencional. Por ejemplo, supongamos que este filtro está roto. Ingreso la palabra prueba aquí y ninguno de los libros desaparece. ¿Pasará nuestra prueba visual o fallará? Si dijiste que pasaría, tienes razón. Porque recuerda, solo teníamos una imagen de ese libro. Dijimos, mira ese libro. ¿Es visualmente perfecto? Claro que sí. Pasa. Así que todavía tenemos que usar nuestro cerebro. Aunque estamos utilizando el aprendizaje automático en nuestras pruebas, todavía estamos en control. Así que puedo combinar mis afirmaciones. No tiene que ser todo visual. Puedo agregar esa funcional de nuevo, ¿verdad? Así que mira la línea tres. Estoy diciendo, asegúrate de que solo haya un libro visible. Esa es la afirmación funcional. Y una vez que eso sea cierto, puedo decir, ahora, haz la prueba visual. Así que eso lo hace realmente, realmente poderoso.

¿De acuerdo? También puedo hacer contenido dinámico aquí. Así que no pensarías que podrías verificar contenido dinámico con pruebas visuales, pero puedes hacerlo con las herramientas de Applitools, ¿verdad? Este es un nivel de coincidencia. Hay varios niveles de coincidencia diferentes. Esto lo hace muy detallado y flexible. Pero este diseño está diciendo, quiero que uses el aprendizaje automático de una manera diferente para detectar el diseño de mi página.

Por ejemplo, esta primera captura de pantalla, estos son los libros en un orden. La segunda captura de pantalla muestra los libros en otro orden. Debido a que dije que verifique esto utilizando el algoritmo de diseño, solo detectará los patrones en la página. Muy popular para sitios de noticias. Cuando trabajaba en Twitter, utilizábamos ese nivel de coincidencia para los tweets. No sabemos qué van a decir, pero queremos asegurarnos de que estructuralmente la página esté bien, que las cosas no se superpongan o se salgan del borde, ¿verdad? Entonces, aunque los libros estén en un orden diferente, esto aún pasa.

Y luego lo último que quiero mostrarte es la capacidad de ejecutar esto en múltiples plataformas. Applitools tiene esta cuadrícula ultra rápida que funciona perfectamente con eyes. Y lo que hace es permitirte ejecutar tus pruebas en cualquier navegador o dispositivo que desees de forma simultánea. Y la forma en que lo hace es capturando el estado de tu aplicación y luego enviándolo a todos esos dispositivos. Entonces no necesitas el teléfono físico, no tienes que lidiar con eso en absoluto. Ni siquiera tienes que cambiar tu prueba. Simplemente agrega esta línea, comenzando en la línea cuatro, tenemos una matriz que básicamente dice, esto es lo que quiero. Quiero Firefox, Chrome, IE en estas dimensiones. Quiero iPhone 10 en modo horizontal y vertical. Quiero Galaxy. Y todo esto se ejecuta simultáneamente de forma extremadamente rápida. Bastante genial. Y eso es cómo se vería en la cuadrícula. Observa aquí, se ejecutan muchas pruebas, en todos los diferentes dispositivos. Muy, muy, muy genial. También funciona para componentes. Entonces, si tienes Storybook para Angular, Vue, React, esto puede verificar tus componentes y asegurarse de que tus selectores de fecha, campos, botones, todo se mantenga visualmente perfecto mientras el resto de tus equipos utilizan estas cosas. ¿De acuerdo? Ahí lo tienes. Eso es la prueba visual en pocas palabras.

¿Qué preguntas puedo responder para ti?

Hola, Alex. ¿Cómo estás?

Estoy bien. Estoy tratando de sobrevivir. ¿Y tú?

Sí, estoy bien. Estoy aguantando.

Genial. Tenemos varias preguntas. Probablemente voy a destrozar los nombres de las personas que hicieron las preguntas. Yuval quiere saber, ¿debería tener regresión visual en todas mis páginas o solo en algunas críticas? Si es así, ¿cuáles son las críticas? Esa es una buena pregunta. Deberías tener pruebas visuales en tus páginas estables, ¿verdad? Si tienes una aplicación que está en constante mantenimiento, por ejemplo, esta página específica, donde constantemente agregas nuevos componentes y aún no es del todo estable, puede que no sea un buen candidato para las pruebas visuales. Sin embargo, podrías utilizar la API de manera creativa y decir, ignora esta sección activa de la página o verifícala como contenido dinámico que va a cambiar o algo así. Podrías hacerlo, pero mi recomendación es utilizarlo en tus páginas más estables.

Vale, eso es muy bueno, eso es muy bueno. Tienen una pregunta de seguimiento que dice, ¿cómo puedo minimizar los falsos positivos? ¿Hay alguna forma de marcar los cambios como intencionales de antemano? Oh, eso es bueno. Diría que no es algo de antemano, pero podría ser antes de que sea parte de tu CI o algo así, ¿verdad? Podría ejecutar algo localmente. Digamos que desarrollo, cambio una función, eso cambia el sitio web. Y sé que la línea de base va a cambiar. Así que puedo ejecutar eso localmente. Y cuando falle, simplemente puedo dar un pulgar hacia arriba. Eso es todo lo que se necesita, un pulgar hacia arriba o hacia abajo para decir si es intencional o no. Y puedo decir, este es un cambio intencional, verificarlo. Y luego, cuando se ejecute como parte del conjunto más grande, estará bien.

Vale, eso tiene mucho sentido. Eso tiene mucho sentido. Manuel quiere saber, ¿cómo pruebas visualmente la página que carga contenido dinámico, como una lista cambiante de usuarios, por ejemplo? Bueno, puedes hacer esto en el panel de control. Applitools tiene un panel de control que te permite anotar la imagen. Así que puedes combinar los diferentes niveles de coincidencia, ¿verdad? Hablé del nivel de coincidencia dinámico. Hablé del nivel predeterminado, que era un modo estricto.

Puedes combinar y mezclar. Puedes decir, por ejemplo, como esa lista, esta parte es dinámica, todo lo demás, quiero que lo verifiques de forma regular. Algunas personas lo usan mucho para fechas, marcas de tiempo, ese tipo de cosas que cambian constantemente en el sitio, por lo que puedes anotarlo. Y puedes hacerlo en el panel de control o puedes hacerlo de forma programática dándole el selector CSS de ese elemento para que pueda decir lista de usuarios, cualquier identificador o lo que sea, puedo especificarlo de forma programática para no tener que volver y anotarlo en el panel de control.

Una forma genial en la que lo uso es con las pruebas móviles. En la parte superior de tu móvil está la barra de estado, ¿verdad? Con tus notificaciones y la hora, todo lo que está ahí arriba es dinámico. Así que de forma programática digo que siempre ignore ese elemento específico de la barra de estado y así, cuando escribo nuevas pruebas móviles, ya ignora esa parte. Oh, eso es realmente interesante. Eso es bastante interesante. Gracias.

¿Cómo garantiza Appy Tools que los resultados de las pruebas no sean inconsistentes? Sí, utiliza aprendizaje automático, que es diferente al píxel a píxel. Tenemos una precisión del 99,5% y, debido a que utiliza aprendizaje automático, mejora cada vez más a medida que aprende más sobre las cosas que se consideran inconsistentes o no.

De acuerdo, de acuerdo. Tenemos muchas preguntas sobre Appy Tools. Voy a seguir con eso porque es algo nuevo para mí al menos. No lo he usado antes y quiero saber más. Teniendo en cuenta las capacidades y beneficios de las pruebas visuales, ¿sigue siendo beneficioso realizar pruebas de instantáneas o incorporar Appy Tools las vuelve obsoletas?

Bueno, si estás pensando en las pruebas de instantáneas, como sé algunas formas de hacerlo. Una es capturar el DOM o lo que sea, el estado completo de la aplicación y luego compararlo. Entonces tienes estos cambios de tipo textual, ¿verdad? En mi opinión, eso es un poco más frágil que el de imagen, ¿verdad? Porque puedo cambiar el código subyacente sin cambiar los aspectos visuales de la página, ¿verdad? Así que esto conduce a un mantenimiento adicional para realizar estas pruebas de instantáneas pero sigue siendo una opción viable.

De acuerdo, de acuerdo. Eso tiene sentido, eso tiene sentido. Tengo una pregunta que creo que está relacionada así que voy a saltar a eso. ¿Qué hay de las pruebas de accesibilidad? ¿Existe alguna posibilidad de automatizarlas?

Sí, Appy Tools también tiene funciones de accesibilidad y esto es genial. Es una excelente manera de utilizar las pruebas visuales fuera de lo común. Tiene este probador de contraste. Por lo tanto, se asegura de que todos tus elementos cumplan con las pautas AA o, ya sabes, las pautas AA o lo que sea, en cuanto a la accesibilidad. Por lo tanto, es algo que puedes activar o desactivar.

De acuerdo, de acuerdo, eso tiene mucho sentido. Eso tiene mucho sentido. Una pregunta más, es rápida y luego podemos dejarte ir a tu sala de conferencias. ¿Tienes una opción local para el servidor de Applitools?

Sí, la opción local, por supuesto, es más costosa. Hay un plan gratuito para todos. Todos pueden usarlo de forma gratuita. Si necesitas más funciones, más capacidades, puedes actualizar, pero la opción local es más, pero sí, está disponible para nuestros clientes que son bancos, atención médica. Ellos utilizan la opción local.

De acuerdo, de acuerdo. Gracias. Has tenido tantas preguntas, Angie. Es realmente, realmente difícil para mí hacerte todas esas preguntas. Así que para las personas a las que no les he hecho las preguntas, lo siento mucho, pero Angie tiene una sala de conferencias en spatial.chat. El enlace para unirse está en tu línea de tiempo y puedes unirte a Angie en la sala y hacerle todas las preguntas que no le he hecho. Así que gracias, Angie, por unirte hoy. Fue realmente, realmente bueno ver tu charla y tener la oportunidad de hablar contigo un poco. Muchas gracias. Claro. Adiós, Alec. ♪♪