Pruebas de Producto (con Erin Hess de Crema)

Michael Luchen

Se dedica mucho tiempo a hablar de cómo construir productos, pero ¿qué pasa con probar el producto? ¿Cuáles son los enfoques, posturas y disciplinas que intervienen para garantizar que un producto esté debidamente probado y respalde a los usuarios para los que fue creado? Hoy nos acompaña en el programa una experta en ingeniería de pruebas para profundizar con nosotros en lo que define este rol tan importante dentro de un equipo de producto, cómo colaboran con los gestores de producto y por qué quizás sean la clave de la empatía dentro del equipo. No te lo pierdas.

Esto es el pódcast de The CPO Club: las voces de la comunidad que está escribiendo el manual para la gestión, desarrollo y estrategia de productos. Somos patrocinados por Crema, una agencia digital de productos que ayuda a personas y empresas a prosperar a través de la creatividad, la tecnología y la cultura. Más información en crema.us. Sigue escuchando para obtener ideas auténticas y prácticas que te ayuden a tener éxito en el mundo de la gestión de productos.

Hola a todos. Me emociona mucho hoy dar la bienvenida a Erin Hess al programa. Tuve el placer personal de conocer a Erin cuando recientemente trajo su talento a nuestro equipo en Crema como ingeniera senior de pruebas. Erin cuenta con un conjunto único de habilidades tanto creativas como técnicas, adquiridas durante 12 años de experiencia en varios cargos de desarrollo e ingeniería de software.

Comenzó su carrera en atención al cliente antes de convertirse en programadora autodidacta y desarrollar un gusto especial por las pruebas de software. Defensora del usuario por naturaleza, entre los principales puntos fuertes de Erin se encuentran la empatía, la visualización y la anticipación del comportamiento y la comunicación. A Erin le gusta crear mapas de procesos e imaginar dónde podrían estar los puntos de dolor. Al ponerse en los zapatos de otros, ver los problemas desde diferentes ángulos y analizar las consecuencias y beneficios a largo plazo de las acciones de hoy, Erin ha logrado hacer la diferencia en cualquier equipo y producto al que se une.

Erin también ayuda a las organizaciones a adoptar e implementar prácticas de diseño inclusivas, creando y difundiendo conciencia sobre barreras de usabilidad universales. Defiende la accesibilidad y contribuye continuamente con materiales de recursos a comunidades de pruebas en línea en constante crecimiento.

Hola, Erin. Bienvenida al programa.

Erin Hess

Muchas gracias por esa gran introducción, Michael. Estoy feliz de estar aquí.

Michael Luchen

Genial. Debo decir que personalmente estoy muy emocionado por esta conversación. Creo que una de las cosas sobre el ingeniero de pruebas y el gestor de productos es que puede dar los mejores resultados, pero realmente no se habla tanto de ello.

¿Lista para comenzar?

Erin Hess

Oh, absolutamente.

Michael Luchen

Muy bien.

Así que quiero empezar desde lo general para algunos oyentes que quizás recién están entrando a este mundo, tal vez no tienen un ingeniero de pruebas en su equipo y realmente quieren entender el rol. ¿Podrías contarnos algunas de tus actividades favoritas como ingeniera de pruebas?

Erin Hess

Oh, totalmente. Hay muchas, y realmente es un tema del que podría hablar durante horas. Hay tantas actividades que puedes hacer siendo tester. Una de mis favoritas en general es construir relaciones y conocer a los equipos con los que trabajo, ya sea desarrollador, diseñador, gestor de producto, otros ingenieros, soporte al cliente, incluso marketing en ocasiones.

Y en proyectos únicos, como cuando se trata de un proyecto de colaboración, también conocer a los recursos del lado del cliente. He encontrado un nicho en la redacción de documentación técnica. Aprecio tener el tiempo y espacio para dar el nivel correcto de detalle y descripción, con ayudas visuales útiles.

Si puedo ser creativa e incluir una foto de un gato frente a una computadora, lo haré. También me gusta aprender nuevas herramientas y trabajar en pareja con otros ingenieros. Es algo que realmente me motiva.

Michael Luchen

Genial. ¿Cómo abordas la construcción de relaciones con tus equipos, especialmente desde la perspectiva que necesita tener una ingeniera de pruebas?

Erin Hess

Soy muy abierta y sé que cada persona del equipo es distinta y que no tendré la misma conversación con un diseñador que con un desarrollador, y lo mismo ocurre con el responsable de producto. Así que mantengo la mente abierta e intento dar todo el espacio y empatía posible al equipo.

Michael Luchen

¿Cómo encuentras el equilibrio entre crear ese espacio y empatía, sabiendo que cada quien es diferente y aporta sus propias habilidades y disciplinas a un equipo de producto?

Erin Hess:

En mi caso, esa disciplina ha sido la paciencia y la práctica, aprender y darme a mí misma y a mi equipo retrospectivas de cómo nos fue no solo en el trabajo, sino en cuanto al cuidado entre las personas durante el sprint. ¿Qué cosas pudieron haber sido difíciles? No solo el trabajo en sí, sino como seres humanos y darles ese espacio para conversar.

Michael Luchen

Eso es genial. Quitándonos el zoom un poco, ¿cuáles son algunas de las actividades típicas que realiza una ingeniera de pruebas en un equipo de producto? Ciertamente no es — y sé que esto es un chiste — pero no es solo decir que se puede lanzar, ¿verdad?

Erin Hess

Oh, no. No es que me siente aquí con un sello que dice aprobar o fallar. Hay muchas complejidades y más construcción de relaciones de lo que pensarías, incluso siendo un cargo técnico. Mucho trabajo y colaboración con distintas partes del equipo, lo que implica hacer pareja con desarrolladores para mejorar en solicitudes de extracción y revisarlas.

Colaborar con el gestor de producto para definir el nivel de detalle adecuado en los criterios de aceptación y establecer expectativas respecto a qué se incluirá en ellos.

Todas las historias de usuario y características requieren ser revisadas no solo por diseños, desarrolladores y demás, sino también por quienes toman decisiones. Como ingeniera de pruebas, eres parte de todo eso. Tienes que mantenerte al día y comunicarte con todos porque si no lo haces puedes perderte algo y aumentas el riesgo de que el producto no cumpla los requisitos.

Michael Luchen

Interesante. Justo conecta con lo que decías de encontrar tu nicho en la documentación técnica, porque ayuda a reunir todo ese contexto, ¿verdad?

Erin Hess

También la uso como mi segundo cerebro. No espero recordarlo todo, pero sé que mi documentación es excelente, así que puedo consultarla cuando la necesite en un proyecto, o para que otros también la usen.

Michael Luchen

Por eso de segundo cerebro, creo que algo que he visto yo también es que tienes toda esa documentación accesible públicamente para el equipo de producto, ¿cierto?

Erin Hess

Sí.

Michael Luchen

Eso es... perdón, sigue.

Erin Hess

Iba a decir que todo está ahí fuera. No está oculto ni detrás de ningún muro de pago raro. Está ahí para que el equipo lo consuma. Y cuando hago algo, sin duda lo comparto.

Michael Luchen

Eso es muy guay. La documentación transparente es algo que creo que todo equipo de producto debería promover, no solo desde la ingeniería de pruebas, sino desde todos los roles de un equipo, porque da contexto; y ese contexto tan bien comunicado es lo que ayuda a que tu rol prospere.

Para quienes escuchan y son nuevos en el rol de ingeniería de pruebas, quizás no han tenido el privilegio de colaborar con alguien en ese puesto, ¿cuál es el mejor momento dentro de un equipo de producto para que el ingeniero de pruebas empiece a colaborar? ¿Es después de que la labor de producto comienza? ¿Al final? ¿En otro momento?

Erin Hess

Diría que he aprendido con el tiempo que cuanto antes puedas incorporar a la ingeniera de pruebas, mejor. Hay empresas que consideran que solo están para cubrir tareas puntuales y escribir pruebas y ya, sin mucha implicación. Pero si quieres buenos ingenieros de pruebas, que aporten más que solo habilidades técnicas, tráelos al pre-kickoff, esa semana de contexto, para que vean de qué se trata el proyecto y empiecen a imaginar mucho.

Desde el principio, incluso pueden contribuir a influenciar diseños para facilitar las pruebas, influir en el desarrollo y plantear temas de accesibilidad desde antes y no como un añadido posterior.

Michael Luchen

Eso es genial. Estoy completamente de acuerdo. Para mí siempre es un riesgo enorme si veo que un equipo arranca sin un ingeniero de pruebas, porque ese contexto que reúnes desde todos los ángulos es clave para garantizar que tengamos un producto probado que cumpla las necesidades del usuario. Es mucho más que, como dijiste, ese sello de goma que a veces se pasa por ahí.

Como ingeniera de pruebas, ¿qué crees que se debe tener en cuenta durante un sprint?

Erin Hess

Buena pregunta. Diría un par de cosas. Primero, no sabes lo que no sabes, así que no temas contactar a tu equipo cuando tengas dudas o inquietudes, aunque parezcan menores; a veces un pequeño problema puede convertirse en una mejora significativa. También, hacerse oír ayuda a reducir riesgos y costos de solucionar problemas si se detectan antes de lanzar algo.

Y luego, no hay "yo" en desarrollo de producto, como no lo hay en "equipo". No estás haciendo esto solo. No vas a ayudar al equipo si no le dices que tienes dificultades. Así que lo peor sería esperar hasta el final del sprint para avisar que no puedes cumplir con algo. Mejor habla a tiempo.

Michael Luchen

Sí. Es indispensable porque desde el lado de la gestión de productos eso ayuda a detectar riesgos importantes en el sprint.

Al comenzar un sprint todo el equipo de producto está ante una cantidad limitada de supuestos. Pero como señalas, para una ingeniera de pruebas puede haber algo detectado al inicio que cambie el rumbo del sprint con muy buenas intenciones.

Erin Hess

Sí.

Michael Luchen

Entrando en colaboración interna, ¿cuáles son tus consejos para que ingenieros de pruebas, diseñadores y desarrolladores colaboren exitosamente?

Erin Hess

Para esto diría que es muy beneficioso que diseño y desarrollo trabajen junto a los ingenieros de pruebas durante el desarrollo de las historias de usuario, siempre que sea posible.

He aprendido que existen oportunidades de colaborar con diseño y desarrollo en las primeras fases del proyecto, y eso me da más datos para preparar escenarios, archivos de prueba, guiones automáticos, etc. Ahora mismo, estoy mejorando nuestros criterios de aceptación y requisitos añadiendo Gherkin, así cuando llegue la automatización ya se habrá avanzado mucho trabajo.

Michael Luchen

Genial. Me imagino que mencionaste conceptos como escenarios de prueba, por ejemplo. ¿En qué consiste eso? ¿Es revisar los criterios de aceptación que como gestor de producto yo escribo o hay algo más complejo?

Erin Hess

Es un poco ambos. Es tomar los criterios de aceptación que el equipo y el gestor de producto mejoraron, y con esos escenarios de prueba definir: como este tipo de usuario, en este tipo de dispositivo, ¿qué hago, cuál es el resultado esperado, cuáles son los riesgos, o cosas que puedo intentar hacer mal? Es idear los diferentes flujos de extremo a extremo de lo que un usuario podría hacer en esa prueba.

Michael Luchen

Al desplegar un producto, hay muchísimos lugares y contextos en los que se puede usar, navegadores, resoluciones, dispositivos... ¿Cómo decides, entre tantas posibilidades, en cuáles centrarte?

Erin Hess

He aprendido que el exceso también es posible en pruebas. Puedes sobreprobar con accesibilidad, repitiendo en páginas donde no hace falta.

Se puede uno volver loco con las pruebas y para acotarlo se necesita tiempo, práctica y reflexión: este es el tipo de proyecto que tienes, será una app web, nativa, solo funcionará en iPhone...

Piensas en todo lo que vas a probar y comienzas a descartar lo que sabes que no necesitas y eliminas lo que no te hace falta. Después creas matrices de prueba: necesito este dispositivo, este navegador, este tipo de usuario...

Michael Luchen

¿Al establecer escenarios y focalizar, revisas estadísticas de uso de navegador, dispositivo, y determinas qué es más relevante para el producto?

Erin Hess

Hay muchos recursos que usamos los ingenieros de pruebas para saber qué tiene más sentido probar. ¿Cuál es el uso actual de navegadores, dispositivos, versiones...? ¿Cuánta gente los usa para aplicaciones o servicios? Con eso decides: vamos a mirar Safari, Chrome, iOS y Android. Luego listamos pruebas de menor prioridad, por ejemplo Edge o Netscape, que sería bueno comprobar, pero no es tan importante.

Michael Luchen

Muy interesante. ¿Hay encuestas o pruebas de usuario que ayuden a decidir qué probar?

Erin Hess

¿Te refieres a formularios, encuestas desde algún servicio web que uses?

Michael Luchen

Como encuestas, sí.

Erin Hess

Personalmente no he hecho mucho con encuestas de usuarios, pero me gusta completarlas y dar feedback. Sería interesante obtener ese feedback real y tan profundo de los usuarios. En general, tomo en cuenta cuál es la experiencia promedio esperada y parto de ahí.

Michael Luchen

Muy bien, antes de pasar a otra cosa, tengo que preguntar sobre algo que mencionaste antes: scripts de automatización. ¿Cuál es el valor de la automatización en un producto, y cuándo se debería introducir?

Erin Hess

Muy buena pregunta. Es uno de esos casos de "depende". Si el proyecto es de largo plazo, continuo, con un equipo robusto y sin fin a la vista, es bueno para automatización. Puedes empezar con pruebas manuales y priorizarlas según riesgo y función.

Luego evaluas qué marco de automatización usar, o si prefieres una solución no-code, hay muchas opciones. De ahí seleccionas cuál tiene más sentido automatizar primero en un proyecto desde cero.

Pensar en automatización no sobra, hay partes en pre-desarrollo y diseño en las que puedes empezar a trabajar con los equipos, como creando etiquetas de accesibilidad en componentes.

Eso estamos haciendo en Gherkin, escribiendo código y scripts antes de que exista el producto. Puede ahorrar tiempo y ayudar a planificar mejor si lo haces en paralelo con diseño, desarrollo y pruebas.

Aporta otra capa de complejidad al rol de ingeniería de pruebas, porque además de redactar y revisar criterios de aceptación y casos, eres casi un desarrollador cuando escribes y revisas los criterios para tus scripts automáticos.

Así que comenzar temprano es bueno, pero realmente es cuando se nota la necesidad: normalmente, para acelerar y estabilizar el proceso de pruebas.

Michael Luchen

Interesante. Cambiando de tema al trabajar con gestores de producto, ¿cómo colaboras con ellos?

Erin Hess

Oh, esto es divertido. Como mencioné antes, me gusta construir relaciones. No se trata de jerarquías, quiero que todos en el equipo colaboren y trabajo para facilitarlo. Me gusta trabajar con los PM tanto como con desarrolladores y diseñadores.

Muchas veces surge al colaborar en criterios de aceptación, investigación, reunir información sobre algo que les interesa, probar un enfoque de test, o lo que sea que necesite el PM y pueda aportar, ahí estoy.

Michael Luchen

Como decía antes, creo que la relación entre ingeniero de pruebas y gestor de producto es de las más decisivas, especialmente en torno a criterios de aceptación y cómo se van a validar antes de lanzar.

Para mí, hay un gran equilibrio cuando colaboran desde el inicio con los criterios de aceptación: los PM aportan el enfoque en los resultados deseados para el usuario y los ingenieros de pruebas el detalle necesario, asegurando que se cubran lagunas de la manera adecuada sin frenar la creatividad de los demás en el equipo.

¿Dirías que ese equilibrio existe?

Erin Hess

Sí, totalmente de acuerdo. He estado en equipos donde eso no pasaba y ahora aprecio mucho que me incorporen desde el principio.

Michael Luchen

Es muy claro: cuando has estado en un equipo sin ingeniero de pruebas, la diferencia es de la noche al día, se nota como todo puede irse al traste si falta ese rol.

Ahora, sé que eres una gran defensora de la accesibilidad. ¿Puedes contarnos en qué consiste?

Erin Hess

Totalmente. El término accesibilidad está muy de moda. Se la conoce también como 'A11Y', ya que hay 11 letras entre la A y la Y. Significa ser la voz de todos los usuarios finales y abogar por que los productos y servicios sean accesibles para todos. Mucha inclusión, muchas charlas y buscar cómo usar mi voz para ayudar a otros.

Michael Luchen

Muy bien. Algo que lamentablemente he visto es que a veces los responsables no priorizan la accesibilidad. ¿Cómo lo enfrentas?

Erin Hess

He probado varios enfoques y el más exitoso ha sido mostrarles cifras del coste que implica para el negocio no tener un sitio accesible: el riesgo de demandas es alto, son difíciles de superar y dejan mal sabor de boca, aunque no haya mala intención esa será la percepción.

Michael Luchen

¿Puedes contarnos un poco más sobre la empatía como base de las pruebas?

Erin Hess

Seguramente conoces el dicho, "ponerse en los zapatos del otro", eso es empatía: la capacidad de entender o sentir lo que otra persona experimenta desde su marco de referencia. Es un concepto que abarca muchas emociones.

De hecho, di una charla específicamente sobre empatía y pruebas en el evento TestBash de Ministry of Testing este año, junto a mi amiga Jenny Bramble. Allí expusimos cómo nuestras historias nos ponen en una posición única para hablar sobre empatía y necesidades del cliente.

Michael Luchen

Genial. En pocas palabras, ¿qué hace que la empatía sea la base de las pruebas? ¿Cuáles son las tácticas?

Erin Hess

En resumen, hay una intersección entre pruebas y empatía: no puedes saber las expectativas de alguien si no entiendes su experiencia. Ponerte en el lugar de otro es parte esencial de probar: probar temas de alto contraste, fuentes disléxicas, etc., tiene un motivo; esa intersección cae de lleno en las pruebas de accesibilidad.

Michael Luchen

Muy interesante. En esta charla de 25 minutos veo varios temas conectados: la defensa de la accesibilidad, cómo la empatía lo atraviesa todo en tu trabajo y lo importante de la colaboración con el equipo de producto entero.

Antes de terminar, me gustaría hacerte unas preguntas personales rápidas, ¿de acuerdo?

Erin Hess

Adelante.

Michael Luchen

¿Cuál de tus hábitos personales más ha contribuido a tu éxito?

Erin Hess

Definitivamente mi capacidad para crear, estructurar y organizar grandes cantidades de información, desarrollada con el tiempo. Es uno de mis superpoderes y surge de mi obsesión por el orden y mi pasión por escribir documentación útil y significativa.

Michael Luchen

¿Cuál es tu herramienta favorita que usas regularmente?

Erin Hess

Sin duda, Chrome DevTools, por muchas razones, pero destaco el Modo Dispositivo para simular móviles, probar la respuesta y diferentes visualizaciones. El panel de red es mi mejor amigo a la hora de buscar defectos; lo uso siempre. Y también Lighthouse y Axe para pruebas de accesibilidad.

Michael Luchen

Por último, para quienes empiezan en este mundo del producto, ¿qué consejo les darías?

Erin Hess

Que estén abiertos a aprender de todo y de todos, ya sea un desarrollador, diseñador o gestor de producto. Si te piden ayuda o tiempo, aprovecha la oportunidad como experiencia de aprendizaje y saca provecho de ello.

Michael Luchen

Muy bien dicho. Sin duda, he aprendido mucho hoy. Gracias, Erin, por acompañarnos.

Erin Hess

De nada. Gracias a ti por invitarme y espero hablar más sobre pruebas de accesibilidad e ingeniería de pruebas en general.

Michael Luchen

Estoy emocionado por ello. Y quien quiera saber más de Erin, puede encontrar su trabajo en crema.us, también en LinkedIn y en Twitter como @QueenTester.

Si te gustó el programa de hoy, consulta nuestra publicación relacionada, QA Lead, donde exploramos lo último en automatización y pruebas en theqalead.com.

De nuevo, muchas gracias Erin por estar hoy con nosotros. Ha sido un episodio fantástico. Gracias a todos por escuchar. Por favor, deja tu reseña del pódcast. Me encantaría saber tu opinión y, recuerda, síguenos y únete a nuestra comunidad en theproductmanager.com. ¡Gracias!