Entrar al mundo del software con una mentalidad de pruebas exploratorias es como llegar a un lienzo de múltiples capas con mucha información y una tarea abierta: ¡encontrar lo que podríamos haber pasado por alto! Esta es la tarea para todos nosotros en los equipos de software en nuestra búsqueda de calidad.
Enmarcar la búsqueda de cómo nuestro sistema no cumple con las expectativas es más fácil cuando podemos ver el software desde la perspectiva del usuario. Sin embargo, las pruebas útiles no son una colección de pruebas de extremo a extremo que automatizamos, sino pruebas excelentes que dejamos atrás y que descomponen el problema de las pruebas de manera diferente. En esta charla, aprenderemos a utilizar la arquitectura como un filtro para descomponer las pruebas y veremos un ejemplo de cómo tomar el control de las respuestas de la API para probar un frontend de React.
Los usuarios no saben ni les importa si el problema está en el frontend y los servicios que su equipo proporcionó si no cumple con sus expectativas, pero a usted le importa. La granularidad de los comentarios es importante. Reconocer los mismos problemas en un alcance incompleto, como características a medio hacer o solo en el frontend o las API, es una habilidad que la industria del software debe desarrollar.
This talk has been presented at TestJS Summit 2021, check out the latest edition of this JavaScript Conference.
FAQ
Mi principal enfoque es actuar como control de calidad para las pruebas realizadas en nuestros equipos, evaluando los resultados y buscando aspectos que otros podrían haber pasado por alto. Generalmente permanezco de seis a doce meses en cada equipo con el objetivo de mejorar sus procesos y resultados.
Utilizo dos tipos principales de pruebas: la creación de artefactos, como la automatización o listas de verificación, y pruebas como un rendimiento, que es más exploratorio e improvisado, permitiendo una interacción más creativa con la aplicación.
Ayudo a los equipos a crecer en la forma en que realizan las pruebas y dejar las cosas mejor después de mi partida. Esto involucra desde la creación de especificaciones hasta la generación de retroalimentación y granularidad en los resultados de las pruebas.
Las pruebas exploratorias son fundamentales, ya que me permiten interactuar directamente con la aplicación y responder a lo que esta 'comunica', lo que aumenta la creatividad y la detección de errores no anticipados.
Los mejores equipos deben combinar varios tipos de pruebas, incluyendo pruebas de unidad, de servicio, de interfaz de usuario (UI), de integración de sistemas y de extremo a extremo, además de utilizar técnicas como la falsificación y simulación para un enfoque de prueba más robusto.
Selecciono herramientas de prueba basadas en la tecnología y las necesidades específicas del equipo, preferentemente aquellas que se integren bien con el código existente en lugar de herramientas basadas en interfaces gráficas.
Mi estrategia incluye realizar pruebas de extremo a extremo en un entorno integrado que simule el entorno de producción real, asegurando que todas las integraciones y dependencias funcionen correctamente juntas.
Maaret Pyhäjärvi, una ingeniera principal de pruebas en Vaisala, enfatiza la importancia de equilibrar diferentes tipos de pruebas para construir mejores equipos. Probar la aplicación con ubicaciones diferentes revela posibles problemas con su comportamiento. El orador destaca la importancia de probar integraciones y dependencias, incluyendo bibliotecas y sistemas operativos. Prefieren herramientas orientadas al código como Requests y Python para las pruebas de API. La única forma de prueba que realizan es la prueba exploratoria, y animan a otros a participar en ella también.
Hola, mi nombre es Maaret Pyhäjärvi y durante el último año y medio de mi carrera de 25 años, he trabajado en Vaisala como ingeniera de pruebas principal. Voy y evalúo los resultados que podemos proporcionar al quedarme dentro del equipo como uno de los miembros del equipo por un tiempo. Repito esto de equipo en equipo, generalmente pasando de seis a doce meses dentro de un equipo, con la idea de dejar las cosas mejor después de irme y ayudar a los equipos a crecer en la forma en que hacen las pruebas.
Una forma interesante de describir lo que hago en mi trabajo es esta idea de que soy el control de calidad para las testing que se realizan en nuestros equipos. Voy y evalúo los resultados que podemos proporcionar al quedarme dentro del equipo como uno de los miembros del equipo por un tiempo.
Muchas veces enmarco mi tarea como ir a buscar al menos algunas de las cosas que otros han pasado por alto. Repito esto de equipo en equipo, generalmente pasando de seis a doce meses dentro de un equipo, con la idea de dejar las cosas mejor después de irme y ayudar a los equipos a crecer en la forma en que hacen las testing. He hecho esto muchas veces a lo largo de mi career para diferentes productos y equipos, uno de ellos es este ejemplo en particular que se muestra en la diapositiva, donde le pedí permiso a un desarrollador de una herramienta de testing basada en API para probar su aplicación y utilizarla como material de capacitación en algunas de las charlas de conferencias que he dado. Luego dieron una entrevista en un podcast diciendo que básicamente la destruí en una hora y media. Esta es una experiencia común que los desarrolladores me cuentan con una sonrisa, espero al menos, en su rostro.
Y generalmente también está relacionado con el hecho de que para ese momento también he tenido conversaciones sobre, sabes, no destruí la aplicación. Lo único que podría haber destruido es la ilusión que nunca fue la realidad. Puedes estar muy orgulloso de tu aplicación. Puede que ya estés haciendo un buen trabajo. Y aún así puede haber cosas que te estás perdiendo. Y tus clientes
2. Testing: Creación de Artefactos y Rendimiento
Short description:
En las pruebas, hay dos tipos: creación de artefactos y rendimiento. La creación de artefactos proporciona especificaciones, retroalimentación, regresión y granularidad. Las pruebas de rendimiento ofrecen orientación, serendipia y ayudan a descubrir problemas inesperados. Para construir mejores equipos, se necesita un equilibrio de diferentes tipos de pruebas, incluyendo la falsificación de componentes y las pruebas con integraciones reales. El sistema debe ser receptivo, fácil de usar y seguro. Un ejemplo de aplicación demuestra el uso de pruebas de front-end y back-end con respuestas simuladas.
podría no estar diciéndote. Así que en todo este trabajo que he hecho, lo he resumido como una receta para mejorar los equipos. ¿Cómo encontramos las cosas que nos faltan? Y comenzamos con dos tipos de pruebas. Está la prueba que se enmarca como una creación de artefactos, ya sea creando automatización o listas de verificación para pruebas repetibles más adelante. Y luego tenemos el otro tipo, las pruebas como un rendimiento, como el teatro improvisado, donde miras la aplicación. La aplicación te habla. Es como tu imaginación externa. Y te hace más creativo. Y todo lo que aprendes, luego lo conviertes en la parte de creación de artefactos de las pruebas. Necesitas ambos lados. Te brindan cosas muy, muy diferentes, donde el estilo de creación de artefactos te brinda especificaciones, retroalimentación, regresión y mi favorito absoluto, granularidad, saber según los resultados que estás obteniendo, qué cambio rompió las cosas y, a partir de los registros, qué está roto ahora, sin tener que pasar varias horas o incluso días analizando tus resultados antes de llegar a las correcciones reales. Estas son cosas que puedes obtener del estilo de creación de artefactos de las pruebas. En el estilo de rendimiento, te brinda cosas un poco más vagas en muchos sentidos, pero también te brinda una especie de guía. Sabes, la dirección, ¿vamos en una mejor dirección? ¿Esto es bueno? ¿Todavía hay más retroalimentación, más conversaciones por tener? ¿Hay algo en lo que necesitemos construir nuestra comprensión y mejorar los modelos? Y mi favorito absoluto, nuevamente, serendipia, accidente afortunado, lo que significa que a veces, algunos de los problemas que necesitamos encontrar son combinaciones interesantes de todo tipo de cosas en las que no pensamos, que solo necesitamos darle tiempo. Entonces, hay un dicho, una cita de Arnold Palmer, un famoso golfista, que no es solo que tenga suerte, es solo que ha estado practicando. Entonces, algo así es la idea general con este estilo de pruebas. Entonces, enmarcado desde los lados, necesitamos algo en el medio para los mejores equipos.
Y lo que necesitamos en el medio son, por supuesto, diferentes tipos de pruebas. Ya sea que provengan del punto de vista de crear artefactos, o que provengan del punto de vista de realizar pruebas y pensar en qué tipo de cosas aún podríamos estar pasando por alto, probablemente probaremos diferentes niveles de interfaces disponibles en el sistema, y trataremos de hacer un conjunto equilibrado de todas las formas diferentes de pruebas, ya sean pequeñas, medianas, grandes, pruebas de unidad, servicio, UI, o pruebas de integración de sistema, o de extremo a extremo, cualesquiera que sean las palabras que desees usar. Probablemente tampoco tendrás solo estos diferentes tipos de pruebas donde básicamente estás ampliando el alcance de las mismas. También probablemente te gustaría tener en esos mejores equipos alguna forma de falsificación, simulación, espionaje, falsificaciones, como quieras llamarlo. Formas de falsificar las respuestas del servicio, los datos, o cualquiera de los componentes que desees excluir del escenario de pruebas para poder tener una retroalimentación enfocada. Pero también quieres probar con las integraciones reales, nuevamente, porque es probable que veas algo diferente allí, y eso es lo que tu cliente terminará usando de todos modos, no las simulaciones que has creado. Probablemente tendrás una base de funcionalidad, pero también las tres otras cosas clave. Debe responder lo suficientemente rápido a las solicitudes del cliente. Debe ser lo suficientemente fácil de entender para que sepas qué hacer con la aplicación. Y los usuarios no deseados deben tener mecanismos para mantenerlos alejados de tu sistema para que cualquier propósito comercial que sirva el sistema, la información también esté segura de otras personas que puedan causarte daño. Entonces, esta es la estructura que creo que necesitamos para los beta testers. Y quería darte un pequeño ejemplo de cómo se aplica típicamente algo como esto en una aplicación. Tomé una pequeña aplicación de ejemplo que se creó básicamente para mostrar la idea de que puedes tener un front-end y un back-end y puedes simular las respuestas del back-end. Así que hay un front-end muy simple de React, una aplicación de React muy simple y la posibilidad de cambiar si estás trabajando contra el
3. Testing the Application with Different Locations
Short description:
La aplicación está claramente creada con fines de prueba, basándose en pruebas de rendimiento manuales. Utiliza una API de mapa del clima abierto y proporciona diversas respuestas basadas en nombres de ciudades, IDs, coordenadas y códigos postales. Las pruebas con diferentes ubicaciones revelan algunos resultados inesperados y posibles problemas con el comportamiento de la aplicación.
el servidor real o el servidor simulado ya está en la interfaz de usuario. La aplicación está claramente creada con fines de prueba en el sentido de que cada vez que lo saco de mis notas y lo ejecuto, los primeros minutos se dedican a actualizar las dependencias que haya. Y después de que las dependencias se hayan actualizado, generalmente tengo que pensarlo por un momento en el hecho de si tengo algún caso de prueba que pueda ejecutar. En realidad, no tengo ninguno, así que confío mucho en el rendimiento manual, en el tipo de pruebas de rendimiento asistidas con esta aplicación. Así que podría comenzar leyendo sobre la aplicación, descubriendo que en realidad utiliza una API de mapa del clima abierto para el clima actual, y resumiendo las cosas para esa API en particular. Y al mostrar las cosas en este esquema, incluso aquí, puedo notar que hace cosas relacionadas con nombres de ciudades, IDs de ciudades, coordenadas, códigos postales. Supuestamente me devuelve diferentes tipos de respuestas. Hay algo de formatos, unidades de medida. Y solo el esquema ya crea una gran cantidad de ideas de lo que podría hacer. Probablemente querría comenzar con una nueva aplicación, tratando de probarla con algo que pueda ver como un escenario positivo básico, algo que sea bastante fácil de verificar. Así que simplemente verificando la ubicación en la que me encuentro y viendo los resultados de eso en este momento, me daría los resultados que puedo verificar simplemente abriendo mi ventana. Y sí, con toda seguridad, muestra exactamente lo que esperaba que fuera el caso para Helsinki, Finlandia. De manera similar, puedo imaginar otras ubicaciones, Sydney siendo una de las ubicaciones que está más lejos de mi hogar en la que he viajado. Así que parece un lugar perfecto para ir y probar. Pero en comparación con mi ubicación, en realidad no estoy obteniendo muchas diferencias aquí, nubes rotas, pocas nubes, no muy diferentes. Así que esperaba ver sol y un icono completamente diferente aquí en la interfaz de usuario. Pero no tuve suerte con eso. Pero nuevamente, generando más ideas, me di cuenta de que podría y he escrito Sydney con un error tipográfico antes. Y me di cuenta de que me sorprende que incluso cuando escribo mal las cosas, probando Sydney y muchos otros errores tipográficos pequeños pero habituales, parece que la API realmente me da la respuesta correcta aunque no sea muy precisa en mi solicitud. Y esto me hace, por supuesto, un poco curioso, pero simplemente tomo nota de ello, una nota mental. Recordando la descripción de la API, recuerdo que había una idea de que también puedo consultar, al menos desde la API, puedo consultar según un código postal o como el código de ubicación. Y primero quiero probar mi propia ubicación, este vecindario mismo en el que estoy en Finlandia. Y para mi sorpresa, no me ubica en Helsinki, Finlandia, sino en Vantaa, Finlandia. Y eso se considera una ciudad diferente, así que no está del todo bien. Y también se suponía que debía ingresar ciudades. Esto no parece una ciudad para mí. Así que obteniendo algunas ideas sobre lo que puedo hacer con la aplicación. De manera similar, pensando en los códigos postales que todos conocemos, 90210 de la serie bastante famosa de antaño. Espero ver Beverly Hills y nuevamente me decepciono, notando que tal vez haya una razón por la cual esto solo debería permitirme ingresar una ciudad para no decepcionarme siempre cuando ingreso el código postal de un área. Así que definitivamente no esperaba terminar en México. Después de haber mirado la interfaz de la aplicación, reviso un poco la especificación y descubro que hay, hay una idea
4. Testing with Mock Data and Integration
Short description:
La aplicación se basa en datos meteorológicos actuales, lo que dificulta probar ciertas características. Para superar esto, el orador sugiere tomar el control sobre los datos y utilizar técnicas de simulación. Proporcionan un ejemplo de cómo configurar un servidor simulado y modificar los datos meteorológicos para probar escenarios específicos. A través de este proceso, descubren problemas con los iconos, los horarios de salida y puesta del sol y las conversiones de temperatura. El orador enfatiza la importancia de probar todas las integraciones y dependencias, incluyendo bibliotecas, sistemas operativos y componentes coexistentes potenciales.
sabes, cosas interesantes sobre ideas de diferentes tipos de climas. Como podría ser una tormenta, podría haber llovizna, incluso podría haber un huracán. Y dado que la aplicación se basa en gran medida en el clima actual, tratar de adivinar ahora mismo dónde en el mundo podría haber un huracán, eso no funcionará muy bien. Y de manera similar, estando aquí en Finlandia en medio de la noche con nubes, no puedo verificar realmente los iconos de día y noche y si funcionan correctamente, como se describe en las especificaciones, con los data que tengo a mi disposición. Entonces, lo que suelo hacer, ya sabes, intentando hacer pruebas adecuadas, es tomar el control de los data. Hay muchas formas de hacerlo. Y la simulación, por supuesto, es una de las formas que podríamos considerar. Y cambiando al servidor simulado, bueno, al iniciar el servidor simulado al principio, puedo ejecutar algunos de los casos de prueba que he preparado que configuran stubs para diferentes tipos de configuraciones. Y aquí tengo un stub con el clima en Utsjoki. Utsjoki es una ubicación en Finlandia desde donde guardé una respuesta en horario de verano en un momento en el que no hay puesta de sol ni salida de sol, porque así es como están ciertas ubicaciones en el norte de Finlandia en pleno verano. Así que configuré eso en Utsjoki y configuré los data de Utsjoki para que, bueno, solo cambio los detalles de cómo es el clima. Así que los horarios y todas esas cosas, los dejo como están. Pero puedo agregar una tormenta. Y sí, definitivamente. Ahora puedo verificar que sí, si esta es la respuesta que obtendríamos, puedo ver un nuevo tipo de icono, puedo ver los textos. Y solo las partes que esperaba que cambiaran están cambiando. Y obviamente, la primera vez que hice esto, no fue tan sencillo averiguar qué data pertenecía junto. Pero me llevó un poco de investigación. También sé ahora que si bien el icono de tormenta funciona bastante bien, hay otros iconos disponibles que la aplicación aún no ha implementado, por lo que no funcionarán tan perfectamente. De manera similar, noté con la aplicación que cuando el sol no se pone en absoluto en verano, definitivamente esperaría que los horarios de salida y puesta del sol sean los mismos. Pero también me hace darme cuenta de que hay un error tipográfico, no es `sunshine`, debería ser `sunrise`, y ya no es tan fácil pasarlo por alto, y estoy bastante seguro de que esta aplicación que encontré en línea es de alguien en la zona horaria IST, lo que significa en algún lugar de las zonas horarias de Asia, en lugar de un vecino mío aquí en Finlandia. Así que me da ideas de cosas que han sido relevantes para el creador, pero también limitarán lo que la aplicación puede hacer en este momento. Investigando un poco más, siendo curioso acerca de las temperaturas, rápidamente me adentro en el código y descubro que hay algo muy interesante sucediendo aquí con la aplicación convirtiendo las temperaturas a grados Celsius. Llegan en Kelvin y rápidamente me doy cuenta de que esto se debe al hecho de que al configurar este stub y la URL allí, hay un pequeño error tipográfico en esa URL que hace que no obtenga los grados Celsius para esta aplicación directamente desde la API, lo que resulta en esta necesidad adicional de implementar la transformación por separado. Si viera esto con el manejo del tiempo, sería una preocupación mucho mayor, porque el manejo del tiempo y todas las excepciones relacionadas con el manejo del tiempo son notoriamente difíciles de crear por uno mismo, así que utiliza lo que tengas y, bueno, lo mismo se aplica a las temperaturas. Entonces, con este ejemplo, lo que quiero mostrarte es que para los mejores equipos y prácticamente cualquier equipo que aspire a ser mejor. Comenzamos con nuestra cosa. En este caso, mi cosa, nuestra cosa, la cosa de mi equipo, es la pequeña aplicación creada en React, y se beneficia de integrarse en la API pública de otra persona. Se ejecuta sobre algunas bibliotecas, se ejecuta sobre un sistema operativo, y todos ellos son parte de las cosas e integraciones que debemos probar. Y también se ejecuta junto a otras cosas que no deberían tener un impacto en ella, como las extensiones del navegador, que aún podrían tenerlo, hay muchas cosas diferentes que podrían necesitar coexistir.
QnA
Approach to Testing and Exploratory Testing
Short description:
En las pruebas, abordamos las aplicaciones, sistemas y sistemas integrados con curiosidad, deseando comprender cómo funcionan las cosas. La automatización es impulsada por alguien que la supervisa, y cuando falla, nos invita a explorar más. Comprender nuestra propia arquitectura y responsabilidades, y cuidar a nuestros usuarios, es crucial. La colaboración es clave, y culpar a individuos no es productivo. Las preguntas sobre las mejores herramientas para las pruebas de API dependen del equipo y el contexto. Personalmente, prefiero herramientas orientadas al código como Requests y Python. Las pruebas exploratorias son importantes para mí, y es el único tipo de pruebas que realizo.
Hay ciertas expectativas por parte de los usuarios y las partes interesadas. Por lo general, son razonables de alguna manera y también son parte de las cosas que debemos considerar al abordar las pruebas. Si aprendes de las pruebas que has realizado y te das cuenta de que deberían funcionar de manera diferente, que tenías una expectativa de que deberían funcionar de manera diferente, pero la evidencia empírica muestra que, al probarlo, el programa no está de acuerdo contigo, el programa ganará y habrá un programa diferente antes de que puedas hacer que el programa esté de acuerdo contigo, por lo que hacemos cambios basados en la evidencia empírica. Tratamos de evitar la especulación acumulada, debemos abordar cuán confiables, cuán confiables son nuestras pruebas y, en general, abordamos las aplicaciones, los sistemas, los sistemas integrados, las necesidades de los usuarios y las expectativas de los usuarios con curiosidad y deseando comprender cómo funcionan las cosas. La automatización juega un papel, pero la automatización es impulsada por alguien que la supervisa. Entonces, cada vez que la automatización falla, es como una invitación para que exploremos más y estamos explorando para crear la automatización en primer lugar. Cuando tenemos buenas preguntas sobre cosas que deben abordarse con la aplicación, como por ejemplo, si se ejecuta a largo plazo, la automatización puede ser muy útil para comprender eso. Pero todo comienza desde la comprensión de nuestra propia arquitectura, nuestras propias responsabilidades y el cuidado de nuestros usuarios, no solo en las cosas que escribimos personalmente, sino en todo lo que integramos intencional o involuntariamente.
Ten un buen tiempo probando, espero que lo disfrutes. Bienvenido y gracias, fue realmente genial tu charla. ¿Qué opinas sobre los resultados que hemos recopilado aquí? Estaba viendo estos números y me estaba riendo aquí solo porque soy un firme creyente de que no hay un individuo que sea responsable de este tipo de cosas. Es una colaboración y hay capas donde intentamos atrapar cosas y la idea de que casi el 20 por ciento, el 19 por ciento, encontraría a un individuo, pero no siempre es el sospechoso habitual, que son los probadores. Es interesante verlo en las encuestas. En un año, si alguien hace esto, estará en la categoría de mayoría. Fue un poco sorprendente ver cómo cambian los números en cuanto a quién se le echará la culpa a medida que llegaban las respuestas, y pensé, bueno, bueno. Por supuesto, como mencionaste, la mayoría de las veces creo que la gente se volverá hacia el probador. Pero de 80, creo que tenemos un buen comienzo y podemos apuntar a la perfección del 100 por ciento. Tal vez alguien solo esté jugando con los botones. Míralo, no hagas eso.
Genial. Creo que deberíamos hacer algunas preguntas entonces. Henry pregunta, ¿cuáles son, en tu opinión, las mejores herramientas para las pruebas de API y la automatización de las pruebas de API? Trabajo con muchos equipos diferentes con muchas tecnologías diferentes. En este momento, por supuesto, personalmente, ya que estoy en un equipo con mucho Python, estoy convencido de que Requests y Python son las mejores herramientas. Hace medio año, estaba trabajando con un equipo de JavaScript y Java, y estaba absolutamente convencido de que SuperTest era la mejor herramienta porque eso es lo que estábamos usando en ese momento. Realmente se trata de qué equipo es, pero estoy mucho más inclinado a herramientas orientadas al código, algo que se ajuste bien al código en lugar de herramientas orientadas a la interfaz gráfica de usuario. Así que creo que esa es la opción general que elijo. Eso es genial. Realmente creo que, nuevamente, no hay nada que gobierne sobre todo lo demás, como una única solución, y eso cambia según el contexto en el que estés trabajando al mismo tiempo. ¿Cuándo y con qué frecuencia realizas pruebas exploratorias? ¿Después del lanzamiento? Sé que este es un tema muy importante para ti. Sí, es muy importante para mí. Así que no realizo ninguna otra prueba que no sea la prueba exploratoria.
Exploratory Testing and Identifying Dependencies
Short description:
La automatización es mi forma de explorar cosas que un humano regular no podría. Dividimos entre pruebas de características y pruebas de lanzamiento. Invitamos a todos en la empresa a realizar pruebas exploratorias. Las pruebas de conjunto en grupos más pequeños ayudan a las personas a aprender cómo realizar pruebas exploratorias adecuadas. Identificar cosas relevantes para coexistir implica analizar dependencias y solicitar imágenes de arquitectura o un entorno de prueba de extremo a extremo.
Respondo. Pero la automatización para mí es parte de cómo documento mis pruebas exploratorias. Y la automatización es mi forma de poder explorar algunas de las cosas que un humano regular sin el uso de la automatización no podría. Así que para mí, todo eso es prueba exploratoria. Quizás lo más interesante sea la división entre pruebas de características y pruebas de lanzamiento, que son los dos conceptos que utilizamos a nivel del sistema. Y aproximadamente el 99% de nuestro trabajo se realiza en el lado de las características, ya solo realizamos verificaciones básicas en el momento del lanzamiento. Pero esto es algo en lo que todavía estamos tratando de avanzar hacia ningún trabajo manual en el momento del lanzamiento. Mientras tanto, el trabajo de pensamiento debe realizarse mientras construimos las características.
De hecho, de hecho. Mark agregó que realizamos pruebas exploratorias principalmente cerca de los principales lanzamientos. Invitamos a todas las personas de la empresa, ya sean desarrolladores o vendedores, a unirse. Pero el desafío siempre es cómo enseñarles a tener éxito, por supuesto, como probador exploratorio en casi ningún tiempo. ¿Cuál es tu enfoque en las visitas de prueba mientras intentan esto hasta ahora? No he reunido a las personas para realizar sesiones exploratorias como esta desde hace unos años. Cuando reúno a las personas, reúno a un grupo un poco más pequeño, generalmente alrededor de 10 personas a la vez. Y hacemos pruebas de conjunto, lo que significa que compartimos una sola computadora. Y yo me encargo de facilitar para que todos aprendan cómo hacer esa prueba exploratoria y utilicen las habilidades de todos en eso. Entonces al haber realizado pruebas de conjunto y permitirles correr y explorar libremente, es probable que sepan un poco más sobre cómo hacer pruebas exploratorias adecuadas. Puedes darles ideas de recorridos o pedirles que encuentren los errores de los que están preocupados, investiguen áreas de su experiencia, cualquiera de ellos son realmente buenos puntos de partida. Pero depende mucho de qué información consideres valiosa y dar esa orientación a tu equipo de exploradores.
Oh, eso es bueno. De hecho, hacemos algo similar cuando creamos pros y contras de esto es no lo que pedimos cuando también hacemos algunas fiestas de prueba. Y Martin dijo que mencionaste que las cosas con las que tu equipo coexiste también son muy importantes. ¿Cómo abordarías la identificación de las cosas relevantes para coexistir? Mirando a nuestro alrededor, tengo una lista mental de las cosas en las que dependemos. Todo lo que está en el sistema operativo, todo lo que está en la red, todo lo que está en la plataforma, todo lo que está en los equipos vecinos. Así que como poder etiquetar todo eso y averiguar quiénes son, pedir imágenes de arquitectura y simplemente señalar una caja en esa imagen de arquitectura. Eso probablemente nos ayuda mucho. Otra forma tal vez más sencilla es pedir un entorno de prueba de extremo a extremo y asegurarse de que todo pase por eso, para que luego no tengas que entender todas las dependencias, pero tienes que ver que funcionan juntas en un entorno integrado.
Sí, creo que eso es importante. Muchas gracias, Merit, nuevamente, tanto por la charla como por tu respuesta a estas preguntas. Estamos muy agradecidos de tenerte aquí. Fue genial. Gracias.
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
Today's Talk introduces TRPC, a library that eliminates the need for code generation and provides type safety and better collaboration between front-end and back-end. TRPC is demonstrated in a Next JS application integrated with Prisma, allowing for easy implementation and interaction with the database. The library allows for seamless usage in the client, with automatic procedure renaming and the ability to call methods without generating types. TRPC's client-server interaction is based on HTTP requests and allows for easy debugging and tracing. The library also provides runtime type check and validation using Zod.
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()? En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor. Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
La web ha evolucionado. Finalmente, también lo ha hecho el testing. Cypress es una herramienta de testing moderna que responde a las necesidades de testing de las aplicaciones web modernas. Ha ganado mucha popularidad en los últimos años, obteniendo reconocimiento a nivel mundial. Si has estado esperando aprender Cypress, ¡no esperes más! Filip Hric te guiará a través de los primeros pasos sobre cómo empezar a usar Cypress y configurar tu propio proyecto. La buena noticia es que aprender Cypress es increíblemente fácil. Escribirás tu primer test en poco tiempo y luego descubrirás cómo escribir un test de extremo a extremo completo para una aplicación web moderna. Aprenderás conceptos fundamentales como la capacidad de reintentar. Descubre cómo trabajar e interactuar con tu aplicación y aprende cómo combinar pruebas de API y de UI. A lo largo de todo este masterclass, escribiremos código y realizaremos ejercicios prácticos. Saldrás con una experiencia práctica que podrás aplicar a tu propio proyecto.
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles. Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador. Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E. Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes. Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman. Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend. Nivel de la masterclass: Intermedio
Comienza con la Rejilla de Datos React de AG Grid con un tutorial práctico del equipo central que te llevará a través de los pasos para crear tu primera rejilla, incluyendo cómo configurar la rejilla con propiedades simples y componentes personalizados. La edición comunitaria de AG Grid es completamente gratuita para usar en aplicaciones comerciales, por lo que aprenderás una herramienta poderosa que puedes agregar inmediatamente a tus proyectos. También descubrirás cómo cargar datos en la rejilla y diferentes formas de agregar renderizado personalizado a la rejilla. Al final de la masterclass, habrás creado una Rejilla de Datos React de AG Grid y personalizado con componentes React funcionales.- Comenzando e instalando AG Grid- Configurando ordenación, filtrado, paginación- Cargando datos en la rejilla- La API de la rejilla- Usando hooks y componentes funcionales con AG Grid- Capacidades de la edición comunitaria gratuita de AG Grid- Personalizando la rejilla con Componentes React
Comments