No se puede ser ágil si se prueba en cascada (aunque uses Scrum, iteraciones o Sprints)

Siempre que alguien me pregunta por su proyecto, por cómo llevan la agilidad, o que me dice que aplican gestión ágil porque utilizan sprints o iteraciones de 4 semanas, hay 3 o 4 preguntas y cosas básicas obligadas a mirar, una de ellas es… “cómo son las pruebas”.
Aunque a alguno os pueda sorprender, conocer cómo se desarrolla el ciclo de pruebas es uno de los mejores indicadores para conocer cómo de “sana” es esa gestión ágil.
En un porcentaje bastante amplio, lo que suelo encontrar y suele suceder es que las pruebas están y quedan fuera del equipo, son responsabilidad de otro departamento (departamento de desarrollo vs departamento de QA). Esto, claramente, indica que el equipo no es multifuncional (no contiene todas las competencias para de manera autónoma completar un requisito), cosa de la que requiere la gestión ágil (si no estás familiarizado con esto lee los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad)
Ello normalmente implica que hasta que el equipo de desarrollo no termina un prototipo este no va al departamento de pruebas para que se pruebe de verdad, por lo que las pruebas se realizan los últimos días del sprint o incluso después.
Y ello implica normalmente que para que el equipo de pruebas avance trabajo, haga cosas  mientras espera al prototipo, éste se dedique a escribir en papel (o Testlink, o lo que sea) los  casos de prueba, lo que implica que necesite para ello y lo antes posible algunas especificaciones (papel) de la funcionalidad que se supone tendrá el prototipo que los últimos días tiene que probar…
En resumen, trabajo en modo cascada cubierto bajo un manto ágil, una fase de pruebas monolítica justo al final del ciclo (cuando hay poco tiempo de reacción) y muchas veces necesitada de un documento de requisitos más o menos cerrado desde el principio.
En otro porcentaje también bastante amplio, aunque menor, lo que me encuentro es que el equipo si es más o menos multifuncional, la persona de pruebas no es de otro departamento, 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.
Pero no te confíes, no te conformes con ver solo con, aún puedes detenerte un poco más y enterarte de… ¿cuándo realmente se prueba? Y de nuevo ocurre que, aún siendo el equipo multifuncional, las pruebas se dejan para los últimos días. ¿Por qué? En este tipo de casos el problema suele venir de dos “amigos” que ya son un clásico: problemas con el control de versiones y/o problemas con los entornos de pruebas.
Si alguno de los anteriores no funciona bien, la gente de pruebas tendrá la versión real a probar muy tarde, volviendo a ser un cascada metido en sprints.
Recuerda, un verdadero ciclo ágil, aquel que persigue la máxima velocidad (acompañada de control y buenas prácticas) no presupone un ciclo en cascada dentro del sprint, se puede (debe) perfectamente, preparar un caso de test, implementar una historia de usuario, y acto seguido, por ejemplo la primera semana del sprint o cuando sea, hacer la prueba real.

6 comentarios en “No se puede ser ágil si se prueba en cascada (aunque uses Scrum, iteraciones o Sprints)”

  1. En mi opinión es errónea la línea de pensamiento.
    Sigue siendo un mini waterfall, no? Hasta que el desarrollador no acaba lo que se puede probar, no se puede probar. Sea al final del proyecto, al final del sprint, o al final del día.
    Y darle vueltas en que es malo agrupar el testing antes, en medio o después desde un punto de vista temporal, lo veo irrelevante.
    Lo que marca la diferencia entre Agile o no es que el concepto de Done incluya la obligación de que sea software que funciona y que sea potencialmente preparado para ser puesto en producción.
    No importa si haces sprint solo de pruebas, siempre que el equipo mantenga la flexibilidad máxima para abrazar el cambio.
    Yo no centraría los esfuerzos en empezar a testear lo antes posible, puede convertirse en algo muy frustrante cuando estamos en las primeras versiones de código, me centraría en que impacte lo menos posible en la capacidad de abrazar el cambio.
    Y allí miraría la madurez Agile del equipo.

    1. Obviamente no, ser ágil y hacer scrum, no significa hacer mini waterfalls, un waterfall dentro de un sprint es claramente un error.
      El modelo en cascada tiene etapas claramente definidas que están guiadas por entregables. Si hicieras un miniwaterfall estarías esperando analizar todas los elementos del product backlog, para luego pasarlos a diseño, codificación y pruebas. Obviamente esto tendría todos los problemas que tiene el modelo en cascada ligeramente mitigados al tener fijada una meta a corto plazo, pero igualmente no sería un desarrollo ágil.
      En un desarrollo ágil las etapas y el inicio del desarrollo de los elementos del product backlog se solapan, se puede empezar por las pruebas (por ejemplo haciendo TDD o BDD), pueden revisarse los requisitos en mitad del sprint (Customer collaboration over contract negotiation), el equipo es multifuncional y por lo tanto hay distintos puntos de vista y habilidades que permiten que se pueda realizar de inicio a fin una funcionalidad solicitada.
      Es algo contradictorio leer que lo que importa es tener software funcionando (con lo que estoy de acuerdo) y decir que no importa si tienes un sprint de testing. Tener un sprint de testing es claramente otro error. Tener un sprint de testing es haber entregado algo jugando con lo que en el desarrollo ágil no se puede jugar: la calidad. Un sprint de este tipo suele poner de manifiesto que se ha liberado código que no se debía, siendo los motivos diferentes no se ha protegido al equipo de la presión de los stakeholders, la DoD es pobre, en el elemento del product backlog no se definió claramente los criterios de aceptación o el responsable del producto la dio por buena cuando no debía. Además, de estar expuesto a una situación poco agradable, explicar a los stakeholders qué vas a hacer, por qué y dónde está su incremento funcional potencialmente usable.
      Definitivamente hacer Scrum, ser ágil no es sólo hacer iteraciones cortas.

  2. Buen inicio en tu artículo Javier, sin embargo tal como lo menciona Juan en su comentario, creo que al final si que te fuiste un poco al extremo. Personalmente creo más en la idea contraria, es decir primero hacemos las pruebas y luego codificamos (TDD). Y la verdad, creo que eso, amigo mío, no le quita lo ágil al desarrollo.
    No se trata de desarrolladores esperando recibir las pruebas para poder codificar. De lo que estamos hablando es que son ellos mismos quienes deben preparar las pruebas. Si quieres expresarlo al extremo, es decir: «el aspecto multifuncional no debe ser del equipo, sino de sus miembros». Uno de los pocos aspectos seriamente censurables de las metodologías ágiles. Su aversión a la especialización profesional y su propensión a que seamos «toderos».

    1. A ver, el problema no es probar después de desarrollar, el problema no es testear cuando quieras (de hecho, eso eso es lo deseable), el problema es que obligatoriamente las pruebas reales se tengan que hacer en el último momento porque el entorno, equipo, etc., no deja otra opción a ello. Es es el problema.
      No sé donde está el extremo del post, el post dice (o yo creí que se entendería así, pero parece que no) «prueba cuando puedas, cuando quieras y cuando lo necesites», no tienes que esperar al último día «cuando ya es tarde, y poco se puede hacer», más extremo me parece a mi «prueba solo los 4 últimos días porque no hay manera ni sabemos hacer que pruebes antes aunque podrías hacerlo desde hace 10 días», eso si que me parece extremo.
      Por otro lado, el tema multifuncional, que yo sepa, en agilidad nunca se ha dicho que aplique a los miembros, aplica al equipo.
      Saludos:-)

      1. Yo creo que a lo que se viene a referir Javier es que no debemos caer en el error que los procesos de trabajos impuestos por el equipo de desarrollo o una mal uso de las herramientas de control de versiones imposibiliten al equipo de QA probar tareas independientes y terminadas hasta que no se ha terminado el total de tareas impuestas para el Sprint.
        Es decir que por ejemplo si tenemos 10 tareas a realizar para este sprint sin relación entre si y trabajamos de tal manera que no se hace la integración hasta finalizar todas las tareas, el equipo de QA se verá obligado a esperar a la totalidad y realizar todas las pruebas juntas, cuando ya podrían haber estado realizadas con anterioridad. Con lo que ello implica si a última hora descubrimos problemas.

  3. Buenas tardes…Muchas gracias… En la empresa donde trabajo estamos iniciando con SCRUM, no obstante tengo la duda de como meter las pruebas de aceptación dentro de la iteración. En la experiencia pasada, esas pruebas se demoran demasiado, porque dependen de la disponibilidad del usuario final. Y en ese caso, quien es el encargado de acompañar al usuario final en la realización de la prueba. Muchas gracias

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba