Un SDET para gobernarlos a todos
•
0 likes•47 views
Twitter: @amgarciao Linkedin: https://www.linkedin.com/in/amgarciao/ Un SDET para encontrarlos. Un SDET para atraerlos a todos y atarlos en las tinieblas, en las Tierra de la Calidad donde se extienden los bugs. He pasado por roles de Desarrollador, Consultor, Automation y Tester. He estado dentro de un equipo de QA, de creación de herramientas, de desarrollo y ahora soy la única (¿de verdad?) influyendo mejoras de calidad de software, trabajando con 5 equipos. En esta charla hablaré sobre como entiendo la calidad del software, lecciones aprendidas y como veo mi rol en los próximos años. Charla de 15 min en QA T4LKS - ZERO Meetup Malaga, 16 Enero 2020. https://www.meetup.com/es-ES/QA-Malaga/events/267414272/
Recommended
Recommended
More Related Content
Featured
Featured (20)
Un SDET para gobernarlos a todos
- 1. un SDET para gobernarlos a todos Ana Maria del Carmen Garcia Oterino
- 2. Developer Testing+ Software Developer Engineer in Test (SDET)
- 3. Desarrollador Testing+ Software Developer Engineer in Test (SDET)
- 8. multiplier a
- 9. vs Largo plazo Corto plazo Tipos de cambios
- 12. Medir e iterar
- 13. Usa la fuerza! (be a force multiplier) 5- Feedback 1 - Cambios a largo plazo 2 - Mapa de influencia 3 - Establece mecanismos 4- Idear, medir e iterar
- 14. amgarciao y que la fuerza te acompañe Gracias!
Editor's Notes
- DIAPOSITIVA 1: Buenas! Me llamo Ana y soy la única SDET o persona relacionada con QA en mi organización. Tenemos 5 equipos de desarrollo, con su managers, managers de proyecto y varios equipos de negocio, y yo trabajo con todos ellos. Dejando a un lado el debate sobre si el ratio 1 vs tanta gente es el adecuado, hoy quería contaros como he afrontado mi rol en este contexto y daros algunos consejos que creo que son útiles para cualquier persona que quiera llevar a cabo cambios de cultura en su organización, sin importar su rol (desarrollador, QA, manager de proyecto, .etc.).
- DIAPOSITIVA 2 Lo primero es lo primero. ¿Qué significa este palabro de SDET?
- DIAPOSITIVA 3 Básicamente, un SDET es un desarrollador de software, especializado en testing. En varias ocasiones he acabado desarrollando en un equipo, como cualquier otro desarrollador, pero también trabajando desde fuera con varios a la vez. Voy rotando, os contaré en base a qué más adelante. El área que más me gusta es la calidad de software y el testing. Muchas veces acabo trabajando en llevar a cabo cambios en este área: desarrollar un framework de pruebas automáticas, ver como arquitecturar una solución software para que pueda escalar a la carga de usuarios que tenemos que dar soporte, cómo hacer pruebas de rendimiento, cómo programar una serie de clases para que sean testeables y fáciles de cambiar en el futuro, cómo hacer mocks de servicios, .etc. Cómo veis esto tiene una parte muy técnica, pero hoy os vengo a hablar de la parte cultural, más emocional, de este rol, más relacionada con el tema de este evento. Porque claro, cuando estáis en este contexto de 1 vs varios equipos, y os dicen que tenéis que mejorar la calidad del software de la organización…¿cómo lo hacéis? ¿de verdad estamos solos en esto?
- DIAPOSITIVA 4 Una de las primeras cosas que podemos hacer es llorar en un rincón y pensar en qué lío nos hemos metido.
- DIAPOSITIVA 5 Pero muchas veces lo primero que tendemos a hacer es querer controlarlo todo. Hay tantas cosas pasando a la vez (nuevos proyectos, operaciones .etc.), que podemos querer estar en el medio de todo, y que todo pase por nosotros para verificar si se están cumpliendo ciertos estándares de calidad. Si el tener un equipo de QA al final, por el que todo pase, que sea el guardián de calidad no es lo adecuado en un equipo ágil, porque la cultura de calidad ya no pertenece al equipo de desarrollo, y acaba siendo un cuello de botella, imaginad el cuello de botella en el que te conviertes cuando eres la única persona. Este enfoque acaba no siendo útil ni para ti ni para los equipos.
- DIAPOSITIVA 6 Otra opción es hacer justo lo contrario: decirle a la gente que si necesita algo, os pregunte. Y puede acabar todo ardiendo y que nadie te pregunte.
- DIAPOSITIVA 7 A mí me gusta adoptar una posición intermedia, que se basa en entender que las organizaciones, los equipos, son sistemas, interconectados entre sí. Las personas no trabajan aisladas, tienen relaciones, se influyen los unos a los otros (de forma personal, laboral) y eso es una parte muy importante de nuestro día a día.
- DIAPOSITIVA 8 Me gusta entender esa red, para ver como el esfuerzo que hago se puede multiplicar y tener un impacto lo más grande posible, y que dure y se propague aunque yo no esté ahí, en vez de ser la persona que gobierna a todo el mundo, por la que pase todo. Pero bueno, y concretamente, ¿cómo aplicamos esto?
- DIAPOSITIVA 9 Lo primero, ¿para qué tipo de cambios utilizo este enfoque? Para cambios a largo plazo, que quiero que duren y tengan un impacto en el tiempo, en la cultura, en el día a día de la organización. Obviamente yo también tengo que hacer cosas a corto plazo, que tienen una fecha límite, y hay que hacerlas sí o sí, así que intento invertir 50% del tiempo en cada tipo de cambio (largo o corto plazo), o cuando hago cambios a corto plazo, intento ver si hay alguna parte que está relacionada con un cambio a largo plazo. Por ejemplo: A lo mejor os toca resolver un bug (corto plazo), pero ¿y si descubrís que solo vosotros habéis sido capaces de encontrar la raíz del problema porque solo vosotros sabíais utilizar las herramientas adecuadas? ¿o sólo vosotros conocéis esa parte del sistema? ¿o si descubrís que la persona que abrió el bug no indicó adecuadamente los pasos para reproducir el bug, y eso hace que se tarde más en identificar el problema y solucionarlo? En estos casos, además de solucionar el bug, invertir en enseñar a otros, implementar algún proceso para mejorar el reporte de bugs, puede marcar una gran diferencia, y hacer que esos cambios duren ahí sin que estéis vosotros.
- DIAPOSITIVA 10 Bien, ya tenemos el tipo de cambio que queremos hacer (largo plazo, puede que tengáis muchos cambios que queráis hacer, pero tenéis que priorizarlos, 1 a 1, eso puede ser tema de otra charla). Ahora qué, ¿dónde tenemos que actuar? A mi me gusta crear un mapa de influencia (en mi cabeza o en papel), en el que reflejo las distintas personas de la organización o del equipo, y cómo se influyen y relacionan los unos con los otros. Flechas gruesas indican que la persona tiene más efecto en la otra (ej.: tu jefe sobre ti o un team lead sobre el resto del equipo). Flechas bidireccionales indican que ambas personas se influyen en la relación, sin flechas (ej.: yo y el CEO) indican que por mucho que hablemos no llego a influenciarle. Pero fijaos, en ese contexto, Joe tiene muchísima influencia sobre el CEO. A lo mejor si a Joe se convence de la idea, puede ser un aliado que la transmita al CEO. Con esto nos podemos hacer una idea sobre en qué puntos de la organización deberíamos actuar para llevar a cabo el cambio y que tenga más impacto.
- DIAPOSITIVA 11 Ahora, ¿qué tipo de acciones llevamos a cabo para implementar el cambio en la organización? Yo distingo tres tipos: herramientas, procesos y personas. Os voy a dar algunos ejemplos: Herramientas: Nuestros equipos trabajan mucho con AWS. Llevamos 5 años desarrollando todos nuestros sistemas en una única cuenta de AWS. Creíamos que era una buena práctica, más sencillo, pero ahora tenemos problemas de seguridad, colisiones, nos cuesta calcular los costes de cada equipo, porque vienen dados por cuenta, .etc. La buena práctica de hecho es tener una cuenta de AWS por sistema y por entorno (beta, gamma, prod). Podemos decidir que nuestro cambio a largo plazo es tener cada sistema en una cuenta de AWS independiente, cosa que afecta a sistemas existentes y a sistemas nuevos (no crearlos como antes). Imaginaos, que a pesar de estar todos de acuerdo, nos damos cuenta de que los equipos siguen creando sus sistemas en la cuenta antigua de AWS, y básicamente es porque les cuesta más esfuerzo la forma nueva: ¿cómo coordinan las pipelines? ¿cómo conectan sus servicios que están en otras cuentas a los servicios de la cuenta principal? Tienen que invertir tiempo en eso, más replicar infraestructura en cada cuenta, mantenerlas sincronizadas, .etc. Y eso se repite en cada uno de los equipos de la organización. ¿Y si en vez de dejarlos sin nada de soporte creamos una herramienta en la que los desarrolladores pueden indicar el tipo de arquitectura que quieren desarrollar (ej. Lambda + VPC, contenedores, ec2), el lenguage (java, python…) y los IDs de cuentas de AWS donde deben estar los sistemas, y es la herramienta la que se encarga de crear un Hello World en la arquitectura deseada, siguiendo las buenas prácticas, que ellos pueden extender? La automatización facilita el mantenimiento y adoptar buenas prácticas. Procesos: Imaginaos que nos damos cuenta de que no estamos teniendo en cuenta el coste a la hora de seleccionar una tecnología u otra, y estamos despilfarrando dinero. Por otro lado, nos damos cuenta que los equipos antes de empezar a desarrollar tienen una reunión, un debate en el que opinan sobre diversos diseños. ¿Por qué no creamos una plantilla para esa reunión, en la que indiquemos que en cada solución se tiene que ver cuanto costaría adoptarla? Así tenemos en cuenta los costes en el diseño. O en el caso anterior, imaginemos que nuestra empresa está muy orientada a objetivos. ¿Por qué no definimos un objetivo anual para migrar 2 sistemas a cuentas individuales? ¿O para reducir costes? Así esos cambios se integran en el día a día de los equipos. Personas: No estáis solos. Si os fijáis en el mapa de influencia, hay gente que tiene mucha y trabaja con muchos equipos. A lo mejor, si invertís tiempo en enseñar como hacer pruebas a un manager de proyecto, trabajar con él mano a mano en un proyecto para que entienda el beneficio, esa persona aplicará lo aprendido en el resto de sus proyectos, influenciando a otros equipos. O similar, a lo mejor un líder de equipo tiene mucha influencia sobre ciertas personas y puede ayudar a propagar esos cambios. O simplemente hay gente apasionada por la calidad, que propone y quiere adoptar cambios, y ayudará a mostrárselos a los demás. Mirad el mapa de influencia y buscad vuestros aliados.
- DIAPOSITIVA 12 Ya tenemos el tipo de cambio, qué acciones vamos a realizar y en qué puntos de la organización. ¿Ahora qué?¿Dejamos que todo fluya y ya está? Eso es un pensamiento demasiado feliz. A la vez que definís el cambio y las acciones a llevar a cabo, tenéis que pensar qué significa que el cambio se haya propagado con éxito, cómo lo vais a medir y en cuánto tiempo. Si en X tiempo los resultados no se corresponden con lo que esperabais, tenéis que identificar por qué, y volver a iterar. Tened en cuenta que el mapa de influencia que creasteis es vuestra opinión, es un plan, puede ser correcto o no, puede cambiar (si alguien se va, alguien nuevo entra, .etc.) o incluso vosotros podéis ganar mas confianza en un equipo con vuestras acciones y adquirir más poder de influencia. Por ejemplo: Implementasteis un framework de automatización de pruebas porque las pruebas automatizadas que había antes no eran estables y este framework puede ayudar a solucionar este problema. Dais formación al equipo y parece que todos están de acuerdo en usarlo y saben como hacerlo, por lo que decidís dejar de trabajar con ellos, y volver en un mes. En ese mes, tienen 2 proyectos nuevos, y vuestra definición de éxito es que hayan implementado X pruebas para esos proyectos usando el framework, o migrado X pruebas antiguas, o que no haya ningún commit en el repositorio que indique que se han deshabilitado test automáticos. Al mes puede ir todo bien, o os podéis dar cuenta de que no ha pasado lo que esperabais. Volvéis al equipo y veis que es porque el framework no era capaz de soportar un caso de uso para el nuevo proyecto, un desarrollador se está oponiendo a adoptar el framework o las personas que esperabais que influenciaran el cambio no lo están haciendo. Entonces tenéis que cambiar el plan e iterar.
- DIAPOSITIVA 13 Para concluir, os animo a que entendáis la fuerza de vuestra organización y os convirtáis en multiplicadores. Para ello: identificad un cambio a largo plazo, identificad acciones y cread vuestro mapa de influencia para saber dónde llevar a cabo esas acciones. Estableced cómo mediréis el éxito e iterad si no conseguís los resultados adecuados.
- DIAPOSITIVA 14 Gracias! Algunos recursos para profundizar en este tema: How to Measure Anything: Finding the Value of Intangibles in Business -> https://amzn.to/2RvnXjF Systemic Coaching : A Target-Oriented Approach to Consulting -> https://amzn.to/30Cg6VG Alas para un cambio: Desarrollo sistémico de las organizaciones -> https://amzn.to/2Rwgn8j Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition -> https://amzn.to/38n0vvK Agile Testing: A Practical Guide for Testers and Agile Teams -> https://amzn.to/3alLXhE More Agile Testing: Learning Journeys for the Whole Team -> https://amzn.to/38liPoP