Hace unos meses, quizá lo recuerdes, hablamos de aquello de que no se puede ser ágil si se prueba en cascada, ya comentamos que es muy usual, es lo clásico, ver como las pruebas están y quedan fuera del equipo, en otro departamento (departamento de desarrollo vs departamento de QA) o equipo externo.
Decíamos entonces que esto indica que el equipo no es multifuncional, no contiene todas las competencias para de manera autónoma completar un requisito (los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad)
Hablábamos también de que cuando la persona de pruebas no es de otro departamento, sino que está inmersa en el equipo de desarrollo como un miembro más, esto tiene mejor pinta, porque el equipo posee todas las competencias necesarias para lograr completar el trabajo, sin depender (o dependiendo mínimamente) de otros equipos, departamentos, áreas o roles fuera del mismo.
Más aún, en un extremo mayor, más complicado de ver en el mundo real, aún si cabe, habrá quien, desde el “mundo ágil” recomiende que más que personas de pruebas debiera haber tareas de pruebas, que pudieran ser desarrolladas por casi cualquiera, las pruebas serían así una dedicación mas que una especialización profesional.
Y a lo que vamos hoy es a.. ¿Y todas las pruebas debieran estar dentro del Sprint y pertenecer y ser ejecutadas por el equipo? ¿No hay pruebas externas? ¿Pruebas fuera de Sprint? ¿Pruebas con otros equipos?
Hay un tipo de prueba que suele escaparse a este tipo de recomendación de que todo el testing quede en el equipo y sea una tarea dentro del Sprint. Algunos las llaman pruebas globales de aceptación, otros pruebas de reléase, y como en cada casa hay una terminología, me estoy refiriendo a aquellas pruebas finales antes de pasar algo grande a producción, aquellas que buscan probar la integración de los trabajos desarrollados por varios equipos diferentes.
Sacar estas pruebas fuera del Sprint no suena muy ágil pero la realidad es otra (ya lo decía Henrik Kniberg). En un Scrum perfecto quedarían dentro del Sprint, en la realidad es la prueba que, aun trabajando de manera ágil, más vas a ver fuera.
Las razones de por qué están fuera son múltiples: implican a muchos equipos (puede que a otros equipos no ágiles), necesitan de hardware específico, necesitan procesos de integración complejos, etc. Que sí, que si la arquitectura, el proceso, la automatización, etc., fueran perfectos no sería necesario sacarlas pero que lo que te encuentras no es eso. Y este tipo de pruebas es las que más verás fuera del Sprint.
Eso si, cuanto peor sea el Testing dentro del Sprint peor y más largas serán esas pruebas fuera del Sprint. Por ello, no dejes de mejorar las pruebas dentro del Sprint y de perseguir que las pruebas fuera del Sprint sean solo testimoniales o que un día desaparezcan.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Estimado Javier, una pregunta: para estas pruebas de aceptación o de release deben usarse los mismos test case que para las pruebas dentro del sprint?