¡Ve a buscar lo que podríamos haber pasado por alto!

Rate this content
Bookmark

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.

27 min
18 Nov, 2021

Video Summary and Transcription

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.

Available in English

1. Introducción a las pruebas en Vaisala

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
React Day Berlin 2022React Day Berlin 2022
29 min
Get rid of your API schemas with tRPC
Do you know we can replace API schemas with a lightweight and type-safe library? With tRPC you can easily replace GraphQL or REST with inferred shapes without schemas or code generation. In this talk we will understand the benefit of tRPC and how apply it in a NextJs application. If you want reduce your project complexity you can't miss this talk.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
WorkshopFree
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.