TESTING EN SCRUM JOHN DONATO

Vista previa del material en texto

QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
 
 
Por Romina Gioacchini, Test Lead – SOGETI 
Septiembre 2011 
 
Introducción a SCRUM e Integración con Procesos de Testing 
SCRUM es un Framework y como tal no propone prácticas técnicas especificas para 
desarrollar o probar. Al decidir gestionar proyectos mediante esta metodología ágil, 
se deberá tener en cuenta la definición de procedimientos de desarrollo y testing 
dentro de este marco. 
El propósito de este documento es explicar las principales características de SCRUM 
como metodología ágil y proponer mejores prácticas y procedimientos para su 
integración con procesos de Testing. 
 
1. Introducción a SCRUM 
En la actualidad la mayoría de los proyectos informáticos poseen una planificación 
al inicio de los mismos que poco tiene que ver con la realidad del día a día: 
• Los requerimientos no son completamente comprendidos y analizados antes 
que un proyecto comience, 
• Los usuarios/clientes solo comprenden lo que necesitan una vez que 
visualizan una versión inicial del software, 
• Los requerimientos cambian a menudo durante el proceso de construcción 
de software, 
• Las nuevas herramientas y tecnologías provocan que las estrategias de 
implementación sean impredecibles. 
 
SCRUM permite de forma rápida y repetidamente inspeccionar el software que se 
está construyendo (cada dos semana a un mes) permitiendo al negocio establecer 
las prioridades y ayudando a los equipos a focalizarse en desarrollar el más alto 
valor de negocio en el menor tiempo. 
Los equipos se gestionan a sí mismos para determinar la mejor manera de entregar 
las características de mayor prioridad. 
Cada dos semanas a un mes se puede ver software real y decidir si éste es el 
software que se desea en producción o continuar y mejorar el mismo en una 
próxima iteración. 
A continuación se enumeran algunas características de SCRUM: 
• Equipos gestionados por sí mismos 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
• El producto progresa en series de 2 a 4 semanas llamadas sprints 
• Los requerimientos son capturados como ítems de una lista llamada Product 
Backlog 
• No especifica ninguna practica o técnica de ingeniería (Framework) 
• Utiliza reglas especificas para crear un ambiente ágil 
• Es uno de los “procesos ágiles” más conocidos 
 
1.1 Agile Manifesto 
Dentro de las metodologías agiles existe el “Agile Manifesto” que prioriza: 
� Individuos y sus interacciones sobre las herramientas y los procesos. 
� Construir software sobre documentación “completa”. 
� La colaboración con el cliente sobre la negociación de contrato. 
� Responder ante el cambio sobre el seguimiento del plan. 
 
1.2 El Proceso 
El proceso a seguir dentro de SCRUM corresponde a una serie de iteraciones 
denominadas sprints en las cuales se construye el producto de acuerdo a los 
requerimientos existentes en el Product Backlog. 
Al finalizar cada sprint, se debe poder mostrar a los interesados, el producto 
construido hasta al momento. Ya sea en el sprint 1 (prototipo) o en el sprint N, los 
involucrados en el proyecto deben poder tomar decisiones sobre el progreso del 
mismo luego de una real demostración por parte de quienes lo construyen. 
Por lo anterior, los requerimientos listados en el Product Backlog serán dinámicos 
ya que pueden cambiar y/o tener más o menos prioridad cada vez que se 
incrementa la funcionalidad del producto. 
 
 
 
 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
1.2.3 Sprints 
Los proyectos gestionados mediante SCRUM progresan en una serie de sprints. Los 
sprints son periodos de tiempos de una duración estándar de un mes +/- 1 o 2 
semanas. Una duración constante permitirá un mejor ritmo de trabajo. 
Durante los sprints el producto es diseñado, codificado y testeado. Para cada sprint 
se planifica la construcción de determinados ítems del Product Backlog. Esta 
planificación debe tener en cuenta que durante el sprint no debe haber 
cambios en la funcionalidad que se decidió incluir en el mismo: la planificación de 
la duración de los sprints debe realizarse teniendo en cuenta el tiempo durante el 
cual se puede mantener el compromiso de conservar los cambios fuera del sprint. 
 
 
 
1.2.4 Release Sprint 
Durante Release Sprint el Scrum Team prepara el producto para su puesta en 
producción teniendo en cuenta que clientes “beta”, usuarios o similares deberán 
poder utilizar y/o aprobar el producto luego de este sprint. 
 
 
Este término no es parte del estándar de SCRUM, sólo se trata de una práctica 
dentro del procedimiento que encuentro útil. 
 
1.3 SCRUM Framework 
SCRUM es un simple Framework de “inspección y adaptación” que posee 
� 3 Roles: Product Owner, Scrum Master, Scrum Team; 
 
� 3 Ceremonias: Sprint Planning, Sprint Review & Retrospective, Daily Scrum 
Meeting; 
 
� 3 Artefactos: Product Backlog, Sprint Backlog, and Burndown Chart. 
 
 
 
 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
1.3.1 Roles 
 Product Owner: Es quien define las características del producto, decide 
sobre la fecha y contenido del producto “release” y prioriza las características según 
las necesidades del negocio. 
Representa los intereses del cliente por lo que es el responsable de poner los 
requerimientos en términos claros. 
Dentro del proceso de SCRUM es quien ajusta las características y prioridades de 
los requerimientos listados en el Product Backlog en cada iteración, de acuerdo a 
las necesidades del momento, y puede aceptar o rechazar el resultado obtenido en 
cada sprint. 
 
 Scrum Master: Es el representante de la gestión del equipo hacia el 
proyecto. 
Ayuda al equipo a avanzar en la dirección en la que ellos decidieron ir asegurando 
en cada momento el cumplimiento de los valores y prácticas de SCRUM. 
Remueve los impedimentos que afecten cualquier tarea definida para el sprint en 
curso focalizando al equipo en el objetivo a cumplir (sprint goal) y protegiéndolo de 
las interferencias externas. 
Asegura que el equipo sea completamente funcional y productivo permitiendo una 
fuerte cooperación a través de todos lodos los roles y funciones. 
 
 Scrum Team: Los equipos deben organizarse a sí mismos y ser multi-
disciplinarios: Arquitectos, Desarrolladores, Analistas Funcionales, Diseñadores y 
Testers. 
Deben tener la capacidad de seleccionan el sprint goal y especificar los resultados 
obtenidos. Tienen derecho a realizar lo que sea necesario, dentro de los 
lineamientos del proyecto, para alcanzar el sprint goal. 
 Características: 
- Equipos de entre 5 y 10 personas, 
- Miembros a tiempo completo (aunque puede haber excepciones), 
- Los miembros pueden intercambiarse sólo entre sprints. 
 
1.3.2 Ceremonias 
 Sprint Planning Meeting: Se lleva a cabo al inicio del sprint y su duración 
es de 8 horas (máximo). 
 Se divide en dos partes. En la primera se define el alcance del sprint 
definiendo el sprint goal, en la segunda se definen las tareas para el sprint que se 
reflejan en el Sprint Backlog, detallando el tiempo que tomará realizar cada tarea. 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
 
 
 Daily Scrum Meetings: 
 Parámetros: 
- Reunión diaria, 
- Duración: 15 minutos, 
- No se trata de una reunión para resolver problemas, 
- Se la conoce también como “Daily Stand Up”: debe realizarse de pie para 
respetar la duración de la misma y para que se desarrollen únicamente 
las 3 preguntas indicadas a continuación. 
3 Respuestas: 
- ¿Qué hiciste ayer? 
- ¿Qué harás mañana? 
- ¿Qué impedimentos hay en tus tareas? 
 Roles: Haciendo alusión al artículo: The Chicken and the Pig 
Varios roles se definen en SCRUM. Todos los roles caen en dos diferentes grupos: 
“cerdos” y “gallinas”, basados en el grado de implicancia en el proyecto. Los 
nombres de los grupos provienen de una broma sobre un cerdo y una gallina que 
iban a abrir un restaurante: 
 “Un cerdoy una gallina van caminando por la calle cuando la gallina mira al 
cerdo y dice: ¿Por qué no abrimos un restaurante? El cerdo mira a la gallina y dice: 
“Buena idea, ¿qué nombre le ponemos?” La gallina piensa y dice: ¿Qué te parece 
`Jamón y Huevos´? El cerdo comenta: “No me parece, yo estaría comprometido y 
tu solo estarías involucrado.” 
Por lo cual, los “cerdos” son quienes están comprometidos con el proyecto, 
cualquier otra persona es una “gallina”: interesados en el proyecto pero 
indiferentes, si el proyecto falla, no son ellos los que se comprometieron en la 
realización del mismo. 
 Por lo anterior, se definen los asistentes a la Daily Scrum Meetings de este 
modo: “gallinas” y “cerdos” son invitados, para evitar otras reuniones innecesarias, 
pero solo los “cerdos” pueden hablar. 
¿Por qué es una reunión diaria? 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
 “¿Cómo puede un proyecto resultar un año retrasado? 
 Un día a la vez.” 
Fred Brooks, The Mythical Man-Month. 
 
¿Se pueden reemplazar estas reuniones por reportes de estado enviados por 
mail? No: 
o El equipo entero visualiza el estado del sprint cada día, 
o Crea presión de pares y compromiso en hacer lo que has dicho que 
harás. 
 
 Sprint Review & Sprint Retrospective: Al final del ciclo sprint, dos 
reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la 
“Retrospectiva del Sprint”. 
Sprint Review Meeting: 
- Los equipos presentan lo que realizaron durante el sprint, 
- Típicamente tiene la forma de una Demo, 
- Informal: 2 horas de preparación es la regla, 
- Participantes: Clientes, Gerentes, Product Owner, Otros Ingenieros. 
Sprint Retrospective Meeting: 
- Sólo se reúne el Scrum Team, 
- Es una reunión para obtener feedback 
- Cada miembro del equipo presenta su visión sobre: 
o Qué estuvo OK / qué estuvo KO, 
o Qué puede ser mejorado, 
o Cómo implementar las mejoras. 
 
1.3.3 Artefactos 
 Product Backlog: Es la lista de todo el trabajo que se desea realizar en el 
proyecto. Esta lista es priorizada por el Product Owner y puede ser actualizada y 
revisada cuando sea necesario. 
 Sprint Backlog: El Scrum Team decide que tareas son necesarias para 
alcanzar el sprint goal. Estas tareas se denominan Sprint Backlog Items: 
subconjunto de requerimientos del Product Backlog que se implementarán durante 
el sprint. 
 El Sprint Backlog puede cambiar durante el sprint: 
- El equipo puede agregar nuevas tareas cuando sea necesario con el 
objetivo de alcanzar el sprint goal, 
- El equipo puede eliminar tareas innecesarias, 
- Pero: el Sprint Backlog sólo puede ser actualizado por el Scrum Team 
 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
 Burndown Chart: Es un gráfico que mide la cantidad de requisitos en el 
Backlog del proyecto pendientes al comienzo de cada sprint. Dibujando una línea 
que conecte los puntos de todos los sprints completados, podremos ver el progreso 
del proyecto. 
 De la misma manera podemos tener un Sprint Burndown Chart para medir el 
progreso del Sprint Backlog. 
 
 Ejemplo de Sprint Burndown Chart extraído de la herramienta ScrumWorks. 
 
1.4 Escalabilidad de SCRUM: Scrum of Scrums Meeting 
La Scrum of Scrums Meeting es una técnica importante cuando se trata de grandes 
proyectos. Si tenemos un número considerado de Scrum Teams es necesario llevar 
a cabo una serie de reuniones para focalizarse más que nada en temas de: 
integración, superposición de tareas y testing. 
Se debe elegir el miembro más “optimo” del equipo para asistir a esta reunión 
según el tema que se quiera tratar (arquitectura, testing, etc.). 
De ser necesario, se recomienda que asista más de una persona por Scrum Team si 
el número de asistentes totales a la Scrum of Scrums Meeting es menor que 8. 
En el caso de grandes proyectos, podemos escalar la Scrum of Scrums Meeting 
hacia arriba de un modo recursivo: en un nivel más alto tendremos una “Scrum of 
Scrum of Scrums Meeting”, que obviamente no es usual llamarla de este modo, 
Scrum of Scrums generalmente basta para identificar estas reuniones en niveles 
más altos. 
 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
La frecuencia de estas reuniones podría ser diaria como la Daily Stand Up Meeting y 
de una duración de 15 minutos, pero algunas experiencias recomiendan que sean 
más espaciadas en el tiempo alargando a 30 minutos su duración. 
Agenda: a continuación se refleja una típica agenda para la Scrum of Scrums 
Meeting: 
 
Como se observa, aquí hablamos de equipos y no de personas por lo que se 
agregan 2 preguntas a la habitual Daily Stand Up Meeting. En esta reunión sí 
podemos asignar tiempo para la resolución de problemas. 
 
2. Integración con Procesos de Testing 
 
2.1 Principales diferencias con las prácticas de testing en metodologías 
tradicionales 
 
2.1.1 Organización de los Scrum Teams 
Uno de los dilemas principales a la hora de planificar los procesos de pruebas es 
cómo organizar los Scrum Teams de forma que se cumplan las prácticas de testing 
tradicionales. 
Desde mi punto de vista existen 2 opciones para organizar equipos: 
1. Los testers forman parte del Scrum Team: En cada sprint se desarrolla y se 
prueba la funcionalidad establecida para cumplir el sprint goal, por lo cual, 
existirá un grupo de testers dentro del equipo que prepare, especifique y 
ejecute los tests necesarios. Las desventajas de esta opción: el Tester está 
muy involucrado con los desarrolladores y esto puede afectar transparencia 
en las pruebas; testers y desarrolladores pueden intercambiar roles entre 
sprints, e incluso durante el sprint en curso con el objetivo fundamental de 
cumplir con el sprint goal y claro está que esta práctica no se alinea a las 
mejores prácticas de testing. 
El Test Manager tendrá que gestionar a los testers de los diferentes Scrum 
Teams y sus tareas teniendo en cuenta la variabilidad de los recursos de los 
que dispone, esta figura queda relegada y con poco poder de decisión al 
seleccionar esta opción. Se deberá entonces poner énfasis y aumentar la 
frecuencia de las Scrum of Scrums Meetings dedicadas al Testing, para 
coordinar tareas, procedimientos, etc. en conjunto con el Test Manager. 
 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
2. Existe un Scrum Team dedicado a actividades de QC: es un equipo separado 
de los de desarrollo, dedicado a la realización de pruebas: esta opción es 
válida desde el punto de vista de las mejores prácticas de Testing, pero 
debemos tener en cuenta algunos problemas que pueden surgir: 
 
a. Disponibilidad del software: de existir integración entre desarrollos de 
diferentes Scrum Teams, se deben coordinar los ciclos de Test de 
manera de disponer del software a integrar en tiempo y versión de 
cada uno de los equipos de desarrollo involucrados. 
b. Las pruebas deben ser planificadas dentro de cada sprint y deben 
mostrar resultados en la Demo de fin de sprint: debe quedar claro 
qué es exactamente lo que el Product Owner espera que este equipo 
muestre como resultado del sprint. 
A este equipo separado y dedicado a QC se lo puede ver como un “Scrum of 
Scrum Team”: este término no existe dentro del Framework de Scrum, pero 
me parece útil para entender las características de este equipo. 
De acuerdo a mi experiencia, el mejor de los casos sería tener una combinación de 
ambas opciones: Scrum Teams de desarrollo que incluyan testers “internos” (con 
perfiles más técnicos) y uno o más Scrum Teams dedicados a QC que reciban el 
producto probado (pruebas unitarias y de sistema genéricas) al finalizar cada sprint 
de desarrollo y, que en sus propios sprints, se dediquen a pruebas más 
relacionadas con Integración, Aceptación y pruebas de Sistema detalladas. 
 
2.1.2 Documentación 
No existe una especificación “formal” de toda la aplicación a probar, las 
metodologías agiles priorizan la construcción del software antesque tener una 
documentación “completa”. La información disponible estará especificada como 
Product Backlog y Spring Backlog Items. 
 
2.1.3 Casos de prueba “Agiles” 
Los casos de prueba especificados deberán ser “agiles” ya que se extraerán de 
“documentación ágil”: 
- Los testers deben ser capaces de ejecutar casos de prueba con solo leer 
su titulo, 
- La funcionalidad tiene un alcance temporal por lo que los casos de 
prueba deben ser también “temporales”. 
 
 
 
 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
2.2 El rol del Tester 
 
2.2.1 Sprint Planning Meeting 
Durante esta reunión el Tester realiza preguntas y comenta sobre los ítems del 
Spring Backlog que serán incluidos en el sprint para definir el alcance de la 
funcionalidad a ser probada y dar una primera estimación de pruebas. Luego 
deberá definir las tareas de testing que serán incluidas en el Spring Backlog. 
2.2.2 Durante el Sprint 
Provee la conciencia de calidad en el equipo. Es responsable de comunicar los 
riesgos que se van detectando durante las pruebas para medir junto al resto del 
equipo la calidad del producto que se está construyendo. 
2.2.3 Review Meeting 
Da visibilidad al equipo sobre los posibles resultados de esta reunión y define el 
“camino feliz” que se utilizará durante la presentación, que usualmente conduce. 
2.2.4 Retrospective Meeting 
Aporta con su visión sobre la calidad del producto entregado y el proceso de 
desarrollo en general, y presenta sus conclusiones sobre el proceso de pruebas, 
indicando posibles mejoras al mismo. 
 
2.3 Estrategia de Pruebas 
A continuación se detallan algunos puntos a tener en cuentan al implementar la 
estrategia de pruebas: 
• Niveles de Pruebas: La influencia de SCRUM en el modelo en V se basa 
principalmente en la que podría tener cualquier metodología ágil. Es decir, al 
definir los niveles de pruebas, se deberán tener en cuenta los principios que 
caracterizan a las metodologías ágiles (Ver apartado 1.1 de este documento 
“Agile Manifesto”). 
 
• Casos de prueba: No existe una especificación “formal” de toda la aplicación. 
La información disponible esta especificada como Product Backlog y Sprint 
Backlog Items. 
QA:newsQA:newsQA:newsQA:news –––– N6 N6 N6 N6 
SCRUM también define el uso de Epics, User Stories y Acceptance Cases. Una 
definición genérica de los mismos podría ser: 
 
o Epic: Definición de alto nivel de una funcionalidad. 
o User Story: Pieza de funcionalidad que representa un valor para el 
Product Owner. 
o Acceptance Case: Definición de las condiciones que debe cumplir la 
user story. 
 
Una técnica válida podría ser la agrupación de casos de prueba por User Story 
basándose en los Acceptance Cases (teniendo en cuenta que no siempre 
estarán especificados los Acceptance Cases). 
 
 
• Automatización: La automatización es la clave dentro de las metodologías 
agiles. Pero deberá tenerse en cuenta el coste del mantenimiento de estos 
scripts debido a la temporalidad de las funcionalidades. 
 
• Pruebas de Regresión: Deberán seleccionarse test de regresión que den 
cobertura pero que puedan ser ejecutados en periodos cortos de tiempo, dentro 
de cada sprint. 
 
• Testers: Los testers dentro de cada Scrum Team tendrán un perfil más técnico. 
Participarán en la definición de los unit tests y deberán ser capaces de 
automatizar pruebas. 
 
 
 
3. Links 
 
http://agilealliance.org -> The Agile Alliance site. 
http://scrumalliance.org -> The Scrum Alliance site. 
http://agilemanifesto.org & http://agilemanifesto.org/principles.html -> The Agile 
Manifesto and Agile Principles.