El peor enemigo de las metodologías ágiles es su propio nombre. “Agile” significa para muchos, flexibilidad, velocidad, facilidad, etc;
pero todo ello entendido o llevado a la práctica de forma errónea. Desde los principios ágiles hasta las buenas prácticas, suelen ser utilizados de una forma que tienden a camuflar los mismos fallos y las mismas desventajas características de otras metodologías tradicionales para acabar con la clásica frustración: “es que la Agilidad no funciona”.
Presentaremos los dos pilares en los cuales se sustenta el testing ágil: “Early and frequent feedback” y “The whole-team approach”, que deben ser la premisa en cualquier estrategia de testing y de desarrollo de Software en general.
¿Cuál es el rol del tester ágil? Aunque este rol se encuentra solapado con otros roles dentro del equipo, éste adquiere mas responsabilidad a la hora de entender y aplicar correctamente los principios ágiles a las tareas de testing: derribar falsos mitos, evangelizar y asegurarse de mejorar, no sólo la calidad del Software, si no de los procesos, de los equipos y de las personas.
Testing temprano, 3 amigos, automatización, pirámide del testing, definición de hecho, integración continúa, retrospectiva, entre otros, son conceptos relacionados con los pilares del testing ágil y que hay que entender desde su verdadero significado. Veremos cómo aplicarlos en nuestras tareas diarias, cómo reforzar esas ideas dentro del equipo, y cómo hacer de la mejora continúa nuestro objetivo principal. Finalmente repasaremos herramientas/frameworks de trabajo que pueden ayudarnos en esta tarea, desde las más sencillas como un simple tablón con “Post-Its” o las “Planning Poker Cards” hasta las más especificas como Jenkins o BDD.
Diapositivas
https://wpgranada.es/wp-content/uploads/2025/02/WP-AgileTesting-pero-verdad.pdf
Transcripción
Bueno, pues buenas tardes a todos. Ya por fin estamos aquí con Frank Guerrero, que va a dar una charla distinta, va a dar una charla sobre testing a Yyle y honestamente yo me he leído tu charla, me he leído todo lo que va a presentar y yo no sé realmente tengo muchas dudas. Espero que no la resuelva todos los que estamos aquí porque sí es verdad que son muchas palabras nuevas. Y bueno, agradecer a Frank que viene de Málaga a dar la mitad y bueno, esta es la segunda mitad que tenemos en el año, decir que ya hemos aplicado para la work on de Granada 2025, que previsiblemente será para final de año, para octubre y bueno, también agradecer al sitio en el que nos encontramos que es la cámara de comercio de Granada que es nuestro sponsor y bueno, pues no te quiero robar más tiempo porque hemos empezado un poquito más tarde y seguramente tengamos mil dudas después. Así que bueno, aquí es Frank y vamos a darle. Gracias. Pues nada, lo mismo, agradecer a la comunidad de Wallpred por haberme invitado hoy. Vamos a hablar un poquito de temas de testing, de calidad y de agile. Realmente tiene que ver con Wallpred y no, quiero decir, al final son conceptos, son formas de trabajar que se pueden aplicar de cualquier equipo, ya sean equipos que estén haciendo desarrollo normal, desarrollo de plugin de Wallpred por ejemplo, equipos únicamente de testing, se puede aplicar a muchas combinaciones. Vamos a hablar hoy de lo que es testing agile, vamos a hablar un poquito también de metodología agile, pero de verdad lo que es agile, de verdad. Fijaros que ahora lo vamos a mencionar, agile tiene ya bastantes años, pero bueno, vamos a ver por qué todavía de hoy no se entiende correctamente, ¿vale? Bueno, pues nada, me presento de nuevo, soy Frank Guerrero, me dedico a toda la parte de QA, de aseguramiento de la calidad del software, llevo ya 14 años en este campo y seguiré, porque me gusta bastante. Hay que tener mi link, aunque después dejaré mi dato de contacto por si queréis arreglarme. Estoy certificado de ISTQV, que es la certificación más reconocida de testing. Y bueno, tengo también la extensión agile, por eso hoy vamos a hablar de este tema. Y me gustaría, como ha dicho Miguel, vengo de Málacas, me gustaría primero que empezáramos aprendiendo un poquito de vocabulario malagueño, porque bueno, en el acento me lo notaré. Entonces, bueno, voy a dejaros que una pincelada de algunas palabras típicas de Málacas, está en inglés pero lo traduzco rápidamente. Saborío es una persona, bueno, un poco seria, seca, si es amanía, no sé cómo le llaman, y de nada, pero bueno. Perita, Perita es algo que está chulo, que está guay, se suele decir allí que es algo que es Perita, o alguien que es Perita. Chorraera, el típico tobogán de parque, se le llama Chorraera, y mi favorita es Guarrito, que es un taladro, se lo se le llama en Málacas, guarrito, y viene porque había unos huérritos antiguos, o sea, unos taladros antiguos, que la marca era Warrington, y se le quedó como guarrito. Entonces, si alguna vez Málacas pide un guarrito, que sepa que están pidiendo un taladro. Bueno, vamos a empezar con el, con el ayael. ¿Quién da aquí trabajar con metodología ágil? O ha trabajado alguna vez con metodología ágil. Vale, casi todo el mundo lo ha aplicado alguna vez, o lo ha utilizado. Realmente el nombre de ayael o ágil, para mí es un nombre supermal elegido, es decir, da la sensación que a yaile puede hacer lo que te dé la gana, o puede hacer cualquier cosa. Y realmente tampoco es así, vale, es decir, por supuesto es una metodología de trabajo que ofrece cierta flexibilidad, pero hay que entender las bases y los conceptos que hay detrás de esta palabra. Como he dicho antes, el manifiesto ágil se escribió en 2001, creo, o sea, el manifiesto ágil está volviendo ya hace más de 20 años y todavía hay empresas que están intentando implantar esta forma de trabajar en sus equipos. No me voy a enrollar mucho con el texto, yo voy a explicar los conceptos a mi manera, tenéis luego la presentación, por si queréis leer vosotros los textos. Aquí están los cuatro puntos principales del manifiesto ágil, donde básicamente nos dice que hay que valorar ciertas cosas por encima de otras. En este caso, las cosas de la izquierda que valoran las más que las de la derecha, por ejemplo, dentro de un equipo de trabajo hay que valorar más lo que son los individuos, las interacciones entre ellos que lo que son los procesos y las herramientas. Es decir, está muy bien mandar un e-mail o escribir un informe, pero si tengo mi compañero al lado, pues hablo con él y resolvo la duda o el problema más rápidamente. También se valora mucho más un software funcionando, más que una documentación extensiva de ese software. Es decir, prefiero entender mi programa, si está funcionando correctamente, que tener una documentación muy detallada y que luego no funcione. Por supuesto, a yail se trata de colaboración con el cliente, luego veremos un poquito del tema de feedback. Y aquí donde viene la parte más flexible, la respuesta ante el cambio, se valora bastante más que seguir un plan súper establecido. Ahora nos vamos a meter ya en materia. Durante toda la presentación de hoy, vamos a tratar diferentes conceptos, diferentes palabras, diferentes historias, pero realmente todas tienen la base en estos dos conceptos fundamentales, que para mí son los dos pilares del test y en ágil. Uno de ellos es el approach del equipo al completo y el otro es el feedback temprano y frecuente. Estas son las dos claves para realmente hacer pruebas ágiles dentro de tu equipo. Por supuesto, cuando hablamos de pruebas, hablamos de comprobar que el software funciona correctamente, no solo que desarrollarlo, también hay que probar que funciona correctamente. Las pruebas tradicionales trataban de un equipo independiente al final del ciclo de desarrollo haciendo pruebas. De hecho, muchísimas empresas, muchísimas compañías todavía siguen trabajando de esa forma. Realmente esto es poco ágil. Dentro del ágilismo lo que se nos dice es que el equipo de testing, el equipo de pruebas, tiene que trabajar conjuntamente con el resto del equipo. Desarrolladores, personas de productos, diseñadores, tienen que trabajar todos conjuntamente. Y tenemos que basarnos en el feedback frecuente y temprano. Esto es lo contrario a las metodologías tradicionales, donde el testing se hacía al final y los errores se encontraban al final y el feedback se recibía muy tarde, ya cuando ya estaba todo hecho y probablemente era demasiado tarde para arreglarlo. Dentro de estos dos pilares vamos a ver ciertos conceptos que los tenéis ahí todos listados, ahora vamos a ir uno por uno. Y sí que para ayudar un poquito, pues vais a ver los dibujitos de eso durante la presentación, cuando veáis las tres cabecitas es el equipo al completo y cuando veáis una persona corriendo para atrás, pues es el feedback temprano. Bueno, justo lo acabo de explicar. Así que bueno, ahí lo tenéis. Vamos a ver conceptos y vamos a ver también casos reales y ejemplos de malas prácticas, son reales, me han pasado ahora os lo voy a contar poco a poco. Vale, vamos a empezar con lo que es testing agile. Allá hay una metodología iterativa e incremental, ¿qué significa esto? Significa que vamos a ir desarrollando en pequeñas iteraciones y vamos a desarrollar en cada una de esas iteraciones un pequeño incremento de mi producto. Ese incremento tiene que ser algo que aporte valor, una funcionalidad nueva, algo que aporte valor a mi cliente. Entonces tengo que fragmentar mi desarrollo en pequeñas iteraciones, pero asegurándome que cada vez le aporta a mi cliente algo nuevo o algo que él va a valorar. Bueno, ya os digo, no quiero parar mucho en el texto porque hay bastante textos y tampoco me interesas, quiero mejor que vayamos a los conceptos. Entonces, dentro de las metodologías ágiles y iterativas incrementales, como he dicho antes, el testing no es una fase, es decir, las pruebas no se hacen al final, esto es algo que tiene que calar, todavía cuesta. El testing no es una fase al final, tenemos que pensar como equipo al completo que el testing va integrado con el desarrollo. Formamos parte del equipo de desarrollo y hay que intentar hacer pruebas en paralelo al desarrollo, lo máximo posible, ¿vale? Esto es importante. Bueno, vamos con el ejemplo real 1. Seguro que muchos vosotros acá en esta trampa ya somos ágiles, dice la empresa, ya somos ágiles y realmente hacen esto. No sé si sabéis lo que es. Claro, el método tradicional es waterfall, hacen como que son hallaz, pero realmente hacen mini cascadas, ¿vale? Es decir, eso no es ser ágil, cuida con la trampa, ¿vale? Muchísimas empresas caen en esa trampa, ¿no? Si os fijáis, pues bueno, tenemos la primera línea horizontal, sería la metodología tradicional, una cascada tradicional donde primero se define todo, luego se codifica y finalmente se testea. Y luego, pues la gente que empieza a hacer iteraciones hace como esas mini cascadas, hace definición, codificación y testing al final de literación, pero realmente esos son mini cascadas. Sin embargo, lo que tenemos que intentar es pasar el testing todo lo máximo a la izquierda que podamos, ¿vale? De esa forma sí estaríamos haciendo testing ágiles, sí estaríamos haciendo pruebas ágiles. Vale, segundo palabra, ¿y con los tres amigos? ¿Quién conoce esta palabra? ¿Quién la escucho alguna vez dentro de allá, ¿y lo? Vale. Los tres amigos, bueno, al final es un concepto que también se ha definido hace bastante tiempo por representantes importantes de todo el ágilismo, se conoce también como the power of three y básicamente es un concepto donde se representa a cada una de las partes importantes que hay dentro de un equipo de software, desarrollos software, ¿no? Que son pues los desarrolladores, los testeros, las personas de calidad y las personas de negocio, los analistas de negocio, los product owners, etcétera. Estos son los tres amigos y es un concepto donde nos dice precisamente que tenemos que tomar decisiones juntos y estar alineados. Esto es súper importante porque si el entendimiento de estas tres personas, logramos ese entendimiento, vamos a ahorrar un montón de errores al final, ¿vale? Muchísimas veces, estoy seguro que vosotros habéis sufrido en vuestro equipo, la mayoría de los errores que se producen son por falta de comunicación, son porque la persona del producto quería una cosa, el desarrollador entendió otra y el testero que lo está probando prueba otra cosa totalmente diferente. Entonces, nadie se comunicó con nadie. Entonces, aquí lo que se enfatiza es que estas tres personas tienen que estar alineadas. Cuando digo tres personas, no es tres personas en concreto, son representantes de esos tres grupos, ¿vale? Bueno, aquí se explica, se llama así porque involucra a las tres diferentes voces negocios, desarrollo y pruebas y dentro de los equipos ágiles estos roles no son ya independientes, sino que de alguna forma se solapan, ¿vale? Obviamente, cada uno tiene su dominio de trabajo, la persona del producto de negocio va a seguir en su dominio, pero va a participar probablemente haciendo pruebas de validación con el equipo de testing. Desarrollo va a seguir desarrollando, pero probablemente también va a participar haciendo pruebas unitarias o haciendo testing por pares con la persona de CUA. De alguna forma, los roles en los equipos ágiles se solapan un poquito. Entonces, el CUA dentro de un equipo ágile ya no es un ser independiente o un equipo independiente o una empresa externa que hace el trabajo, sino que debe formar para el equipo. Aquí, tras de todos lo digo, muchos más estaré sesolados entre los diferentes roles y esas líneas de separación ya están más difuminadas. Luego veremos cómo es necesario porque dentro del testing ágile tenemos que recaer también mucho la parte de pruebas automáticas, la parte de automatización de pruebas con lo cual necesitamos ayuda, desarrollo, etcétera. CREACIÓN COLLABORATIVA DE HISTORIA DE USUARIO La historia de usuario fina solo los requisitos, como se le llama a los requisitos dentro del mundo ágil. Normalmente se tiende a pensar que la historia de usuario son responsabilidades en la analista de negocio o de la persona de producto, pero precisamente, según todo lo que estamos diciendo, no deberían ser ellos los únicos que escriban esos requisitos, sino que deberíamos de participar con ellos. Si nosotros, los testers y los desarrolladores participamos con producto a la hora de crear la historia de usuario, vamos a conseguir ese entendimiento común que estábamos hablando antes. Entonces, en una historia de usuario la tenemos que crear de forma colaborativa. Este es el típico dibujo de Scram, que es la metodología ágil más famosa. Tampoco vamos a entrar a explicarlo, que ya está bastante manío de muchísimas veces, pero bueno, lo tenéis ahí por si lo queréis ver. Pero sí que, como veis, dentro de Scram, la iteración que se le conoce como Spring, conlleva un trabajo previo, muy amplio, que es, bueno, coger todo ese producto, ese backlog de productos, fragmentarlo, discutirlo, definir bien esa historia de usuario y una vez ya tenemos todo eso preparado, entonces entra a formar parte de la iteración. Pero hay un trabajo previo que hay que hacer, ¿vale? Un trabajo previo de análisis y de refinamiento de todos esos requisitos. Vale, hablamos ahora de la colaboración con el cliente, que es algo que hemos mencionado como uno de los principios básicos dentro del manifiesto ágil. Es importante que el cliente nos vaya dando feedback, si os fijáis, en las metodologías tradicionales, cuando pasaban a lo mejor seis meses de desarrollo y se le entregaba al cliente, a lo mejor el cliente no era lo que quería o de repente había cambiado opinión. Entonces, ¿cómo podemos evitar ese tipo de cosas? Pues colaborando con él, es decir, en cada iteración, en cada pequeña entrega que vayamos a hacerle, que nos dé un feedback, preguntarle, oye, ¿estamos bien por aquí? ¿Quieres que cambiemos algo? ¿Te gusta mejor que vayamos por allí? Y luego es importante que vayamos construyendo cosas, como decía el principio, incrementando el valor de nuestro producto. No ir haciendo cosas como veis arriba al coche, ¿no? Primero una rueda, luego otra rueda. Eso al final el cliente no lo puede utilizar hasta el final. Estaríamos en lo mismo que en una metodología tradicional. Lo interesante es en cada iteración entregarle algo que a lo mejor no es lo que él quiere al final, pero que ya puede utilizar. Si yo en la iteración número 2 de la línea abajo le entrego un patinete, pues ya puede desplazarse, el cliente lo que quiere desplazarse. Ya llegará al coche, ¿vale? Pero ya le estoy dando algo de valor. Esto tiene que ver también con el tema de la colaboración, ¿no? El bueno, lo que os decía, discutir esos requisitos, discutir esas historias de usuarios y que cada representante de esos tres amigos haga preguntas, ¿no? Oye, y que el tester, por ejemplo, oye, ¿qué ocurre si el cliente quiere hacer esto? ¿Y qué ocurriría si el cliente clica aquí el desarrollador puede decir, oye, pues esto no se puede hacer en base de datos porque por temas de rendimiento, etcétera. Es decir, esa discusión tiene que ocurrir, ¿vale? Si no ocurre, eso se va a traducir en problemas. Vale, caso real 2, y esto supongo que también lo habéis vivido, cariño, ¿dónde están mis requisitos? Claro, seguro que lo había encontrado un misterio de usuarios, sí. La aplicación tiene que ser construida en Java. Eso son los requisitos. Pues obviamente esto no es bueno, es decir, porque al final es muy ambiguo, obviamente muy abierto y probablemente el equipo de desarrollo con toda su buena intención vaya a ser lo mejor que pueda, pero al final no va a estar alineado con lo que esperan los clientes, ¿no? Entonces es importante eso, que construyamos los requisitos entre todos y que sean unos requisitos que todo el mundo puede utilizar y todo el equipo pueda participar. Vale, bueno, si esta es la rana, buscando los requisitos, efectivamente. Tema para textinaje, el importante. Bueno, dentro del agilismo en general, lo que es la gestión visual. La verdad que ya está bastante extendido, pero bueno, antes no era tanto. Decía ahora con las herramientas digitales como Gira, Trello, Asana, etcétera, pues casi todas las herramientas tienen ya un tablero digital donde podemos ver el estado de nuestras tareas. Esto antiguamente nos hacía tanto, porque había que hacerlo a mano. Decía, voy a coger una pizarra, crear posis con las tareas, el desarrollador o la persona del equipo tenía que levantarse y moverla y ir progresando esa tarea según el estado en el que estuviera. Hoy en día ya digo se utiliza muchísimo más, pero es una herramienta muy potente, porque es algo que de un vistazo tú conoces como estas las cosas. Con lo cual estamos consiguiendo un feedback temprano. Es decir, yo veo, por ejemplo, en el panel que veis los posits, que es un panel que se ha hecho analógico, yo veo que está todo apolpado en progres. Es decir, ahí tengo un cuello de botella en el equipo importante y lo estoy viendo simplemente viendo las fotos. No hace falta ver nada más, con lo cual estoy recibiendo un feedback muy rápido de cómo va mi equipo y de cómo va mi desarrollo. Entonces, es importante que intentemos gestionar siempre nuestra tarea en un tablero o con un horre. Sí? – ¿El equipo en un tario? – ¿Pasa que no lo coge de botella? – ¿Cómo va la tarea? – Vale, a ver, aquí lo que se suele hacer normalmente es lo que se conoce como la limitación del working progress. Es decir, si veis arriba pone «WIP», que significa eso, el working progress, y lo que se suele hacer en los equipos es limitar el número de tareas que pueden estar en progreso. Precisamente para que no ocurra eso, para que no haya cuello de botella bloqueo y se golpe todo. Lo que se hace, en progreso solo puede haber cuatro tareas máximas y nadie puede ponerse a trabajar en una nueva hasta que no se solucione en esas cuatro. Entonces, si el equipo se preocupa más de bloquear cosas. Esto se puede incluso limitar en los tableros digitales, se puede poner en límites para que nadie pueda poner una tarea, puede empezar una tarea nueva hasta que no se libere en las anteriores. De todas formas, un acuerdo del equipo también. Ahora veremos lo que es la definición de hecho y todo esto. Bueno, los tableros digitales también nos dan ciertas métricas, cierto gráfico de progreso como lo van down chart, que nos va diciendo el ritmo que tenemos para completar todas nuestras tareas. Si os fijáis en esta línea azul sería un ritmo ideal y la línea roja es el ritmo real en el que se van quemando tareas, en el que se van haciendo tareas. Si os fijáis, bueno, abajo tenemos la línea en días, pues en día 6, pues ahí ya se veía que íbamos con un poquito de retraso. Entonces, bueno, se puede decidir el jefe de proyecto, el excramástero, quien esté un poco al cargo de la coordinación del equipo, ver qué está pasando, cuáles son esos bloqueos, intentar liberarlos para que el equipo pueda volver a coger el ritmo. Si tenemos 20 días, pues sabemos que tenemos que llegar. Estimaciones, este me gusta mucho. ¿Quién hace estimaciones? ¿Has hecho estimaciones alguna vez en sus equipos? Vale. Voy a pasar al ejemplo y ahora volvemos a esto. El ejemplo real, estimando con cartas. No sé si alguna vez habéis usado las planning poker, que son cartas para hacer estimaciones donde el equipo saca una numeración, que pueden ser horas, puntos, no vamos a entrar tampoco en muchos detalles. Y, bueno, pues qué pasa. Por ejemplo, el equipo se explica una tarea y el equipo estima y dice a alguien, pues yo le doy un 1, da igual, que sea horas, días, lo que queráis. Otro dice, yo le doy un 5, pues coge el jefe de proyecto y dice, bueno, pues voy a sumar todas las puntuaciones y la divido entre 3 y cogemos la media de esa estimación. ¿Quién ha hecho eso alguna vez? O que es que no ha hecho eso. Nunca había hecho la media de las estimaciones. Pero eso está mal, que es cierto, eso no es correcto, porque realmente cuando todo el mundo piensa en estimaciones, ¿crees que es eso? Que es poner un número para ver si entra, si no entra, pero realmente la potencia de las estimaciones está aquí. Fijaros, las estimaciones de las tareas normalmente se hacen antes de que las tareas empiecen, con lo cual estamos en una fase muy temprana. Y durante la estimación hay discrepancias muy fuertes, como por ejemplo la persona que dice un 1 y la persona que dice un 5. Lo interesante de la estimación no es ni el valor que salga al final, ni si la tarea cabe o no cabe en el spring. Lo importante es la discusión. Lo importante es la discusión por qué el de 1 ha dicho 1 y por qué el de 5 ha dicho 5. Puede ser que el de 1 se la ocurrió una solución más sencilla o puede ser que el de 5 está teniendo en cuenta cosas que los demás no están manteniendo en cuenta. Y entonces cuando discuten y ponen en común esa información es cuando realmente se adquiere el verdadero valor del equipo. Entonces, cuando ya se ha discutido o cada uno ha puesto su motivo, se vuelve a estimar. No tienen porque está todo el mundo con el mismo número, pero probablemente de esta reunión ya se sale todo el mundo sabiendo lo que hay que hacer. Fijaros, en este caso han estimado todos más altos, con lo cual de 5 se ha acordado de cosas que había que hacer, que los demás no habían tenido en cuenta primeramente. Y ahora ya todo el equipo lo sabe antes de empezar. Ok, bueno, de la velocidad del spring. Vale, vámonos con la definición de hecho. La definición de hecho es otro concepto bastante importante, sobre todo que afecta mucho al test y a las pruebas. ¿Por qué? Porque hay una cultura general, no sé, una forma tradicional de desarrollar que cuando el desarrollador termina de picar el código dice ya está hecho. No, no está hecho. O sea, está codificado, pero no está hecho. Es decir, hay que definir qué es hecho. Echo para empezar debería ser. Desarrollo y pruebas, seguro, porque hay que probarlo, sino no podemos decir qué está hecho. Entonces, la definición de hecho es algo que hay que hacer de forma conjunta con el equipo. No hay una definición de hecho típica o estándar. Cada equipo tiene que definir qué considera, cuál considera que va a ser su definición de hecho. Bueno, hay equipos que van a pensar que para considerar que su tarea ya está hecha, pues tiene que pasar todas las pruebas unitarias, tiene que pasar las pruebas de acestación, el código ha tenido que ser revisado, se ha tenido que explicar en un entorno. Entre todo el equipo hay que hacer una lista de cuáles son las condiciones que hay que cumplir para considerar qué algo está hecho. ¿Vale? Esa lista, pues una lista escrita en un folio, que no importa, pero tiene que ser algo acordado con el equipo, ¿vale?, que todo el mundo se aconciente de que, cuando decimos que algo está hecho, ha cumplido esos puntos y, entonces, sí podemos completar esa tarea o decir qué está hecha. ¿Vale? ¿OK? ¿Había visto la definición de hecho alguna vez o la había escuchado? Sí, cual entera la definición de hecho cuando, en general, estamos listos para entregar algo. Está como definido por la implementación, pero si no están los tipos, se los toman y puede ser como no instalar en cumplir los conceptos de test y para tratar de hacer traducciones también. También. Si están, por ejemplo, si hemos preparado manuales para los usuarios, etcétera. No sé si todo es en general, que estamos listos, no solo si el código está hecho. Pero si estamos cumplidos con lo que estamos listos para ya los usuarios. Exacto, en cada equipo, en cada negocio, tendrá sus condiciones, efectivamente. La definición de hecho, efectivamente, no solo se aplica una tarea en concreto, sino que se puede aplicar definición de hecho para salir de producción, definición de hecho de una historia de usuarios, definición de hecho de un spring. Cada fase tiene su propia definición de hecho para considerar que ya está terminado de verdad. Ok, los cuadrantes del testing ágil. Dentro probablemente, aunque no se haya experto en pruebas o no haya trabajado en ese campo, pero seguro que había escuchado pruebas unitarias, pruebas de API, pruebas de regresión, los típicos conceptos de testing, sin embargo, en la metodología ágile, estos tipos de pruebas se clasifican en cuatro cuadrantes, vale. Eso es simplemente para que lo tengáis y lo consideréis. En el cuadrante 1 entrarían lo que son todas las pruebas unitarias, que son a nivel de código, pruebas para las clases, los métodos, las funciones. En el cuadrante 2 encajarían lo que son todas las pruebas funcionales, la comprobación de los requisitos, la verificación de la historia de usuarios, ejemplos, casos de uso. En el cuadrante 3 tendríamos lo que serían más pruebas realmente de validación o de aceptación, como pueden ser las UAT o las pruebas de beta testing, por ejemplo, pruebas exploratorias. Y en el último cuadrante nos quedaríamos con todo lo que son las pruebas no funcionales, pruebas de rendimiento, pruebas de estrés, pruebas de carga, etcétera. Entonces, en la estrategia de pruebas dentro de los equipos ágiles tenemos que coger de cada cuadrante lo que necesitemos. Es decir, si por ejemplo nuestra herramienta, nuestro negocio, depende mucho de la seguridad, pues tenemos que hacer pruebas del cuadrante 4. Lo ideal, por supuesto, es una combinación de todas ellas a la profundidad que necesitemos en cada parte. Vale, BDD. ¿Conoceis BDD? ¿Alguien conoce BDD? Vale, pues bien, conceptos nuevos, guay. Primero, antes de definir qué es BDD, no sé si habéis visto alguna vez esta imagen o alguna típica como el 6 y el 9. Fijaros, los problemas de comunicación existen para existir siempre. Es decir, es algo que va a ocurrir. Si os fijáis, bueno, hay una persona que mire de aquí, va a haber un círculo, la que mire de otro lado va a haber un cuadrado y se van a pelear, se van a discutir. Dos desarrolladores que no hablan entre ellos cuando van a merghar va a haber conflicto. Lo comentaba antes y producto no habla con el equipo de desarrollo van a entender cosas diferentes. Entonces, es muy importante la comunicación. Esto no va a evitar muchísimos problemas y muchos dolores de cabezas posteriores. ¿Cuál es una forma para facilitar esa comunicación? Teniendo en cuenta que, por ejemplo, un desarrollador entiende exactamente el código, pero una persona de negocio no lo entiende. Pues, por ejemplo, escribir escenarios que se conocen con una especie de lenguaje natural. Es decir, son tres palabras claves realmente, given, when, then, que significa «dado, cuando, y, con esas tres palabras claves, yo tengo que ser capaz de describir escenarios o situaciones, o casos de uso de mi cliente, por ejemplo. Ahí tenéis un ejemplo muy sencillito que dice, «Dado que lanzo mi navegador de Chrome, cuando voy a la página de Google, verifico que la página, entonces verifico que la página muestra una caja de textos y un botón de buscar». Entonces, eso lo entiende a todo el mundo, solo es un desarrollador y lo entiende, lo de una persona de producto y lo entiende. Un cocinero y lo entiende también, es decir, es algo el lenguaje natural. Entonces, si nosotros somos capaces de nuestros requisitos o las necesidades traducirla en una especie de escenario, que además luego esto se puede automatizar, que es lo interesante, pero si somos capaces de escribirlo en una especie de escenario con un lenguaje natural que todo el mundo entiende, pues habremos conseguido un entendimiento común. Entonces, VDD realmente es una forma de entenderse. Claro, todo esto es hablando de comunicación, es decir, todo esto es porque estamos haciendo hincapié en la comunicación. Fijaros, esto es una prueba real que yo he hecho en entrevistas, me la hicieron a mí y yo la sigo haciendo también, que seguramente habréis visto en algún ejercicio parecido, que es donde dos personas se sentan de espaldas y hay una persona que se dedica a describir un dibujo, de escribir una imagen y la persona que tiene que dibujarla, pues con las indicaciones que le va dando, tiene que intentar dibujar lo mismo que hay en el otro papel. Entonces, Fijaros, un ejercicio bastante bueno porque además aquí puedes ver perfectamente cómo las personas se expresan, si da bastante detalle y si la otra persona lo recibe correctamente, si lo interpreta bien, no es fácil, no es tan fácil la comunicación. Fijaros, esto es un ejemplo real, el dibujo original es el de la izquierda y el de la derecha es el que pintó la persona, pero lo hizo bastante bien, sobre todo la parte de la pirámide, pero fijaros la parte de tu nombre, claro, le dirían, dibujo una frecha apuntando la parte superior del folio a la derecha, dibujo una frecha apuntando a la derecha y dentro pon tu nombre y puse su nombre. Entonces, no es tan fácil, es complicado, entonces es un ejercicio de comunicación interesante. Vale, testing temprano, vamos para allá. Fijaros, desde el principio lo venimos diciendo, tenemos que intentar que el testing no sea una fase y que no esté al final, sino hacerlo lo más tanto posible. Esto, que parece muy obvio, pues muchas veces nos aplica, pero fijaros en este gráfico, podéis encontrar millones de gráficos como este y estadísticas reales del coste de arreglar errores dependiendo de la fase en la que nos encontremos durante el desarrollo. Si nos encontramos una fase muy temprana, como puede ser en definición de requisitos o diseño, el coste de arreglar los fallos es muy poquito y sin embargo, si estamos en una fase de producción, el coste de arreglar un error es muy caro. Esto se ve con un ejemplo. Si yo tengo un requisito, un documento, un historiado de usuario, lo que sea y alguien lo revisa y ve un error, arreglar ese error es muy sencillo, simplemente corregir las frases. Cambio las frases, modifico mi historiado de usuario, mi documento y ya lo he arreglado, es muy sencillo. Sin embargo, si estoy ya en producción, es decir, si me producto ya está en el usuario final y el usuario final encuentra un error, imaginaros, está intentando comprar un billete de tren a las tres de la mañana y no puede comprar el billete de tren. Ahora llama a atención al cliente, los de atención al cliente tienen que llamar a los que estén de guardia que le tienen que pagar las guardias, los de guardia se tienen que despertar por esa regla del error, porque si no, no coge el tren a la ocha de la mañana, tienen que llamar luego al equipo de pruebas para que comprepe que ahora han arreglado el error, al final el cliente coge el tren pero le deja una mala reseña y la compañía se queda sin cliente. Entonces es muy caro, parece muy obvio pero todavía no se entiende bien. Hay que intentar testear al principio, es decir, hay que intentar, en vez de hacer testings al final, que también hay que hacerlo, por ejemplo, revisar requisitos y comprobar que todo está correcto, revisar diseños, sentar al desarrollador con el téster y hacer pruebas conjuntamente. Entonces, este tipo de cosas, todo lo que encontremos en esos momentos, vamos a estar en fase muy temprana, con lo cual el coste va a ser muchísimo más barato de arreglar eso de todos. Bueno, esto es justamente lo que decía, una de las técnicas que se suele hacer, que a mí más me gusta es emparejar a Cuba con desarrollo, es decir, sentarse los dos juntos en el ordenador del desarrollador, en el local y, oye, pues mira, desarrollador, esto vamos a hacer pruebas y ponerse los dos conjuntamente a hacer pruebas y se encuentran un montón de errores y todavía es una fase muy temprana, ¿vale? Todavía es una fase bastante temprana. Ok, vamos a hacer de la nueva mujer embarazada, si lo sabéis no lo digáis, ¿eh? Si sabéis no lo digáis. Vale, esto es un caso real también muy típico, que seguro que ha pasado, ¿no? No llegamos, no llegamos al final del Spring, no teníamos o equitareas por hacer y no nos da tiempo. ¿Qué hacemos el jefe del equipo? Pues, venga, más recursos, vamos a contactar más gente, vamos a meter más gente. A mí me han llegado a decir esto, ¿eh? ¿Puede venir mi mujer a testear? No, como ha venido tu mujer a testear, si no ha testeado nunca, ¿no? Es decir, pero es como la, fijaros, dice un Project Manager, es alguien que piensa que nueve mujeres embarazadas pueden tener un bebé en un mes. No funciona de esa manera, ¿vale? No funciona de esa forma. Ok, testin basado en riesgos. Vale, esta parte también es importante. ¿Por qué? Porque dentro del testin ágil estamos hablando de iteraciones cortas, iteraciones de dos semanas, tres semanas, iteraciones muy cortitas. Entonces, el testin tenemos que hacer muchísimas pruebas donde nos enfocamos, donde nos centramos, por donde empezamos. Entonces, es importante analizar los riesgos, es decir, analizar los riesgos de nuestra aplicación, lo vamos a ver aquí más fácil. Por ejemplo, nosotros vamos a tener una serie de tareas que vamos a desarrollar, pues podemos detectar cuáles son las funcionalidades o componentes o parte del código que se van a ver afectadas, que se van a ver modificadas por mi desarrollo nuevo. Pues esta funcionalidad aquí o este componente entero, etcétera. Dependiendo del grado en el que se vea afectada esa funcionalidad, yo puedo decidir hacer un testin más en profundidad, hacer más pruebas o hacer menos pruebas, ¿vale? Entonces, fijaros, cuando yo no tengo un desarrollo nuevo, pero solo tengo dos semanas, no puedo probar todas las cosas que ya existen. Entonces, tengo que filtrar, tengo que quedarme con una selección de las cosas que de verdad corren un riesgo de haberse rotos, de haberse modificado y de que se haya podido introducir un nuevo error. Entonces, tenemos que hacer un análisis de riesgos de ese spring. ¿Cómo hacemos ese análisis de riesgo? Pues con el equipo, ¿vale?, con productos y con desarrollo. Porque nosotros como personas que hacemos pruebas no tenemos todos los ángulos de visión, con lo cual necesitamos que producto nos diga, oye, pues esto es esto, es súper crítico para el usuario, hay que comprobarlo. Desarrollo nos puede decir, oye, pues esto, cuidado, que tiene una dependencia con esto otro y hay que probarlo. Y necesitamos ese análisis conjunto de riesgos. ¿Vale? ¿Habéis hecho análisis de riesgo alguna vez, de algún tipo, de alguna manera? Ok. A ver, cuidado con los análisis de riesgos, ¿vale? Hay mucha gente que prioriza con la sigla esta de Moscú, ¿no?, lo de MAS, CHUD, QUD y WON, que digamos que son de lo más importante a lo menos importante, ¿no? Entonces, bueno, pues el típico caso es, bueno, dice de los creadores todo es falso salvo alguna cosa, dice hacemos priorización pero todo es MAS. Entonces, no hacemos priorización, ¿vale? Es decir, cuando todo es importante, nada es importante. Entonces, cuidado con eso, ¿vale? Decía, hay que hacer un análisis de riesgo, pero no podemos tampoco considerar que todo es importante, las cosas tienen que tener una escala. ¿Vale? Puebas exploratorias. Dentro del mundo ágil se hace mucho un capié en que se hagan pruebas exploratorias. Fijaros, se ve muy claro en este dibujito las pruebas tradicionales o incluso las pruebas automáticas que hace una máquina. Además, eso está muy bien por el debate siempre de las pruebas automáticas, la IA. Yo llevo escuchando de eso, 14 años que las pruebas automáticas iban a quitar el trabajo a los manuales y ahora viene que la IA va a quitar el trabajo, etcétera. Pero bueno, no va a pasar. Fijaros por qué una máquina al final, una prueba automática, siempre sin un camino, es decir, es un script, es un guión que se le da. A chequear a esto, chequear a esto, chequear a esto. Tú lo puedes hacer veinte mil millones de veces, lo puedes hacer muy rápido. Te va, por supuesto, te aumenta muchísimo la productividad del equipo, pero siempre es el mismo camino, el que veis de la flechita negra. Eso dentro de las pruebas se conoce como la paradoja del pesticida. Significa que siempre pasamos por el mismo camino, con lo cual llega un momento en el que ya mis pruebas no son efectivas, porque ya siempre hago lo mismo, ¿no? Como el pesticida. Si le echas las plantas al mismo pesticida, al final ya deja de ser efectivo. Las pruebas exploratorias son pruebas que hacen las personas de forma manual basada un poco en su experiencia y basada en su creatividad. Entonces, cuando se hacen pruebas exploratorias se exploran otros caminos, se exploran otras formas de llegar a los sitios, a las aplicaciones y conseguimos encontrar errores que con el camino tradicional no encontraríamos. Entonces, en las pruebas ágiles se hace mucho un capié en que se hagan pruebas exploratorias para justamente esto mismo. Una herramienta chula para hacer pruebas exploratorias son los mapas de ideas. No sé si alguna vez lo habéis utilizado, para otro propósito quizás. Dentro de las herramientas como por ejemplo Xmine o algunas de estas, pues bueno, te permiten estructurar tus ideas como una especie de esquema y además puedes ir, conforme se te van ocurriendo ideas, las puedes ir anotando, las puedes ir probando y puedes ir anotando un poco los resultados, si esto funciona, si falla, si tenemos que una duda de qué pasaría si voy por este camino y de alguna forma podéis estructurar las ideas siguiendo este mapa. Yo lo recomiendo si no lo habéis usado nunca, es bastante potente, es decir, incluso si soy desarrollador y trabajo con otras aplicaciones y no tenéis tiempo de poner a hacer pruebas exhaustivas, pues haceros aunque sea un mini mapa de ideas y darle una vuelta a vuestra aplicación, seguro que encontráis un montón de cosas. Vale, bueno, esto lo podemos saltar. Pirámide de automatización. Ok, vamos con la parte de las pruebas automáticas. Como decía antes, dentro de un sprint, dentro de una iteración tenemos muy poquito tiempo y además tenemos un problema dentro del mundo del testing, que son las pruebas de regresión. Las pruebas de regresión son las pruebas sobre la funcionalidad antigua para ver que no se ha visto afectada por los desarrollos nuevos. ¿Qué pasa con mi funcionalidad antigua? Que siempre crece, crece, crece, crece sin mi aplicación, cada vez voy introduciendo funcionalidades nuevas, pues cada vez voy a tener más pruebas que hacer de todo lo antiguo. Entonces, en algún momento siempre tengo dos semanas o tres, lo que sea mi iteración. ¿Cómo voy a probar todo lo antiguo? No me da tiempo. Entonces, las pruebas de regresión son muy buenas candidatas automatizarse, es decir, que se hagan de forma automática para poder ahorrar tiempo. Hay un concepto, que es el de la pirámide de automatización, que nos dice que tenemos que intentar automatizar pruebas siguiendo esta proporción de pirámides. Es decir, tener pruebas unitarias en la base, bastante, tener luego pruebas de integración o de API y finalmente tener pruebas en tuEN o pruebas de UI. ¿Por qué? Esta proporción tiene un motivo y es porque las pruebas, mientras más estemos en la cima de la pirámide, son más costosas y son más lentas, con lo cual hay que intentar compensar con pruebas más rápidas como las pruebas unitarias o pruebas de API, que son muchísimo más rápidas. Si conseguimos tener pruebas automáticas en esos tres niveles, pues tenemos más tiempo para hacer pruebas exploratorias, por ejemplo, que son las que hemos dicho antes. Estos son criterios para automatizar. La cuestión real es que muchas empresas hacen esto. No hacen la pirámide, sino que hacen lo que se llama el cono del helado. Es justamente al revés. Es decir, tienen muy poquita prueba unitaria. De hecho, ¿cuánto de vosotros habéis hecho pruebas unitarias alguna vez o por aquí algunos sí? Bien, bien. Y al final, pues, recaen todos en el test inmanual a través de la UI. Entonces, bueno, estoy bastante lento. Hay que intentar cambiar esta proporción. Siguiendo un poco la evolución natural de todo esto, ya tenemos pruebas automáticas, pues vamos con la parte de integración continua. Vamos con la parte de integración continua, que significa poder tener estas pruebas unitarias dentro de un mecanismo de 6D, un mecanismo que despliegue o haga construcciones o despliegue del código, pero además también que ejecute esas pruebas unitarias. Lo que son las pipeline de 6D pueden ser todo lo compleja que queramos. Tampoco vamos a poner una tan compleja, vamos a poner esta un poquito más sencillita. Pero si conseguimos tener un proceso automático donde, a través de un control de versiones, como puede ser Git, vea cuando hay cambios en el código y lance, pues, la construcción del código, las pruebas, el despliegue en los entornos. Si conseguimos tener un proceso automático nos va a ahorrar muchísimo tiempo. No solo nos va a ahorrar tiempo, sino que nos va a dar cifras. Es decir, si nosotros conseguimos construir esta herramienta dentro de nuestro proceso de desarrollo, vamos a conseguir que cuando un desarrollador introduzca el código nuevo, automáticamente se lance este proceso, se ejecute en las pruebas y nos dé el resultado. Entonces, vamos a obtener muy rápido si el código nuevo ha roto algo o no ha roto nada. Esto es complejo. Obviamente, dicho aquí, parece muy sencillo, pero construir esto lleva tiempo. Ok, vamos con las últimas ya casi retrospectivas. ¿Quién ha hecho retrospectivas por aquí? ¿Quién ha hecho la del barco? ¿La retrospectiva del barco alguna vez? Pues esta es esta más chula. La típica retrospectiva es que hay bien, que hay mal, que se puede mejorar la típica. Esta es esta más chula porque es un dibujito que lo podéis copiar por ahí. Y, bueno, tenéis el barco, el sol, las piedras, los tiburones o los riegos que hay por ahí. Entonces, es otra forma de clasificar qué ha ocurrido durante el desarrollo. Por ejemplo, las rocas. ¿Cuáles han sido los bloqueos que yo tenía? ¿Cuáles han sido los…, pues justamente eso. Las piedras en el camino que me he ido encontrando durante el spring. O el motor o el viento. ¿Cuáles son las cosas que me han impulsado para ir adelante? ¿O los riegos? Lo que decíamos antes, esa análisis de riego que habíamos hecho. Cuidado al ponerse en producción, que puede romper esto o otro. De esta forma, si el equipo sabe identificar diferentes cosas que aún ocurrió durante el spring en cada una de estas partes, pues podemos mejorar para el futuro. Es decir, podemos en la siguiente iteración una de las cosas buenas de allá y que, como son interacciones, siempre tenemos una nueva oportunidad de mejorar. Venga, casi terminamos. No sé cómo vamos de tiempo, por cierto. Ahora, de todas formas, me gustaría que hicierais preguntas, que hay, ya estamos muy calladitos. Vale, al final todo esto es mejor a continuas. Es decir, los testers, también porque nos interesa bastante, porque nos facilita mucho la vida en aplicar todas estas cosas, pero siempre buscamos esa mejora continua. Es decir, si conseguimos mejorar como equipo, comunicarnos mejor, definir mejor las cosas, trabajar conjuntamente y alineados, pues vamos a tener menos errores. Con lo cual, al final, cuando los equipos empiezan a aplicar a algunos de los conceptos que hemos visto hoy, empiezan a ver los beneficios y es cuando quieren aplicar más. Vale, al principio cuesta, al principio os vais a encontrar con esto, siempre, si no lo habéis encontrado ya. Es decir, llega alguien con la rueda, no estamos muy ocupados. Ya, si todos los equipos están ocupados y todo el mundo está haciendo un montón de cosas, pero es que si no mejoramos, siempre vamos a estar en la misma problemática. Entonces, se trata de eso, ¿no? De mejora continua. Y bueno, la calidad final no es algo casual, ¿vale? La calidad, conseguir un producto de calidad es el conjunto de esfuerzos, decisiones inteligentes, habilidades del equipo. Es decir, cuando nos encontramos un producto de calidad que vosotros como usuario, pues, puede distinguir perfectamente una aplicación de móvil, un programa que tiene errores a otro que realmente tiene buena calidad, no es casual, no es…, hoy han hecho algo con calidad por suerte, no, es porque le han puesto de verdad interés y ganas, ¿vale? Vale, pues acordaros, los dos pilares que hemos dicho al principio, el equipo el completo y feedback frecuente y temprano, ¿vale? Si no cumplí esos dos pilares, pues, mira, os va a pasar lo de allí. Vuestra Relíja de Inclusión, pues, va a explotar, ¿vale? Y el equipo de testing, pues, se va a tirar por la venta, literalmente. Y esta es mi fase favorita, que es con la que me gusta cerrar siempre. Los testes no rompen el código, ellos rompen las ilusiones que se tienen sobre el código. Es importante que sepáis. Y bueno, con mucho redbull y mucho ánimo. Y ahora sí las preguntitas. Aquí tenéis mi dato de contazo y venga, tú no te preguntas. Si quería preguntar sobre este pirámide donde había los tests integration, test, unit test y tests manuales. Y como según su experiencia, integration tests están hechos por los programadores. Sí, por quien exactamente? Porque unit test hace backend developer y integrations. Vale. A ver, la teoría nos dice que la base que son las pruebas unitarias, las debe hacer el equipo de desarrollo, ¿vale? Es decir, la base que tenéis ahí, las pruebas unitarias, las debe hacer el equipo de desarrollo. Sí que es verdad que nosotros como equipo de testing podemos ayudarle o darle ideas, ¿no? Porque sí que suele ocurrir que cuando el equipo de desarrollo hace pruebas unitarias te hace el happy path. Es decir, la prueba unitaria básica, el caso positivo más típico, ¿no? Y no tienes esa mentalidad de testers de ir a romper la aplicación, ¿no? Es decir, cuando tú tienes una función suma, suma a y b, no solo te tienes que conformar con probar sumar dos y dos. También tienes que probar número negativo, sumar números con decimales, intentar sumar letras, es decir, todo ese tipo de variaciones son pruebas unitarias. Entonces, nosotros podemos ayudar al equipo de desarrollo en que tengas diferentes datos de entrada para esas pruebas unitarias, pero en teoría lo hace el equipo de desarrollo. Las pruebas de integración suele ser fictificti, es decir, tanto el equipo de QA como el equipo de desarrollo. Nuevamente, si hablamos de pruebas de API, las podrían hacer también el equipo de QA. Es decir, si tú tienes una documentación buena de las APIs, saber lo que hace cada petición, pues tú puedes con una herramienta como postman o alguna de ese tipo, puedes entrar hacia esa petición, comprobar las respuestas, chequear que te han llegado todos los campos, lo puedes hacer en un QA perfectamente. Si son integraciones entre componentes o clases que llaman otras clases y hay que hacer mocs, etcétera, ya se requiere un poquito más de habilidad técnica con lo cual quizá el equipo de desarrollo pueda participar más en esa parte. Y si la parte ya entúe en Immanuel, sí sería del equipo de Detecting. -Mal, gracias. -Más preguntas. Gracias, Frank. Mira, me surjo una duda. Hay alguna fase de la gestión de proyectos desde el punto de vista tradicional que comparta la gestión de proyectos con metodología ágila? Es decir, una manera de pensar tradicional comparte algo en algún punto con el desarrollo tradicional? A ver, sí, no. Yo te diría que casi que no, porque la forma de desarrollo tradicional que sigue funcionando en algunos sitios, que no significa que haya que denoctarla en algunas empresas, pues siguen funcionando. Pero las metodologías tradicionales son para desarrollos muy largos, es decir, pues no sé, compañías que no tienen a lo mejor necesidad están desarrollando un producto a largo plazo, pero dentro de la mayoría de compañías que nacen hoy en día o que se desarrollan productos nuevos hoy en día, hay mucha competencia. En el sentido de, oye, el primero que llega al mercado y aporte esa visión nueva o ese producto nuevo se lleva el pastel. Entonces, la tecnología es muy cambiante, entonces necesitamos más periodos, más cortos de desarrollo. Entonces, las metodologías tradicionales no cumplen con muchísimas de los conceptos que estamos hablando, porque vamos a hacer el texto intemprano, todo demasiado cuadriculado, no hay tanta flexibilidad, pero sí que se puede meter ciertas mejoras, es decir, puede seguir haciendo metodología tradicional, pero por ejemplo, en tu fase de definición de requisito, que sería al principio, involucrar al téster, por ejemplo, o involucrar al cliente. Bueno, el cliente lo tienes que involucrar a la fuerza, ¿no? Pero podrías involucrar al téster para que estrellas los requisitos, porque si tú el téster lo dejas para el final y han pasado seis meses cuando llega el equipo de testing y te encuentran los errores y vienen a tirar del hilo y se dan cuenta que es que el requisito estaba mal, se podría haber evitado eso hace seis meses. Entonces, es cierta mejora que sí pueden introducirse dentro de un equipo de adicionales. Porque el téster hace la función de validación, ¿no?, a medida que va avanzando el proyecto, ¿no? Vale, hace ambas, de todas formas, eso es interesante porque coloquialmente utilizamos muchas veces, indistintamente, verificación y validación. Y realmente no es lo mismo, ¿vale? El téster se preocupa más de la verificación y lo que es el cliente o el representante de negocio de la validación. Os explico la diferencia muy sencilla. Por ejemplo, una persona quiere cruzar un precipicio, ¿no?, de una parte a otra, de un punto A a un punto B. Podemos hacer un puente, ¿vale? La solución es un puente. Entonces, yo pongo un puente colgante y como téster cruzo para ver si funciona, no me he caído, he sobrevivido, entonces funciona. Llevo del punto A al punto B. Pero un puente colgante a lo mejor con una cuerda cita, el cliente cuando llegue eso no le va a gustar. Porque va a decir, no, no, esto es peligroso, yo no quiero esto, yo quiero un puente como el puente del hombre para cruzar. Entonces, esa diferencia entre verificación y validación. Verificación funciona correctamente y validación hace o cumple con las expectativas del cliente. Son dos cosas diferentes y ambas hay que cumplirlo, obviamente. Entonces, el CUA sí que está más en la parte de verificación, pero también participa en validaciones como puede ser UAT o beta testing, etcétera, etcétera. También participa en… Entonces, el principal tractor, digamos, de ese proyecto con metodología ágela es el valor que se le entrega al cliente. Sí, efectivamente. Y puede ir en contra del manifiesto a Yael? No, eso no. El qué? El… No, no, no, justamente… Y escuchándole la cifra. No, justamente uno de los cuatro puntos del manifiesto a Yael es ese, la colaboración con el cliente. Con lo cual, nosotros tenemos que buscar algo que el aporte va a valorar el cliente. Y si el cliente no va guiando desde el principio, vamos a darle la tecla. El problema es cuando no colaboramos con él, esperamos al final y al final le damos a algo que no es lo que él quería. A lo mejor no es lo que él quería, es que pensé que los clientes son muy caprichosos. Lo mejor es que ha cambiado de idea durante el proceso. Entonces, hay que intentar colaborar con él. A ver, no todos los día hablando con él, pero si puede, periódicamente, sí. Collaboración con el cliente sube una negociación contractual. Es importante, pero sí, efectivamente, creo que uno de los puntos clave es eso. Asegura que le entregamos al cliente lo que es lo que es. (Murmullo) Cuando es de Scrum, el cliente suele estar en alguno de los puntos. Sí. A ver, y normalmente tienes que estar al Product Owner, que al final es el representante de esa persona. Si el cliente no está físicamente, tiene que tener comunicación directa con el Product Owner. Pero, sí que bueno, en Scrum tienen las demos o los Spring Reviews que se conocen para justamente cada dos semanas, cada tres semanas enseñarle al cliente lo que se ha desarrollado. ¿Quién te diga? Pues sí, vamos bien o no vamos bien. Y luego con Kanban, ¿cómo metes los QAs? A ver, Kanban es otra metodología ágil, pero requiere muchísimas madures. Es decir, en Kanban casi todo el QA tiene exáceos automáticos, porque al final, en Kanban es un proceso, es un framework, un marco de trabajo muchísimo más sencillo que Scrum, porque no tiene tantas nombres, tantas fases, pero digamos que conforme se va haciendo se va entregando. Por lo cual el equipo tiene que ser muy maduro en el sentido de que los desarrolladores e incluso en Kanban se utiliza mucho TDB. Es decir, es una metodología de trabajo donde el desarrollador escribe primero las pruebas y luego desarrolla el código. Es decir, primero escribe las pruebas unitarias o del tipo que sea y luego escribe un código para que cumpla con esas pruebas. Esto hay un punto intermedio que el equipo de QA le da las pruebas al equipo de desarrollo antes de que entregue su desarrollo. Entonces, mucha gente dice que ya, pero es que le está dando las respuestas del examen. Entonces, el desarrollador, si ya sabe lo que tú vas a probar, lo va a hacer bien ya, pero es que eso es lo que queremos, que lo haga bien. Entonces, de alguna forma, esa forma de trabajar en Kanban donde escriben primero las pruebas, ahí ya está haciendo el testing porque se está asegurando que lo que van a desarrollar ya funciona. Entonces, se va a entrar en un mecanismo de desarrollo con desarrolladores más senior donde eso se ejecutan luego las pruebas de forma automática, entran en una pipeline de CICD, se despliega automáticamente y incluso se despliega producción. Es decir, conforme van entrando tareas, se van desarrollando y se van entregando. No es como escran que tú entregas cada dos semanas, en los que entregas muchísimo más rápido, tarea por tarea, pero requiere de eso de un equipo muchísimo más maduro, más senior en programación, con pruebas más automáticas, etcétera. Es complicado, Kanban, es bastante complicado. Kanban funciona en equipos muy pequeñitos y ese tipo de cosas. Más preguntas por ahí. Hay una pregunta en que, ¿no es? Sí, es YouTube. Mira, ¿qué te preguntan? Buenas tardes, Frank. ¿Cómo se podría equipo de CUA al principio de desarrollo involucrándolo en el equipo? ¿Veis revisando el criterio de aceptación y que prepare sus casos de testeo? Y aquí después preguntan. ¿Pero alguna de otras cosas que poder hacer durante el exprim mientras los programadores van teniendo las implementaciones? Sí, efectivamente. A ver, claro, siempre va a haber un pequeño desfase en el sentido de que nosotros no podemos testear el código hasta que no esté escrito, pero sí podemos hacer lo que he dicho antes, escribir las pruebas para que el desarrollador ya pueda cumplir esas pruebas. Entonces, por ejemplo, efectivamente, como dicen ahí, lo que podemos hacer muy al principio es revisar los requisitos, ver que todo está correcto, que no hay incoherencias, que no hay ambiguidades y una vez tengamos eso claro, escribir un plan de pruebas o diseñar unas pruebas para que el desarrollador las haga en cuanto termine. Otra cosa que pueden hacer es lo que comentaba antes, es emparejarse con el desarrollador y hacer pruebas en el local. Es decir, no sé si alguna vez lo habéis hecho con un QA, pero no me imagina en la cantidad de cosas que surgen en ese momento. Pensad un desarrollador que está en ese momento en su local, con su rama abierta, su visual estudio, su entorno de trabajo y ha terminado algo y le dice al QA, ven, síntate conmigo y vamos a hacer pruebas y empiezan los dos. Pones, tú pruebas esto, ahora pones otro, se encuentran un montón de cosas y los buenos que se arreglan sobre la marcha, porque está todavía el código abierto, con lo cual no es que luego se haya al final, que hay que escribir un informe, mandárselo a no sé quién, es muchísimo más rápido. Entonces, para trabajar en paralelo con el desarrollador, yo creo que es muy bueno trabajar por pareja con el desarrollador. Por ahí, bueno, allí creo que también no teníamos… Entonces, por así decirlo, resumiendo, casi todos los fallas suelen venir por la falta de comunicación, ¿no? La gran mayoría sí. Entonces, arreglando la comunicación de que se hable más entre el grupo y el cliente y ir testeando paso a paso lo que se va haciendo, prácticamente estaría solucionado de una forma sencilla, ¿no? Sí, parece sencillo, de hecho. Parece sencillo, pero es muy complicado conseguir eso. Pero sí, efectivamente el resumen es ese. A ver… ¿Puedo hablar de los fallos también? Bien. A ver, luego hay otras causas. Es decir, la causa de los errores hay muchísima otra naturaleza. Al final, los equipos también somos humanos, tanto los desarrolladores como los Juay, puede que nos equivoquemos y haya un error, algo que nadie ha contemplado, es decir, incluso aunque hablemos de estos riesgos que hemos dicho antes, analicemos las dependencias, hablemos entre todas las partes, puede ser que se nos haya escapado algo. Es decir, al final también existe el software muy complejo, con unas arquitecturas muy spaghetti, muy complicados. Entonces también se puede producir errores por complejidad, por falta de tiempo, muchas veces también, por… Hay que entregar o tenemos una fecha concluyente y se va con estrés. Entonces, todo eso también produce errores. Pero la gran mayoría, la gran mayoría vienen por falta de comunicación y entendimiento. Sí. Básicamente, el que había dicho la pregunta en YouTube era mi amigo y… No, vale, vale. Otra manera de la pregunta es cuando, sobre todo, como ha dicho, al final acabo el problema en la comunicación. Pero por lo que yo gran parte veo, bueno, primero, que normalmente en todos los proyectos no hay un CUA. Eso es lo primero. Ya hay el 90% de los proyectos, se te lo habría admirado. Y segundo, es que normalmente suele ser que el jefe o el… bueno, o el ProDwarner habla con un cliente, te dice, «Pues me tienen que hacer una aplicación en Java y ahí te queda». Y entonces mi pregunta va desde el desarrollador. ¿Cómo tú la puedes decir a ese bueno jefe o ProDwarner de, «Oye, sé lo que es Java y sé que tengo que hacer la aplicación en Java, pero necesitaría más cosas o más requisitos o directamente déjame meterme en la llamada y escuchar lo que necesita el cliente». O sea, yo lo que creo que es muchísimo proyecto es que no hay un CUA, eso es lo primero. Y segundo, que el ProDwarner escucha una cosa, le dice una cosa totalmente distinta al desarrollador y entonces la metodología está agile, lo que hace es menos agile las cosas, porque si el desarrollador escucha, se lo que quiere el cliente más o menos sabe los requisitos que necesita. Entonces, ¿cómo le dirías tú a un ProDwarner los requisitos que necesita? Porque a lo mejor no sabe qué requisitos necesitan en el sentido de, «Pues necesito, no sé cuánta entidad, este esquema, un caso de uso». Sí, a ver, yo creo que una clave que tú has dado es justamente esa, es decir, hay que decir, «Oye, involucrame». Es decir, es que si no está involucrando al resto del equipo, no es allá y realmente es lo que estamos diciendo, si solo es el ProDwarner con el cliente y no involucra al resto del equipo, entonces no está trabajando con ese concepto de tres amigos que decíamos. Entonces, los CUA, por ejemplo, incluso aunque la empresa tenga CUA, es verdad que tú dices que hay muchas empresas que no tienen CUA, pero es que incluso cuando lo tienen no los involucran, los dejan como apartes, como, bueno, pues ya te estarán. Entonces, muchas veces nosotros sufrimos eso, tenemos que estar, «Oye, por favor, méteme en la reunión», no a todos los CUA, pero quizás al jefe de equipo o a un representante. «Méteme en las reuniones, méteme en los refinamientos, en las planificaciones, en las demos con clientes», porque ellos tienen que aportar su visión, el CUA tiene que aportar su visión y el desarrollador es hasta entre lo mismo. Entonces, el desarrollador, si no están contando con él, tiene la misma problemática. Sí que es verdad y esto, yo por mi experiencia, los perfiles de desarrollo como que se conforman más en el sentido de, a mí me aplicación Java dice, sí, pues hasta puede haber algún Java y no tiene esa insistencia, pero tiene que tener más insistencia de decir, «Oye, que me involucres, que yo también quiero saber qué es lo que el cliente está pidiendo y necesito saberlo», o el desarrollador necesita decirle, «Oye, pues esto no se puede desarrollar, porque tiene estos incrementos». Bueno, algunas veces también lo que pasa es que el desarrollador le dice, «Pero necesito más cosas y el podón te dice no las tienes ya con lo que te he dicho y ahora cómo le hable y cómo la dice». Sí, a ver, pues a cosas las que hay que lidiar. A ver, ahí entra también un juego, si hemos hablado de la definición de hecho, hay otra definición que no es tan famosa que es la definición de listo, la definición de ready, es decir, cuando algo está preparado ya para hacerse. Entonces, esa definición es buena para poder empezar a desarrollar algo. Vale, es decir, el equipo puede decir, «Oye, yo no voy a empezar a desarrollar hasta que no tenga mi requisito, mi diseño, mi diagrama de arquitectura, la duda resuelta y hasta que yo no tenga esto listo no empiezo a desarrollar». Esa definición también existe, no es tan famosa como la definición de hecho, pero sí se puede utilizar también. Entonces, llegado a un punto extremo donde no te hacen caso, pues hay que poner esas puertas, decir, «Oye, si no cumplimos estos no empezamos a trabajar, es que si no tenemos lo mínimo no puede empezar a trabajar». A ver, no podemos pasar tampoco de cero a cien. Sí, pero en la mayoría de casos realmente, por no forzar esa situación lo que hace es desarrollar la aplicación, luego vienen los desastres y luego te echan a ti la culpa de que el desastre es tuyo. O sea, como que no ha dicho tú y ahora el error sale ahí y ahora es tu culpa. Bueno, no, estoy diciendo casos concretos. No, no, estoy diciendo casos muy comunes, muy comunes. Estoy diciendo «ven». Yo solo estoy diciendo casos reales que he vivido… Pero tú lo has definido bien, llegando desastres. Es decir, efectivamente eso es perjudicia para todo el equipo, es decir, no solo para el desarrollador porque luego le vayan a echar la culpa, es que para, efectivamente, si el de producto luego al final el resultado no es lo que quería también el cliente le va a decir «Oye, ¿qué pasa? Esto no es lo que yo te conté y él tendrá que dar la cara también contra el cliente». Entonces hay que entender ahí que todo el mundo va en el mismo barco, es que eso es súper importante. Si los roles empiezan a pasar, serán pelotas unos a otros, hay que mentalizarse en los equipos de eso, de que todo está dentro del mismo barco y el éxito del equipo es común. A ver, yo voy a poner una situación. Imaginaros que son personas de calidad, de testing, de pruebas. Poneros el gorro un momento de personas de pruebas y, oye, había hecho las pruebas de vuestros desarrollos, eso es un desastre, está fallando todo por todos lados y llega el jefe de vuestro proyecto y dice «Oye, necesito la firma de CUA o del equipo de calidad para salir de producción. ¿Qué hacéis, firmáis o no firmáis?». Dice el jefe del equipo. Es que, mira, hemos hecho una campaña de marketing en televisión, hemos gastado 2.000 millones de euros en la campaña, para el día 17 esto tiene que salir a la fuerza, pero tú sabes que eso va a explotar, porque eso está reventando por todos lados. Y el test está diciendo que no puede retrasarse la fecha, que tiene que salir a producción sí o sí, que necesita la firma del equipo de calidad. ¿Firmáis o no firmáis? Si la he contado, es bueno. Buena pregunta. Por ejemplo, coge 10 de día. Mira, les falta esto, esto, esto y esto. ¿Qué haces, compadra? Ve a la visita, si él quiere sacar la delante o hacer un perro, si quiere, pero en tu proceso se trata. Pero es tu nombre, es tu nombre el que va a la firma. Pero ahora al final que me acaba pagando. Es que está, entonces. ¿Pero es el gorro de cálida? ¿Hablaríes con su jefe, con el jefe de vuestros jefes? Para decirle, mira, este está loco y quiere salir a producción con todo esto roto. ¿Pero que tal iré para la corrupción? Se me viene. Es como no, como nos marcamos y se lo recupan. Vale, es decir, por supuesto hay que ser flexible, pero hay que entender que tampoco podemos hacerse de, ante cosas que no tienen, que cuando oyes que no, es que esto no, voy a poder hacerlo, es que no me está dando el requisito, es que no puedo desarrollar esto. O esto no puede ser a producción tal y como está. Entonces hay ciertas cosas, hay que sentarse con ellos, explicarles los riesgos, explicarles los fallos, hablar con clientes, explicar la situación. Hay que hacer todo lo posible. Hay que hacer todo lo posible. Yo no firmaría. Pero bueno, vale, entonces, te lo digo desde el punto de vista de desarrollo lo mismo, ¿no? Si es que es una pregunta suficiente para hacer bien vuestro trabajo, hay que plantarse. En el caso extremo, ¿eh? En el caso extremo, son casos extremos. (Murmullo) (Risas) (Murmullo) Tu, en el que me está encantando el ratito este que está muchando, gracias, Frank. Ese tipo, ese típico equipo de desarrollador, jefe de proyectos con diseñador maqueta, hablo de roles, ¿vale? No de, el diseñador que también maqueta, el jefe de proyectos que también programa y el cliente. ¿Cómo metemos ahí el QA, el rol de QA, vale, no la persona, sino el rol de QA, ¿qué recomendaciones tiene para equipo así pequeñito? Vale, a ver, si no queréis un rol específico, me refiero, una persona dentro de ese dominio de QA, porque el equipo sea pequeño, no haya recursos o suficiente, es el equipo que se tiene que hacer responsables de la calidad. Es decir, en AYIL, en Testinágil, la calidad no es propiedad de una única persona, es de todo el equipo al completo. De hecho, hay otro manifiesto del Testinágil que no lo he puesto aquí, pero justamente dice eso, que la calidad no es responsabilidad del teste, sino que responsabilidad del equipo al completo. Entonces, si no tienes ese rol específico, pero tienes diseñador, project manager, product manager, desarrolladores, pues habrá que departirse la calidad entre todos esos roles. Por ejemplo, el product owner o el project manager tendrá que hacer esas pruebas de validación. De decir, oye, este es el puente que el cliente quiere, tendrá que asegurarse que lo que se ha hecho cumple en la expectativa del cliente, el desarrollador, si no tiene QA, pues tendrá que testegarse por pares. Es decir, oye, pues yo te voy a hacer pruebas a ti, tú me haces a mí, o hacemos pruebas unitarias, o vamos a coger los diseños y vamos a revisar los diseños, o el product owner y revisar los diseños del diseñador y le saca errores o lo que sea, pero tienen que hacer esas revisiones. Entonces, entre vosotros, ¿obtenes que distribuir esa responsabilidad? Muy bien, muchas gracias. Y ha asociado eso en cuanto varía el coste de un proyecto cuando se integra QA en horas, en dinero, en recursos, en lo que tú quieras. ¿Cuánto varía? Se incrementa, se decrementa, un porcentaje, ¿cuánto? Claro, a ver, yo no todos sabría decir un porcentaje, porque depende también tanto de la persona de calidad que haya como de la cantidad de testing que se haga, pero sí te puedo decir que es una inversión. Es decir, muchas veces se prescinden…, yo lo entiendo, por ejemplo, en empresas pequeñas en Startup, que están comenzando y, obviamente, el presupuesto no es muy alto, pues no pueden permitirse tener una persona exclusivamente para QA, que aun así tendrían que hacer lo que he hecho antes, repartirse el trabajo de calidad de testing. Pero realmente cuando tú introduces una persona de calidad que ya es cuando ya se han producido todos los desastres que decía antes, ahí es cuando ya la gente dice, «Uff, el cliente ya se está quejando, ya se va a marchar, entonces ahora contratamos a alguien de calidad». Realmente las empresas lo ven como un gasto, lo suelen como un gasto, pero realmente es una inversión. Es decir, yo no sé si alguna vez alguna empresa se ha puesto a contar cuánto se ha gastado por falta de calidad, ¿no?, en lo que decía. Cuando los errores han llegado a producción, ha habido quejas de usuarios, el equipo ha tenido que trabajar a deshoras, horas extras…, han contabilizado todo eso, decía, han medio cuántos han gastado en ese tipo de cosas. Entonces, yo no sé qué porcentaje se pueda ahorrar, pero que sea ahorra es seguro y bastante, es una inversión. Es decir, al final, si te puedes permitir invertir en eso, puedes invertir, si puedes, claro. Bueno, ya estoy rodeo aquí. Ok, pues nada, muchas gracias, espero que os haya gustado y que haya aprendido cosas nuevas. Muchas gracias. (Aplausos) (Aplausos)
