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

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

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

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

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.

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.

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.