La siguiente presentación formó parte de una exposición que dí ayer para la Universidad Nacional de Colombia, organizada y moderada por Albeiro Espinosa Bedoya.
Gracias a Dios (y a las comunicaciones) pudimos alcanzar el objetivo de tratar lo aspectos más importantes, generar un espacio para el debate permitiendo que los alumnos interactuaran con comentarios y preguntas, y sentirnos cómodos, que no es poco.
Nos reimos un poco y profundizamos un poco en cuanto a la situación del caso real planteado, la importancia de la comunicación, el tratamiento de la calidad por parte de todos los miembros del equipo ágil, la administración de la documentación, los roles y claro, la participación del Probador (Tester) en todo ésto.
Apliqué uno de los principios del agilismo (deja la comodidad de tu asiento y levántate) cuando les fui pidiendo a los alumnos que se acercaran al micrófono del frente ya que no contaban con micrófono inalámbrico….. jajaja, y formularan una pregunta o dejaran su comentario.
Eso estuvo bueno, permitió que los chicos se fueran relajando y nos sintiéramos más cómodos todos.
A continuación, les dejo parte de su contenido:
Planteo formulado dentro de un grupo de discusión
Generalidades
¿Qué tipo de actividades llevas a cabo bajo este modelo?
¿Qué ceremonias: Daily Scrum Meetings, Sprint Reviews, Retrospectives?
¿Participan con el Product Owner en la User Story?
¿Qué tratamiento le dan al Product Backlog y Sprint Backlog?
¿Participan del Sprint Planning?
¿Tienen un Scrum Master que lo elabora?
¿Estiman el esfuerzo de trabajo?
¿Qué documentan?
¿Elaboran Indicadores y Métricas?
Herramientas
¿Usan herramientas aranceladas? JIRA Agile, JIRA Bamboo, JIRA Zephyt, TFS
¿Usan herramientas open source? Redmine, Testlink, Mantis, Selenium WebDriver, Cucumber, SonarQube
Automatización
¿Ejecutan Automation Testing?
¿Bajo qué tipo de modelo: BDD y/o ATDD, pej?
¿Ejecutan Testing contra Código?
¿Ejecutan Testing contra Servicios?
¿Ejecutan Testing contra Front End?
¿Estiman, documentan, elaboran Indicadores y Métricas?
Planteo por parte de un miembro
En mi trabajo es difícil aún introducir los procesos de Testing en Scrum.
Acá se practica la metodología estrictamente, los sprint son de dos semanas y la documentación es casi nula (no existen los casos de uso, y los documentos de requerimientos son escasos), el tiempo para crear casos de prueba es muy poco por lo que decidimos solo crear los de regresión y dedicar mas tiempo a los Criterios de Aceptación (Definition of Done).
Utilizamos Jira pero no solo como bugtracker sino también como pizarra de Scrum donde se encuentran las Historias de Usuario (User Story) creadas entre todo el equipo de Scrum en el Sprint Planning.
Por el momento las estimaciones de los desarrolladores para bugfixing nunca alcanzaron, y la verificación de bugs de un Sprint se realizan en el próximo. Para nuevos proyectos vamos a probar con Sprints de 3 semanas: 2 de desarrollo, 1 de Testing y bugfixing, así los desarrolladores podrían liberar funcionalidades mas completas (y testeables), estimar mejor el tiempo de testing (somos abiertos al testing exploratorio) y quedaría tiempo para realizar bugfixing. La verificación de bugs seguiría quedando para el próximo sprint.
Devolución ofrecida
No están siendo ágiles.
Si están realizando el testing fuera de la sprint, no están entregando un producto de calidad.
La idea es entregar un incremento TERMINADO: diseñado, desarrollado, probado.
Lamentablemente, así funcionan muchos equipos actualmente.
Es necesario incorporar el Testing dentro de las iteraciones.
Respuesta por parte del mismo miembro
Realizamos una etapa de testing dentro de cada sprint (3 a 4 días).
Luego los desarrolladores realizan la corrección de errores y en general, la verificación de esos errores «solucionados» se hace en el siguiente sprint.
Luego hacemos la regresión de la corrección de errores para el sprint.
Los proyectos duran entre 2 y 5 meses (según la complejidad de la aplicación y los objetivos de calidad que exija el cliente)
Con respecto a la documentación, es complicado el asunto y esta casi cerrado en utilizar solo las Historias de Usuario (que siguen siendo básicas e insuficientes) y los Criterios de Aceptación ya que la duración de los proyectos es corta. Para mi es un dolor de cabeza diario.
Devolución ofrecida
Si están haciendo el testing por separado no están siendo ágiles.
La idea de trabajar ágilmente no es hacer lo mismo de antes en menos tiempo.
Ni que el incremento o entregable salga con defectos.
Tampoco es la idea no hacer nada de documentación.
Creo que no son ágiles… todavía.
A medida que avancen van a ir encontrando el camino.
Respuesta, nuevamente, por parte del miembro
Cómo se implementa el testing en las metodologías de desarrollo ágiles?
Específicamente, ¿En que difiere de lo ya expuesto? Teniendo en cuenta que no aplicamos TDD y que desde el primer sprint se realizan pruebas de unidad, integración sobre el código, y el ciclo de pruebas descrito anteriormente.
En cuanto a la documentación, para mi, como tester, es importante pero uno de los principios del desarrollo ágil es reducir la documentación a la que es absolutamente necesaria y en proyectos de 6 a 10 sprint la documentación que se puede generar realmente es poca.
Entonces si pudieses darme algún consejo acerca de que tipo de documentación puedo excluir o incluir en sprints que duran entre 2 y 3 semanas o como puedo mejorar los procesos de testing en Scrum estaría muy agradecido.
No comprendo como entendiste que intentamos hacer lo mismo en menos tiempo o que llegamos al final del sprint sin testing, Pero por si no me explique bien, eso no sucede. Ya lo había aclarado antes.
Devolución ofrecida
1. Está generalizada la idea errónea de reducir la documentación, de hecho, NO es un principio de desarrollo ágil (podés buscar manifiesto ágil en wikipedia y también da los principios). Puede que suceden dos cosas: no hay buena comunicación en el equipo, entre devs, testers y clientes; o falta documentación necesaria. En ambos se soluciona comunicando y poniéndose de acuerdo sobre cómo trabajar mejor, qué pueden mejorar y qué necesitan, en las retrospectivas. ¿Las están haciendo en cada final de sprint?
2. Mencioné que posiblemente estaban haciendo lo mismo que antes en menor escala, porque leí que están teniendo una sprint con los primeros días de desarrollo, y luego se hace el testing (corregime si no es así). Acá les puede ayudar la integración continua, o tener builds más seguidas para ir probando las historias que se fueron cerrando, no cerrar todo y luego hacer el testing completo. Así, mientras van encontrando defectos los van fixeando,
Testing en Scrum
Participación temprana del equipo de Testing.
Interacción fluida entre todos los miembros del equipo Flexibilidad en el proyecto.
Transparencia y visibilidad del los objetivos a cumplir.
Gran dinamismo en el proyecto.
Compromiso y responsabilidad en el equipo.
Foco en desarrollar/testear lo prometido.
¿Tienes alguna sugerencia para hacer?
¿Qué le agregarías a la presentación?
Envíame tu comentario a: gustavo@testingbaires.com
