Mantenimiento de la calidad de extremo a extremo con pruebas visuales

Las pruebas son una parte fundamental del flujo de trabajo de cualquier desarrollador. Nos ayuda a asegurarnos de que nuestro proyecto mantendrá un alto nivel de calidad, así como a evitar que los molestos errores salgan a la luz.

Pero a menudo las pruebas automatizadas pueden ser difíciles de manejar. Entre una cantidad interminable de código para asegurarse de que está brindando una cobertura completa y lidiando con la naturaleza frágil de las pruebas de front-end, donde un simple cambio de selector puede romper por completo un flujo de trabajo de extremo a extremo, a veces puede parecer cuesta arriba. batalla.

Al agregar pruebas visuales automatizadas , podemos eliminar esas pruebas escamosas, nivelando nuestras canalizaciones de prueba proporcionando esa cobertura (y más) aprovechando las comparaciones de imágenes inteligentes usando capturas de pantalla de nuestro sitio web o aplicación.

Antes de sumergirnos en las pruebas visuales, tomemos un minuto para refrescarnos sobre los diferentes tipos de pruebas automatizadas y cómo encajan entre sí. Luego hablaremos sobre qué es exactamente la prueba visual y cómo puede brindarle otro nivel de cobertura de prueba para su proyecto.

Un vistazo rápido a algunos de los tipos de pruebas automatizadas

Las pruebas automatizadas son una parte interesante del ciclo de desarrollo. Algunos clientes o partes interesadas pueden ver claramente el valor que brindan, pero otros preferirían que el tiempo de desarrollo se dedique exclusivamente al desarrollo de funciones.

Esto a veces puede ser contradictorio, donde el objetivo de las pruebas automatizadas es proteger el negocio o evitar que el equipo tenga que dedicar tiempo a corregir errores en primer lugar. ¡Escribir pruebas automatizadas sólidas puede evitar grandes pérdidas financieras! En última instancia, es un riesgo que algunos están más dispuestos a correr que otros.

Afortunadamente, ese valor no siempre es difícil de vender, y cuando tenemos tiempo para centrarnos en pruebas automatizadas de calidad, tenemos una variedad de opciones sobre cómo abordar esas pruebas, como pruebas unitarias, pruebas de integración, pruebas de extremo a extremo. pruebas y pruebas visuales (que también pueden proporcionar una cobertura ampliada para las tres primeras).

Cuando se aplica con los puntos fuertes de cada tipo de prueba, podemos dedicar más tiempo a escribir pruebas que realmente pueden ayudar a proteger nuestro trabajo y evitar la frustración de nuestros clientes.

Echemos un vistazo a cómo se ven algunas de estas estrategias de prueba en la práctica.

Examen de la unidad

Las pruebas unitarias se enfocan en probar áreas más pequeñas y enfocadas de una aplicación . ¿Quiere probar que una función que calcula el total de un pedido después de las promociones funciona correctamente? Querrías escribir una prueba unitaria.

 function myBusinessLogic(pricePerItem, quantity, discount) { const subtotal = pricePerItem * quantity; return subtotal - ( discount * subtotal ); } expect(myBusinessLogic(2, 4, .1)).toEqual(7.2);

La gran parte de las pruebas unitarias es que son baratas de escribir y no requieren mucho tiempo para ejecutarse. Es por eso que a menudo verá que las empresas dedican mucho tiempo a crear un conjunto de pruebas unitarias para capturar esas piezas granulares de una aplicación.

Pero debido a esas pruebas enfocadas, es posible que las pruebas unitarias no cubran cómo funcionan juntas esas diferentes piezas, que es donde comenzamos a pasar a las pruebas de integración.

Pruebas de integración

El objetivo de las pruebas de integración es tomar las piezas y los componentes más pequeños de una aplicación y probar cómo funcionan juntos . Un ejemplo común podría ser cómo una parte particular de una interfaz de usuario responde a las interacciones seguidas de solicitudes a un servidor o base de datos.

 cy.get('.add-to-cart').click(); cy.url().should('contain', 'cart'); cy.get('.cart li').contains('My Item');

Es muy posible que su pequeño componente de interfaz de usuario funcione como se espera por sí mismo. Sus eventos sintéticos pueden activarse correctamente en una instancia de onClick. Ese código que envuelve sus solicitudes de API podría funcionar perfectamente con algunos datos simulados. Pero puede haber agujeros entre esas dos piezas que trabajan juntas que las pruebas unitarias podrían no detectar.

Las pruebas de integración son una forma convincente de probar su aplicación, pero puede ir un paso más allá mientras busca probar "todas las cosas".

Pruebas de extremo a extremo

Las pruebas de extremo a extremo capturan el viaje completo de un usuario de extremo a extremo para un flujo de trabajo enfocado. Por ejemplo, si estoy construyendo una tienda de comercio electrónico, el "camino feliz" (o el camino esperado con la menor resistencia) sería encontrar un producto, agregarlo a un carrito y pagar por esos artículos. Si estoy escribiendo una prueba de extremo a extremo, capturaría todo el proceso, es decir, desde encontrar un producto en una página de listado de productos hasta pagar por ese artículo.

 cy.visit('/products'); cy.get('.product a[href="/product/1234"]').click() cy.url().should('contain', 'product/1234'); ... cy.get('.order-button').click(); cy.url().should('contain', 'receipt'); cy.get('.receipt li').contains('My Item');

La gran parte de las pruebas de extremo a extremo es que es esencialmente una gran prueba de integración. Está capturando muchos componentes diferentes de la aplicación, incluido cómo funciona la interfaz de usuario, que las API responden correctamente y que esas piezas funcionan juntas.

El problema es que las pruebas de extremo a extremo, e incluso las pruebas de integración, tardan más en escribirse y también tardan mucho más en ejecutarse. Entonces, ¿ cómo podemos aprovechar todas nuestras opciones de prueba y armar un conjunto de pruebas que brinden una manera eficiente de cubrir nuestra aplicación?

Aprovechar los diferentes tipos de pruebas

Hay una variedad de mentalidades que generalmente describen cuántas pruebas de cada tipo debería dedicar tiempo a escribir.

A Mike Cohn se le ocurrió el concepto de la "pirámide de prueba" en su libro Succeeding with Agile .

Argumenta que debería escribir más pruebas unitarias donde sean menos costosas de escribir y más rápidas de ejecutar. Si bien su diagrama original etiqueta las diversas pruebas de manera un poco diferente, a medida que se inclina más hacia las pruebas de tipo de integración, se vuelven más lentas de ejecutar y más costosas de escribir. Si bien esas pruebas son valiosas, no desea tener tantas integraciones o pruebas de un extremo a otro como lo haría con las pruebas unitarias.

Tener este equilibrio puede ayudarlo a concentrarse en capturar las partes críticas de la aplicación, como la lógica empresarial con pruebas unitarias y cómo funcionan junto con las pruebas de integración, pero Kent C. Dodds argumenta que la tecnología de prueba se ha puesto al día hasta un punto en el que no hay grandes compensaciones de costos más largas para escribir pruebas de integración, que es donde entra en juego su concepto del "trofeo de prueba".

En los entornos de desarrollo modernos, tenemos muchas herramientas increíbles a nuestra disposición, como Cypress, Selenium y Playwright, que brindan a los desarrolladores e ingenieros de control de calidad la capacidad de escribir pruebas que interactúan fácilmente con navegadores como Chrome y Firefox.

Con Cypress, escribir una prueba que haga clic en un botón podría verse tan simple como:

 cy.get('#my-button').click()

Podría decirse que es tan simple como probar que el botón funciona con eventos sintéticos, si no más simple. La mejor parte es que está probando cómo funciona realmente ese botón en un navegador.

Independientemente del diagrama al que se suscriba, en última instancia, el objetivo es sopesar las diferentes opciones entre el costo y la velocidad para determinar la opción adecuada para su aplicación en particular. Es importante no solo alcanzar ese 100% en su informe de cobertura, sino también asegurarse de que la experiencia que brinda a los visitantes funcione como debería.

Pero no importa la combinación de pruebas que ejecute, estas pruebas programáticas que solo interactúan y prueban el DOM (Document Object Model) carecen de una gran pieza del rompecabezas: cómo sus visitantes ven visualmente esa aplicación.

Qué tipos tradicionales de pruebas no capturan

A medida que ejecuta su unidad, integración y pruebas de extremo a extremo en su aplicación, todas tienen una cosa en común. Todos están probando el código.

Lo que quiero decir con eso es que no están probando lo que realmente ve el visitante de su aplicación.

Si está ejecutando un conjunto de pruebas de integración y, como nuestro ejemplo anterior, prueba que alguien puede agregar un producto a un carrito y comprarlo, en cada paso del camino, está encontrando un elemento en el DOM a través del código y confirmando que funcionó de la misma manera.

Esto no prueba cosas como si el texto de su página es legible o no. ¿Alguien agregó un cambio de CSS que accidentalmente hizo flotar todas las cosas hacia la izquierda y las volteó boca abajo?

Estos tipos de errores se conocen como "errores visuales", donde pueden pasar todas sus pruebas con gran éxito, pero cuando alguien realmente los mira, no es del todo correcto o, peor aún, completamente inutilizable.

Siendo realistas, no podemos esperar brindar una cobertura completa del 100 % de cada detalle de una interfaz de usuario con las pruebas tradicionales. Entre la cantidad interminable de estados de la aplicación y el hecho de que siempre estamos agregando nuevas funciones, simplemente no escala.

Esto es lo que nos lleva al titular de esta historia: Pruebas visuales .

¿Qué son las pruebas visuales?

Visual Testing captura la salida visible (como una captura de pantalla) de una aplicación y la compara con la misma aplicación en otro momento.

Esto suele suceder al capturar primero una captura de pantalla de línea de base o una instancia capturada previamente de la aplicación con los resultados esperados y comparar cada nueva prueba con esa línea de base.

Pero a medida que se desarrolla su proyecto, las cosas cambian. A medida que pase el tiempo, esa línea de base se actualizará junto con su aplicación a medida que apruebe nuevas diferencias visuales como cambios aceptados.

Tipos de pruebas visuales

Una cosa interesante acerca de las pruebas visuales es que hay diferentes formas de manejar esto.

Un enfoque para probar visualmente es mediante el uso de comparaciones píxel por píxel en las que el marco de prueba marcará literalmente cualquier diferencia que vea entre dos imágenes. Si bien tales comparaciones brindan un nivel de entrada a las pruebas visuales, tienden a ser escamosas y pueden generar muchos falsos positivos.

Como puede imaginar, cuando se trabaja con la web, las cosas tienden a ser ligeramente diferentes entre las cargas de la página y las actualizaciones del navegador. Si el navegador desvía la página en 1 píxel debido a un cambio de representación, muestra el cursor de texto o "simplemente porque sí", es posible que sus implementaciones se bloqueen debido a estas pruebas fallidas.

Sus pruebas también son propensas a fallar cuando se trata de contenido dinámico. Por ejemplo, si realizó pruebas visuales diarias píxel por píxel en la página de inicio de este sitio, Smashing Magazine , obtendrá muchas pruebas fallidas a medida que producen más y más contenido.

Una mejor manera de manejar las pruebas visuales es aprovechar la tecnología como la IA, donde cada vez que se ejecuta una prueba, el marco de prueba analiza de forma inteligente la captura de pantalla en comparación con la línea de base.

Puede detectar que las dos capturas son diferentes o incluso detectar si se trata de un cambio de contenido en lugar de un cambio de diseño. No marcará esa prueba como fallida si algo no cambió realmente e incluso puede agregar reglas para ignorar las regiones dinámicas de una aplicación que podrían cambiar debido a ese contenido.

Donde ayudan las pruebas visuales

Las pruebas visuales prosperan al poder capturar el estado actual de una aplicación tal como lo vio su cliente. Esto lo hace atractivo para cualquier aplicación que tenga humanos reales interactuando con ella.

Mientras captura esa instantánea, brinda cobertura de muchas partes de esa aplicación, no solo un único componente granular para el que escribió una prueba. Termina capturando el contexto en torno a ese componente, lo que lleva a una cobertura más amplia.

Esto se convierte en una gran manera de proporcionar una amplia cobertura con gastos generales bajos . Volviendo a la pirámide de prueba o al trofeo de prueba, podemos proporcionar una cobertura completa además de todas nuestras otras pruebas.

¿Cómo funcionan las pruebas visuales?

La esencia es simple: comparar dos imágenes entre sí y buscar la diferencia, pero es un poco más complicado que eso.

Comparaciones de imágenes

Al implementar pruebas visuales, el objetivo será proporcionar cobertura para flujos de trabajo críticos que puedan capturar cómo una persona real está usando la aplicación. Eso a menudo incluye la primera pantalla que alguien puede ver, pero esa no suele ser la única pantalla que ven.

Al igual que crear una estrategia sobre cómo ejecutar pruebas tradicionales, debe asegurarse de buscar interacciones reales que terminen con resultados reales en la interfaz de usuario, como agregar un artículo a un carrito de compras o agregar un artículo favorito a su lista de deseos.

Con eso en mente, querrá capturar una captura de pantalla de cada paso del camino. Por ejemplo, si estaba probando una tienda en línea, es posible que desee agregar pasos para lo siguiente:

• Lista de productos cargados en una página;
• Página del producto después de seleccionar un solo producto;
• Interfaz de usuario del carrito en la página después de agregar un producto a ese carrito;
• Página del carrito después de navegar al carrito;
• Interfaz de usuario de pago y envío una vez que ingresa al flujo de pago;
• Página de recibo después de la compra exitosa.

Esto capturará los resultados de todas las interacciones a medida que alguien se abre camino a través de su tienda en línea, donde puede verificar que no solo funciona funcionalmente desde la perspectiva del código, sino que la persona puede usar su aplicación sin errores visuales que interfieren.

Bits técnicos

Mientras avanza en la planificación de capturas de pantalla, necesitará un mecanismo para automatizar esas tareas. Algo que puede interactuar con un navegador basado en un conjunto de tareas.

Aquí es donde entran en juego los marcos de automatización de navegador populares como Selenium, Cypress y Playwright, donde esos marcos de prueba aprovechan las API del navegador para ejecutar sus comandos, encontrando y haciendo clic en cosas como lo haría un humano, donde luego le diría al marco de prueba visual cuándo capturar el estado de la interfaz de usuario visualmente.

En el caso de Cypress y Applitools, Cypress navegaría por cada página, donde el SDK de Applitools extraería una instantánea del DOM y enviaría esa instantánea a la nube de Applitools, donde finalmente generaría capturas de pantalla para comparar.

En ese momento, dependiendo de la plataforma de prueba visual, obtendrá un conjunto de resultados en forma de diferencias resaltadas o una bonita marca de verificación verde si todo se ve bien.

Integración con marcos de prueba existentes

Al igual que la integración de Cypress y Applitools anterior, la integración suele tener poca fricción. Muchas de las plataformas de prueba visual disponibles pueden integrarse directamente en los marcos de prueba existentes, en su mayoría solo depende de los SDK que tengan disponibles.

 cy.visit('/product/1234'); cy.eyesOpen({ appName: 'Online Store', testName: 'Product Page' }); cy.eyesCheckWindow(); cy.eyesClose();

Esto significa que normalmente no necesita reescribir completamente su conjunto de pruebas para fortalecer sus pruebas y obtener cobertura visual; puede agregar esos puntos de control a las pruebas que ya tiene.

Pruebas de automatización

Afortunadamente, la automatización del desarrollo y las tareas relacionadas con las pruebas ha madurado rápidamente, lo que brinda muchas opciones excelentes sobre cómo podemos automatizar nuestras pruebas.

Las soluciones tradicionales de CI/CD como Jenkins o Travis CI le permiten ejecutar sus pruebas en sus entornos junto con el resto de la canalización de integración e implementación. Relativamente nuevas en el espacio de la automatización son herramientas como GitHub Actions, donde proporcionan un mecanismo similar a los entornos tradicionales de CI/CD, pero justo dentro de su repositorio de GitHub existente. Esto hace que sea fácil ganar cuando intenta ejecutar sus pruebas y otras tareas de código automáticamente, donde no necesita un sistema completamente nuevo, sino que usa sus herramientas existentes.

 name: Node.js CI on: [push, pull_request] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - run: npm ci - run: npm test

Pero independientemente del entorno que utilice, en última instancia, está sujeto a los requisitos del marco de prueba. Cypress funciona bastante bien donde sea que pueda instalar Node.js, lo cual es bastante común en estos días, siempre que tenga acceso a un navegador sin interfaz como Electron o Chrome. Otros pueden requerir un poco de entorno adicional, pero en ese punto, normalmente puede montar ese entorno como desee, creando las condiciones que necesita para ejecutar sus pruebas.

¿Cuáles son los beneficios de las pruebas visuales?

Las pruebas visuales proporcionarán una amplia variedad de beneficios como algunos de los que ya discutimos, pero realmente ayudan a todas las partes interesadas, incluidos ejecutivos, gerentes de productos, desarrolladores, diseñadores y realmente cualquier otra persona en el equipo.

Por ejemplo, para un director ejecutivo o un gerente de producto, está ganando la confianza de que la cobertura de su prueba realmente captura el uso del mundo real . Para el equipo de desarrollo, está ganando la misma confianza de que cada vez que realice cambios, obtendrá comentarios inmediatos, eliminando el factor de miedo involucrado cuando intenta moverse rápidamente. Pero también hay muchos beneficios prácticos.

Menos código para mantener

Al integrarse con una plataforma de prueba visual, la mayor parte de su código girará en torno a dos cosas: interacciones y capturas de pantalla.

Las interacciones consisten esencialmente en navegar a través de una aplicación, encontrando qué página o flujo de usuario desea capturar. Independientemente de cómo esté probando, es probable que necesite mantener esto de una forma u otra.

Las capturas de pantalla, por otro lado, cubrirán todas las afirmaciones que normalmente escribiría en una prueba. Al comparar cada captura de pantalla con una línea de base, automáticamente se asegura de que cada componente de su proyecto funcione exactamente como se esperaba.

Las pruebas son menos frágiles

Y al usar esas capturas de pantalla como su mecanismo de afirmación, sus pruebas serán menos escamosas y frágiles.

Si está escribiendo una aserción contra una parte particular del DOM, como usar una ID o un selector generado automáticamente, se está arriesgando a una prueba de ruptura con cualquier cambio en ese componente.

Con una identificación, alguien podría simplemente eliminarla o cambiarla accidentalmente. Tal vez pensó que era solo para fines funcionales y lo actualizó cuando reelaboró ​​las cosas, lo que terminó rompiendo la prueba (¡me pasó a mí!).

O si usa selectores generales, generados automáticamente o no, tienden a ser muy específicos, ya que está probando partes muy específicas de la aplicación . Si termina anidando algo de HTML o moviendo un poco las cosas en el código, incluso si no cambió su apariencia visual, podría terminar rompiendo esa prueba.

Probar lo que la gente realmente está usando

Hablando de probar cómo se ve visualmente, cuando se trata de pruebas visuales, está probando lo que sus visitantes o clientes realmente ven.

El uso de HTML semántico adecuado no hace que su proyecto sea utilizable automáticamente. Un pequeño cambio de CSS (como el índice z) puede cambiar por completo la usabilidad y el aspecto de algo.

Al capturar una captura de pantalla y comparar el estado real de la aplicación a través de las interacciones del flujo de un usuario, puede asegurarse de que su aplicación funcione funcionalmente y de que sea utilizable por más que solo robots de automatización.

Lectura recomendada : Gestión de CSS Z-Index en grandes proyectos

Probando cosas que no pensaste probar

También obtiene cobertura de diferentes partes de su aplicación que ni siquiera pensó en probar.

Considere la lista de pruebas que tiene en su suite, esas son las que pensó escribir o escribió porque anteriormente encontró un error. ¿Qué pasa con el resto de la aplicación?

Esa captura de pantalla capturará más detalles y contexto que sus otras pruebas podrían no haber incluido.

¿Qué no cubre la prueba visual?

Pero las pruebas visuales no pretenden ser una solución definitiva para reemplazar todo el conjunto de pruebas. Al igual que los otros tipos de pruebas, debe coexistir, llenando los vacíos de las demás y, en última instancia, brindando una cobertura más significativa.

Probar la lógica empresarial basada en datos

A medida que realiza pruebas visuales, es posible que pueda capturar algunos aspectos de su lógica comercial, como asegurarse de que cuando alguien agregue un artículo al carrito, las matemáticas se verifiquen, pero es probable que su tienda en línea tenga una variedad más amplia. que solo ese producto.

Todavía es importante capturar esa lógica comercial compleja con pruebas unitarias, asegurándose de capturar diferentes casos de uso, como el impacto de varios descuentos en ese total.

Pruebas completas de API

Cuando se trata de API, puede pensar en una prueba visual como una prueba de integración. Podemos probar que, al interactuar con el navegador, nuestra lógica de solicitud funciona como se esperaba. Pero no proporciona una visión completa de cómo funciona esa API.

De manera similar a la lógica comercial, su API aún debe estar respaldada por un conjunto de pruebas que garantizarán que funcione como se espera, como pruebas unitarias o controles de estado.

Primeros pasos con las pruebas visuales

Como otra herramienta en nuestro cinturón, las pruebas visuales realmente pueden ayudar a proporcionar otro nivel de cobertura que nos ayuda a mantener un alto nivel de calidad para nuestras aplicaciones, pero ¿por dónde empezamos?

Encajar en el ciclo de vida del desarrollo

Debido a que las pruebas visuales ayudan a trabajar hacia los objetivos de todas las partes interesadas, esto realmente puede encajar en cualquier parte del ciclo de vida del desarrollo.

Por ejemplo, tradicionalmente las pruebas solo se usan para validar que el código funciona según lo previsto, pero también podemos usar pruebas visuales para la transferencia de diseño y la colaboración de UX . Los diseñadores del equipo pueden conectar sus maquetas como referencia y usarlas fácilmente para comparar la experiencia real.

Pero desde la perspectiva del código, las pruebas visuales pueden prosperar en entornos automatizados, como ejecutar comprobaciones en solicitudes de extracción, en entornos de prueba antes de la implementación y asegurarse de que la producción se vea bien después de la implementación.

Incluso puede ejecutar sus pruebas visuales en un cron, reemplazando sus eventos sintéticos de verificación de estado, que generalmente son inestables y nunca le dicen realmente en qué estado se encuentra su aplicación.

Afortunadamente, hay muchas opciones tanto para el servicio que usa como para los puntos de integración para usar esos servicios.

Soluciones disponibles para pruebas visuales

Determinar con qué solución avanzar depende de elegir la biblioteca o el servicio que usará para ejecutar las pruebas. Como cubrimos anteriormente, el mayor diferenciador será el tipo de prueba visual que brindan estos servicios.

Muchas plataformas utilizan pruebas visuales píxel por píxel para realizar comprobaciones. Esto incluye herramientas como Percy y Chromatic que marcarán los cambios entre dos capturas de pantalla.

Luego están las pruebas visuales impulsadas por IA, donde Applitools es realmente el único servicio que actualmente brinda esa capacidad. En lugar de simplemente verificar las imágenes píxel por píxel, Applitools compara de manera inteligente las imágenes evitando cualquier prueba escamosa o falsos positivos , brindando una detección de cambios significativa.

Independientemente de la solución, en última instancia deberá integrarla en su entorno de desarrollo, ya sea que esté comenzando desde cero o agregándola a un marco de prueba existente.

Integración de pruebas visuales

Al integrar la plataforma de prueba visual de su elección, tiene la opción de comenzar desde cero o la ruta más fácil de integrarse en su marco de prueba existente. Herramientas como Applitools hacen que esto sea fácil, donde la gran variedad de SDK que se admiten ayudan a facilitar el acceso a los flujos de trabajo existentes.

Un buen ejemplo de esto es si ya está configurado y funcionando con Cypress:

 it('should log into the application', () => { cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.get('h1').contains('Dashboard'); });

Si ya está realizando pruebas programáticas, simplemente puede superponer pruebas visuales para proporcionar otra capa de cobertura.

 it('should log into the application', () => { cy.eyesOpen({ appName: 'My App', testName: 'Login' }); cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.eyesCheckWindow(); cy.eyesClose(); });

Y algunos SDK lo hacen aún más fácil, donde si ya está ejecutando una biblioteca Storybook, todo lo que necesita hacer es instalar el paquete con npm y ejecutar un comando simple, luego tiene una cobertura completa de todos sus componentes.

 npm install @applitools/eyes-storybook --save-dev npx eyes-storybook

En última instancia, la pregunta más importante es qué marco de prueba querrá usar y si el servicio que desea usar es compatible con ese marco.

Usos creativos de las pruebas visuales

Además de obtener otro nivel de cobertura de pruebas para su aplicación, hay una variedad de otras formas en las que puede aprovechar las pruebas visuales.

• Supervisión del tiempo de actividad
  Ejecute regularmente una prueba visual significativa en lugar de la típica supervisión del tiempo de actividad con eventos sintéticos frágiles.
• Diseño/Colaboración UX
  Desde el traspaso hasta los problemas de usabilidad, use pruebas visuales para brindarle a todo el equipo un medio para colaborar.
• Pruebas de accesibilidad
  Capture problemas clave que pueden limitar la accesibilidad de su aplicación.
• Instantáneas históricas
  La ejecución periódica de una prueba visual puede ayudarlo a capturar instantáneas, lo que le brinda fácilmente una forma de hacer referencia a un estado anterior del proyecto.
• Pruebas de localización
  Con las pruebas visuales basadas en IA que pueden detectar cambios de contenido, tiene la capacidad de asegurarse de que todo se vea y funcione como se espera, sin importar el idioma. Bonificación: puede reducir los gastos generales al intentar comparar diferentes versiones de un idioma determinado.

Al agregar el elemento visual a sus pruebas, obtiene más opciones para agregar formas significativas de mantener un alto nivel de calidad para su aplicación.