Michael Luchen conversa con Erin Hess, ingeniera senior de pruebas en Crema. Comenzó su carrera como diseñadora gráfica antes de convertirse en programadora autodidacta, quien desarrolló una pasión por las pruebas de software. Escucha para aprender más sobre las pruebas de producto.
Aspectos destacados de la entrevista:
- Erin tiene un conjunto único de talentos creativos y técnicos adquiridos durante más de 12 años de experiencia en diversos roles dentro del desarrollo y la ingeniería de software. Comenzó su carrera como representante de soporte al cliente antes de convertirse en programadora autodidacta que desarrolló su amor por las pruebas de software. Defensora de los usuarios por naturaleza, algunas de las principales fortalezas de Erin incluyen la empatía, la visualización y la anticipación de comportamientos y comunicación. [0:53]
- A Erin le gusta crear mapas de procesos e imaginar dónde pueden estar los puntos de dolor. Al ponerse en el lugar de otros, observar los problemas desde múltiples perspectivas y visualizar las consecuencias y beneficios a largo plazo de las acciones actuales, Erin ha logrado marcar la diferencia en cualquier equipo y producto al que se suma. [1:30]
- Erin también ayuda a las organizaciones a adoptar e implementar prácticas de diseño inclusivo creando y difundiendo la conciencia sobre las barreras de usabilidad universal. Es defensora de la accesibilidad y contribuye continuamente con materiales de recursos para las comunidades de pruebas en línea en constante crecimiento. [1:47]
- Hay muchas actividades que puedes realizar como tester. Una de las cosas favoritas de Erin, en general, es construir relaciones y conocer a los equipos con los que trabaja. [2:48]
La disciplina ha consistido simplemente en paciencia y práctica, aprendizaje, darme a mí misma y a mi equipo retros de lo que hacemos para cuidar unos de otros y seguir avanzando durante el sprint.
Erin Hess
- Algunas de las actividades típicas que realiza una ingeniera de pruebas en un equipo de producto son principalmente la construcción de relaciones, el trabajo y la colaboración con distintas áreas del equipo. Como ingeniera de pruebas, eres parte de todo eso. Tienes que estar al día y comunicarte con todos los miembros del equipo, porque si no lo haces, te vas a perder algo y te vas a quedar sin información. [5:26]
- Erin aprendió con el tiempo que cuanto antes puedas involucrar a la ingeniera de pruebas, mejor. Cuando quieras a esas buenas ingenieras de pruebas, las que van a aportar más allá de solo habilidades técnicas de testing, invítalas a la reunión previa al kickoff y haz que vean en lo que se están metiendo. [8:14]
- Lo primero a tener en cuenta durante un sprint es: no sabes lo que no sabes, así que no tengas miedo de contactar a tu equipo cuando tengas alguna duda o inquietud sin importar cuán grave la consideres. A veces una preocupación pequeña puede convertirse en una mejora significativa. [9:41]
No existe el «yo» en el desarrollo de productos, como tampoco existe el «yo» en un equipo. No lo haces solo. Eres parte del equipo y no vas a aportar nada al equipo si no les cuentas que estás teniendo dificultades.
Erin Hess
- Definitivamente es beneficioso que diseño y desarrollo se emparejen con las ingenieras de pruebas durante el diseño y desarrollo de las historias de usuario siempre que sea posible. Erin puede decir por experiencia que existen oportunidades para trabajar junto a diseño y desarrollo en las etapas iniciales de un proyecto, lo que le da más información para preparar escenarios de prueba, archivos de prueba o redactar scripts de automatización. [11:22]
- La palabra accesibilidad se utiliza mucho actualmente. También se conoce como ‘A11Y’, porque hay 11 letras entre la A de accesibilidad y la Y. [22:13]
Yo diría que ser defensor significa que eres la voz de todos los diferentes usuarios finales, y vas a luchar por prestaciones y desarrollos de productos y servicios para que sean accesibles a todo el mundo.
Erin Hess
- Erin realizó una presentación sobre empatía y testing. Fue en el evento TestBash Home del Ministry of Testing, donde presentó junto a su amiga Jenny Bramble. Ellas hablaron sobre cómo «La empatía es la base de las pruebas» y cómo se ve eso y de qué manera su historia las coloca en un lugar único para hablar sobre empatía y necesidades de los clientes. [24:36]
La empatía es la capacidad de comprender o sentir lo que otra persona está experimentando desde su propio marco de referencia.
Erin Hess
- Los hábitos personales de Erin que más han contribuido a su éxito son su habilidad para crear, estructurar y organizar grandes cantidades de información desarrollada a lo largo del tiempo. [26:44]
- Las herramientas favoritas que Erin utiliza regularmente son Chrome DevTools, como Device Mode, que puedes usar para simular dispositivos móviles, probar la capacidad de respuesta y diferentes tipos de ventanas de visualización. [27:16]
- El único consejo de Erin para alguien que está comenzando su camino en el producto es: mantente abierto a aprender cualquier cosa, sin importar de quién provenga. Si un desarrollador, un diseñador o el product manager quieren tu atención o tu tiempo para hacer algo, acéptalo. Úsalo como una experiencia de aprendizaje y obtén el máximo provecho. [27:59]
Biografía de la invitada:
Erin comenzó su carrera como diseñadora gráfica antes de convertirse en programadora autodidacta, desarrollando una pasión por las pruebas de software. Es una defensora del usuario de corazón: la empatía, la visualización, la anticipación del comportamiento y la comunicación son algunas de sus principales fortalezas.

Me gusta formar relaciones con mi equipo, así que no estará basado en jerarquía. Es porque quiero que todos en el equipo colaboren y trabajen juntos.
ERIN HESS
Recursos de este episodio:
- Suscríbete al newsletter de The CPO Club
- Échale un vistazo a Ministry of Testing
- Échale un vistazo a La empatía es la base de las pruebas con Jenny Bramble y Erin Hess
- Échale un vistazo a La empatía es la base de las pruebas
- Échale un vistazo a Herramientas para desarrolladores de Chrome
- Échale un vistazo a The QA Lead
- Échale un vistazo a Crema
- Conecta con Erin en LinkedIn
- Sigue a Erin en Twitter
Artículos y podcasts relacionados:
- Cómo la colaboración interfuncional potencia el crecimiento del producto
- 3 tácticas simples y efectivas para gestionar a los product managers
- 10 mejores softwares para el desarrollo de nuevos productos
- Gestión de productos en el sector público (con Seán Massey de DWP Digital)
Lee la transcripción:
Estamos probando la transcripción de nuestros podcasts usando un programa de software. Por favor, disculpa cualquier error tipográfico ya que el bot no es correcto el 100% del tiempo.
Podcast relacionado: Desarrollo impulsado por las personas (con Sam Higham de Glean)
Lectura relacionada:
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!
