Cascada vs Agile Scrum v2.0

Desarrollo en Cascada (Waterfall) VS

Desarrollo Agile-SCRUM

Í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

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?

Agile Testing, ¿Trabajas bajo este modelo?

En relación con la herramienta

¿Utilizan una suite arancelada u open source?

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?

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.

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.

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.

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.

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.

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,

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.

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.

Modelo en Cascada

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 

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.

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.

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

Agile-SCRUM

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.

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.

Zephyr

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.

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

Actualizado por: Gustavo Terrera

Gustavo Terrera (Fundador de TestingBaires)Email: [email protected]: http://testingbaires.com/

Facebook: https://es-es.facebook.com/testingbairesTwitter: https://twitter.com/testingbaires