Scrum Master Avanzado
Clase 2
Ricardo Araya Gautier
CEO
[email protected]+56 9 690 948 65
Equipos de apoyo
Son equipos que complementan la ejecución del proyecto para los
desarrolladores
• UX
Opciones:
• UI
• Qué estén dentro del equipo scrum, por lo tanto participan activamente en
• Arquitectura
la ejecución, esto es lo ideal
• Testing
• En el caso que no sean parte del equipo, se sugiere que participen en las
•…
reuniones diarias para que sepan cuando tendrán que hacer alguna tarea
para el desarrollo.
• En caso que no participen, el Scrum Master debe coordinar lo más
anticipado posible con ellos el trabajo que tendrán que realizar
Testing agil
Ricardo Araya Gautier
CEO
[email protected]+56 9 690 948 65
Fundamentos de la calidad de Software
¿Qué es Calidad?
Para la ISO 8402 (Interna onal Standard Organiza on), de ne La Calidad como: "El
conjunto de caracterís cas de una en dad que le con eren la ap tud para
sa sfacer las necesidades establecidas e implícitas”
En la ISO 9000:2000 se la de ne como “Grado en el que un conjunto de
caracterís cas inherentes cumple con los requisitos”
ti
ti
ti
ti
fi
ti
ti
fi
fi
ti
Fundamentos de la calidad de Software
La calidad de Software es:
Según R. Pressman: “La calidad del so ware se de ne como la
concordancia con los requisitos funcionales y de rendimiento
explícitamente establecidos, con los estándares y procesos de desarrollo
explícitamente documentados y con las caracterís cas implícitas que se
espera de todo so ware desarrollado profesionalmente”.
ft
ft
ti
fi
Procesos de Testing - Waterfall (cascada)
Análisis
Diseño
Desarrollo
Testing
Arreglos
Producción
Procesos de Testing - Waterfall (cascada)
Este es el proceso es el que se conoce de manera ortodoxa o tradicional, donde al terminar la
fase de codi cación pasa a QA para realizar las comprobaciones, luego de esto viene el
proceso de estabilización o bug xing.
Riesgos:
• Si el desarrollo se demora, el tiempo para revisar disminuye lo que implica una menor
calidad en la entrega del software.
• Existen tiempos muertos cuando el equipo de desarrollo termina de codi car y testing tarda
en comenzar su trabajo, lo mismo puede ocurrir al equipo de desarrollo al tomar la etapa de
estabilización.
• El equipo de desarrollo no se hace responsable por el testing y viceversa.
fi
fi
fi
Procesos de Testing - Pair Programming (programación en pareja
El Pair Programming consiste en que 2 programadores en
conjunto realicen el desarrollo del software, uno realiza la
codi cación mientras el otro va revisando lo que se esta
haciendo.
En esta forma de trabajar se requiere de un per l de QA
mucho más técnico ya que participa también en el
desarrollo.
fi
fi
Procesos de Testing - Pair Programming (programación en pareja
• El driver o controlador es el programador encargado de
• El navigator o navegador es la persona encargada
escribir el código y determinar qué funciones, variables
de revisar el código y guiar a su compañero
y algoritmos utilizarán para avanzar en el proyecto.
ofreciendo sugerencias y soluciones a medida que la
Además, es importante que verbalice y comparta su
tarea avanza y surgen nuevos desafíos.
proceso lógico mientras codea.
•
Lo recomendable es que tanto driver como navigator intercambien roles cada aproximadamente 30 minutos.
Pair Programming - Ventajas
Aprender explicando. Tal vez una de las razones principales para que Aprender de un par. Cuando realizas Pair
practiques esta técnica Programming junto a un compañero, y te explican
un challenge a resolver, también recibes información de una
forma que tal vez el instructor no lo hizo, y lo entiendes
mejor.
Code Review en vivo. Al codear de a dos, y si funcionas
como driver tienes la ventaja de revisar tu propio código en vivo y
Liderazgo. Esta metodología y el cambio de roles que
adelantarte a que posibles errores no lleguen a producción.
propone es una muy buena oportunidad para poner en
práctica habilidades de liderazgo y mentoreo.
Aprender de la diferencia. Una de las experiencias más Skills colaborativas. Codear en pareja es una gran
maravillosas que nos regala el Pair Programming es la oportunidad para ejercitar estas habilidades blandas tan
posibilidad de cruzar personas con distintos niveles de signi cativas en la industria tech como la colaboración, el
conocimiento, o incluso especialidades. trabajo en equipo y la comunicación.
Nuevos puntos de vista. Muchas veces no hay una única solución a los
problemas que se nos plantean cuando codeamos.
fi
Procesos de Testing - Pair Programming (programación en pareja
Difícil comienzo. Es muy costoso empezar a trabajar con esta técnica de Alta concentración, El rol del copiloto es una pieza clave en la ruptura del ujo de trabajo, es
programación por primera vez, ya que, al principio, cuesta ver los bene cios de la muy importante que esté siempre concentrado en lo que hace su compañero y en el aporte de
metodología. Se necesita una mentalidad y actitud abierta. ideas, ya que su distracción puede arrastrar fácilmente al compañero y llevar al equipo a la
pérdida de tiempo.
Problemas de a nidad, Esta técnica de trabajo también puede generar frustración debido a la
Frustración o fatiga. El Pair Programming, cuando se hace correctamente genera falta de a nidad con el compañero, ya que dependiendo del emparejamiento y personalidad de
mucho cansancio, ya que los descansos o las pausas que te puedan surgir cuando los pares puede degenerar en un pair improductivo por las potenciales discusiones (en el buen
miras el correo, por ejemplo, no tienen cabida. Pero tener a alguien viendo tu misma sentido) y la consecuencia sea una baja producción.
pantalla hace que intentes ser productivo constantemente.
¿Improductividad?, Dos personas trabajando en un mismo ordenador, implica Pereza, Uno de los problemas que se puede dar es la creación de personas perezosas que
menos código del que harían por separado (obviamente la calidad es tan alta que dejan todo el peso en el compañero limitándose a mirar. A pesar de que son casos aislados, no
merece la pena). sería objetivo pasarlos por alto.
Frustración inicial, Hasta que no encontramos el ritmo de pareja, podemos vernos sumidos en
Desequilibrio, Se da especialmente en proyectos muy grandes que experimentan un
una sensación ingrata de frustración ya que no producimos al mismo ritmo
crecimiento demasiado rápido. Este crecimiento supone una inclusión de nuevos
Aparente aumento de costes: Donde antes había un recurso (programador) para una tarea,
desarrolladores a un paso acelerado, y trae consigo una consecuencia, y es que se
ahora hay dos… no en mi proyecto!
crean parejas muy descompensadas con un integrante muy junior o con poco
conocimiento del proyecto, y otro muy senior que tiene que hacer frente a muchas
responsabilidades.
fi
fi
fi
fl
Procesos de Testing - Cross Testing
• Esta forma de realizar la revisión se debe trabajar en base a la revisión cruzada del
código, en el cual un desarrollador revisa el trabajo del otro, ya que si el mismo
programador revisa su propio trabajo, lo más probable es que ocurra es que revise
bajo las mismas condiciones cuando creó el código.
Procesos de Testing - Ciclo 2 sprint (estilo cascada)
• Durante el primer sprint el equipo de desarrollo realiza el código, y el equipo de QA crea el plan de pruebas.
• En el segundo sprint el equipo realiza el testing al código creado en el primer sprint y crea el plan de pruebas del segundo
sprint, además el equipo realiza la estabilización del código y crea el código correspondiente al segundo sprint.
• Esta forma no es aconsejada, ya que cada sprint debe tener una entrega probada y funcional en cada uno de los sprint.
• Esta estrategia se utiliza cuando las áreas de desarrollo y QA no trabajan de manera conjunta, lo cual no es aconsejable para
trabajar con Scrum.
Procesos de Testing - Un sprint
• Un sprint es similar a utilizar cascada pero dentro de un sprint.
• Una falencia que tiene este enfoque es que el tester esta sin hacer nada mientras el equipo de desarrollo esta creando el código.
• El equipo podría incorporar menos funcionalidades dentro del sprint, lo que implicaría que el equipo al nalizar los últimos días no podrían
desarrollar otros requerimientos del backlog.
• Podrían tomar nuevas funcionalidades con el n de aprovechar el tiempo pudiendo realizar las tareas según el siguiente esquema:
fi
fi
Procesos de Testing - Enfoque ágil
• Una forma de mejorar la incorporación de testing es tomar funcionalidad más pequeñas de código
que se vayan pasando rápidamente a los testers. Para esto se debe hacer un buen re namiento
previo.
• Esto es algo complejo ya que pueden existir algunas tareas que no sean tan rápidas de desarrollar y
por lo tanto genere tiempos muertos.
• Así mismo los primeros días cuando el equipo de desarrollo esta creando la primera pieza de software
no exista nada que revisar por los testers, así mismo ocurre al nalizar el sprint, donde los
desarrolladores estarán estabilizando el código o arreglando los bugs encontrados por los testers.
fi
fi
Procesos de Testing - Carry Over
• Con el n de mejorar los tiempos de ambos roles y maximizar el trabajo dentro de un sprint si no se alcanza a
terminar un requerimiento, este pasa al siguiente sprint, al quedar solo el testing, los tiempos para nalizar ese
requerimiento se vuelve a estimar.
• Esta forma de trabajar impacta al objetivo del sprint, ya que no se cumpliría al 100%, ya que lo no terminado
pasa al siguiente sprint. Además si QA encuentra mas bugs de los esperados se pone en riesgo el sprint es el
siguiente.
fi
fi
Procesos de Testing - Automatización Casos de Prueba
• Los problemas anteriores se solucionan con la automatización de los casos de prueba. Mientras el desarrollador crea la
funcionalidad el tester puede estar creando el código de las runas automatizadas.
• Al automatizar las pruebas se gana mucho tiempo e incluso se pueden reutilizar las veces que se requiera, incluso el mismo
desarrollador puede hacerlo.
• Es en esto cuando las técnicas como TDD, ATDD comienzan a aplicarse, así como también el sentido de responsabilidad
compartida por el cumplimiento del objetivo del sprint.
• Para lograr esto se requiere un equipo maduro, la complejidad puede se elevada si la tecnología utilizada es compleja o poco
conocida y el test automatizado no reemplaza en un 100% el testing manual.
Dinámica
Seleccionar un proyecto que estén trabajando y responder:
• ¿Qué estrategia están ocupando hoy?.
• ¿Cuál creen que es la estrategia que se debería tener?.
• ¿Qué necesitan para aplicar esta estrategia?.
Testing dentro de Scrum 19
Estrictamente QA no es parte de los
Actualmente qa al final del sprint
desarrolladores, ellos mismos deben
hacer QA.
QA debe ser parte del QA aporta la visión del PO y
equipo de desarrollo cliente
Si QA no alcanza a testear, es
Traspasa la
culpa de todo el equipo de
información del PO
desarrollo
como pruebas
Planificación Testing - Plan de Pruebas
El Plan de Testing constituye una plani cación de la realización de las pruebas a realizar sobre un proyecto o entrega, en el que se establecen
las fechas previstas de comienzo y n de las tareas de veri cación y revisión previstas.
Analizar los requerimientos de desarrollo de software
Para elaborar un plan de pruebas de software lo primero que debes hacer es entender los requerimientos de usuario que componen la iteración o proyecto, que son el sujeto de la veri cación de calidad
que se va a realizar.
Deberás analizar toda la información de la ingeniería de requisitos, especi caciones y diseño funcional, requisitos no funcionales, casos de uso, historias de usuario (si estás trabajando con metodologías
ágiles), entre otra documentación.
También es muy importante realizar entrevistas con el equipo encargado de la ingeniería de requisitos para aclarar dudas y ampliar la información que sea necesaria.
Identi car las funcionalidades nuevas a probar
A partir de la documentación del análisis de requisitos y de las entrevistas con el equipo de ingeniería de requisito y desarrollo, debes identi car e incluir en el plan de pruebas de software en la lista de
las funcionalidades.
En el caso de desarrollos de software integrados a un sistema existente es necesario revisar con los analistas de negocio y también con los arquitectos de software las funcionalidades que forman parte
del desarrollo de software, en todas las capas de la arquitectura.
Identi car las funcionalidades de sistemas existentes que deben probarse
Se debe identi car las funcionalidades existentes que estén siendo impactadas por el desarrollo de alguna forma, considerando todos los componentes afectados en todas las capas de la arquitectura de
software.
Existen dos situaciones que se puede encontrar al identi car estas funcionalidades:
• Funcionalidades modi cadas de cara al usuario: Por ejemplo, si una funcionalidad está siendo modi cada agregando mas pantallas o cambios a su ujo de proceso, debe ser incluida en el plan de
pruebas de software.
• Funcionalidades modi cadas en sus componentes internos: Son funcionalidades no modi cadas de cara al usuario, manteniendo la misma interfaz grá ca y ujo de procesos, sin embargo, si se
modi can componentes internos que comparten con otras funcionalidades del sistema, en las capas de lógica de negocio o acceso a datos. Estas deben incluirse en el plan de pruebas de software
para determinar a partir de ellas pruebas de regresión a realizar.
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
fi
fl
fi
Planificación Testing - Plan de Pruebas
De nir la estrategia de pruebas
Consiste en seleccionar cuáles son los tipos de pruebas de software que se deben realizar.
De nir os criterios de inicio, aceptación y suspensión de pruebas
Criterios de aceptación o rechazo:
Para de nir los criterios de aceptación o rechazo, es necesario de nir el nivel de tolerancia a fallos de calidad. Si la tolerancia a fallos es muy baja puede de nirse como criterio de aceptación que el
100% de los casos de prueba estén sin incidencias. Lograr este margen en todos los casos de prueba principales y casos bordes será muy difícil, y podría comprometer los plazos del proyecto
(incrementa los riesgos), pero asegura la calidad del producto.
Una vez logradas las condiciones, se darán por aceptadas las pruebas y el desarrollo de software.
Criterios de inicio o reanudación:
De nen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas. Por ejemplo, en el caso de inicio la condición podría ser la instalación de los componentes de software en el
ambiente y que los casos de pruebas de veri cación de ambiente sean exitosos.
Para el caso de la reanudación las condiciones están relacionadas, se determina a partir de cuales criterios de suspensión se presentaron para detener las pruebas. Una vez que estás condiciones ya
no existan (sean solventadas) se procede con la reanudación.
Criterios de suspensión:
Las condiciones van a depender de los acuerdos de nivel de servicio (SLAs) internos de la organización y también de los acuerdos establecidos en cada proyecto individual.
Por ejemplo, si se tiene un equipo de pruebas que comparte su esfuerzo entre varios proyectos, se puede de nir un criterio de suspensión exigente, un determinado porcentaje de casos fallidos que
resulten en incidencias. Si la condición se cumple, se detienen las pruebas y se dedica el personal a otras actividades,
Por otra parte, si se tiene un equipo de pruebas con personal dedicado, el criterio de suspensión puede ser poco exigente, por ejemplo solo ocurriendo si se bloquean por incidencia todos los casos de
prueba.
fi
fi
fi
fi
fi
fi
fi
fi
Planificación Testing
Plan de Pruebas - elaboración
• Objetivo, se debe de nir el objetivo de las pruebas, por ejemplo: En el proyecto de Integración del sistema Cotizaciones con
el sistema de ventas tenga la información concordante entre ambos sistemas, en cuanto a valores de cotización sea igual al
valor de venta y además se registre en las cuentas contables correctas
• Entregables: Se construirá un plan de pruebas que contenga casos de prueba desde el punto de vista funcional como
también de usabilidad y/o de ambientes si aplicase
• Casos de prueba: se de nen los casos de prueba para las distintas funcionalidades
fi
fi
Scrum Master Avanzado
Clase 2
Ricardo Araya Gautier
CEO
[email protected]+56 9 690 948 65
