1.
Desarrollo en Cascada (Waterfall)
VS
Desarrollo Agile-SCRUM

2.
Índice
1. Una situación real.
2. Modelo en Cascada
I. Definición.
II. Desventajas.
III. Características del Testing en Modelo en Cascada.
IV. Cambio de Paradigma.
3. Scrum
I. Características.
II. Testing en Scrum.
4. Zephyr

3.
Agile Testing,
¿Trabajas bajo este modelo?
 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?

4.
Agile Testing,
¿Trabajas bajo este modelo?
 En relación con la herramienta
 ¿Utilizan una suite arancelada u open source?

5.
Agile Testing,
¿Trabajas bajo este modelo?
 ¿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?

6.
Agile Testing,
¿Trabajas bajo este modelo? PLANTEO 1-1
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.

7.
Agile Testing,
¿Trabajas bajo este modelo? DEVOL –Planteo1.1
 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.

8.
Agile Testing,
¿Trabajas bajo este modelo? PLANTEO 1.2
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.

9.
Agile Testing,
¿Trabajas bajo este modelo? DEVOL – Planteo 1.2
 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.

10.
Agile Testing,
¿Trabajas bajo este modelo? PLANTEO 1.3
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.

11.
Agile Testing,
¿Trabajas bajo este modelo? DEVOL – Planteo 1.3
 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,

12.
Agile Testing,
¿Trabajas bajo este modelo? PLANTEO 2
Actualmente estoy trabajando en proyecto en el empezó utilizando "Kanban" como metodología,
sugerí cambiar y utilizar Scrum. Hemos hecho el cambio y funciona mucho mejor el proceso.
Solíamos usar una planilla de google drive para el seguimiento del trabajo diario. Sugerí cambiarlo por
un Board Ágil de Jira.
Desarrolle un workflow acorde a las necesidades del proceso y centralizamos toda la información en
un solo lugar.
Para el trackeo de test cases y test cycles usamos testrails, pero estamos en un proceso de cambio. Las
opciones son Qtest, una herramienta de QaSymphony y Zephyr. Ambos tienen features similares,
pero Zephyr ya lo he usado y me resulto muy bueno como tracker.
En cuanto al proceso, nos manejamos con dailys y el Product Owner participa activamente del
proceso.

13.
Dentro de las organizaciones de desarrollo de aplicaciones existen dos
grandes corrientes para la metodología en el desarrollo de un proyecto:
 La que tradicionalmente conocemos como “desarrollo en cascada o
secuencial” y
 las nuevas metodologías que proponen la generación de pequeños
entregables en un esquema de actividades que se pueden solapar o
traslapar, ya sea en forma secuencial o con un enfoque en palalelo.

14.
Modelo en Cascada

15.
Definición - Etapas
 Es el enfoque metodológico que ordena rigurosamente las etapas del
ciclo de vida del software, de forma tal que el inicio de cada etapa debe
esperar a la finalización de la inmediatamente anterior.
 Las etapas que comprende este enfoque son:
1. Análisis de requisitos
2. Diseño del Sistema
3. Codificación/Implementación
4. Pruebas/Validación
5. Implantación/Instalación
6. Mantenimiento

16.
Desventajas del Modelo en Cascada
 La mayor desventaja del modelo de cascada es uno de sus mayores ventajas: No se
puede volver atrás.
 Les exige a los usuarios finales que tengan que conocer desde un principio todos sus
requerimientos.
 Muchas veces sucede que el cliente no es muy claro de lo que exactamente quiere
del software. se exige la aceptación de alcances previamente definidos a través de
documentos como “Casos de Uso”.
 Los pequeños cambios que surgen una vez que el software está completamente
desarrollado  Generar mucho re trabajo.
 La mayor desventaja del Modelo en Cascada es que hasta que la etapa final del
ciclo de desarrollo se haya completado, el software no está en las manos del cliente.
Recién en esta instancia, el usuario podrá tener interacción con el producto
solicitado Ocasiona:
 Problemas por falta de definición, mala interpretación, etc.
 Muchos aspectos de un sistema (look and feel, usabilidad, etc.) sólo se perciban cuando se
opera el mismo.

17.
Características del Testing en Modelo
en Cascada
 Normalmente solo se involucran los analistas de sistemas para el levantamiento de
requerimientos sin involucrar a otros miembros del equipo de desarrollo (ejemplo:
tester) La participación del Tester está relegada a etapas posteriores del proyecto.
 El alcance se congela rápidamente  Las pruebas son definidas y se mantienen a lo
largo de todo el proyecto.
 Se tiene un conocimiento claro de cuándo parar el ciclo de Testing  Condiciones
de Corte.
 Aunque los requerimientos evolucionen, el alcance debe ser mantenido hasta que
se genere un control de cambios La tarea de actualización de CP es mínima.
 Los cambios en los requerimientos normalmente aparecen a lo largo del proyecto 
las actividades de Testing están delimitadas y se conocen claramente. No hay
cambios en las mismas.
 Es factible implementar la automatización de CP.

18.
Cambio de Paradigma
 Exigencias del Cliente  Fechas pactadas con la Gerencia.
 Modificación en el “Dinamismo del proyecto”  Búsqueda de una
nueva metodología:
 Pronto resultado  Visibilidad del producto.
 Fuerte interacción entre todos los involucrados del proyecto.
 Decisión: Utilizar Desarrollo Agile-SCRUM

19.
Agile-SCRUM

20.
Características
 Scrum es un modelo de referencia Iterativo e incremental.
 Define una serie de prácticas y roles.
 Permite la creación de equipos auto organizado impulsando la co-
localización de todos los miembros del equipo, y la comunicación verbal
entre todos los miembros y disciplinas involucrados en el proyecto.
 Un principio clave de Scrum es el reconocimiento de que durante un
proyecto los clientes pueden cambiar de idea sobre lo que quieren  Por
lo tanto, Scrum adopta una aproximación pragmática, aceptando que el
problema no puede ser completamente entendido o definido, y
centrándose en maximizar la capacidad del equipo de entregar
rápidamente y responder a requisitos emergentes.

21.
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.

22.
Zephyr

23.
Zephyr para JIRA es una aplicación adicional que aumenta JIRA 5 y 6 , que permite en
cada etapa del ciclo de vida del software planificar, construir, probar y poner en
marcha el software .
Las características principales incluyen :
Crear , ver, editar y pruebas.
Ciclos de ejecución del plan de pruebas.
Ejecutar pruebas.
Enlazar Defectos.
Métricas de calidad por ciclo de Testing.
Crear cuadros de mando personalizados.
Realizar búsquedas avanzadas utilizando ZQL.

24.
Elaborado por : Marcela Andrea Alvarez (Colaboradora)
ar.linkedin.com/pub/ing-marcela-andrea-alvarez/21/16a/ba3/en
Actualizado por: Gustavo Terrera

25.
Gustavo Terrera (Fundador de TestingBaires)
Email: gustavo@testingbaires.com
WebSite: http://testingbaires.com/
Facebook: https://es-es.facebook.com/testingbaires
Twitter: https://twitter.com/testingbaires