Conceptos de desarrollo ágil

Prácticas modernas de pruebas basadas en Lean/Agile
1. Conceptos de Desarrollo Ágil

Contenido
• Lean Testing
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development

Lean Testing
Que tan “Lean” son tus Pruebas?
Documentación Herramientas Roles
Aprendizaje
Planificación de
Pruebas
Frecuencia de
Despliegues
Priorización de
Defectos
Seguimiento
de Defectos
Objetivo de
las Pruebas
ACTIVIDAD GRUPAL
5

Lean Testing
• Algunas “creencias” injustificables sobre las
pruebas conduce a desperdicios:
• Todas las pruebas deben tener un “guion de pruebas”
• Los planes de prueba deben seguir el formato IEEE 829
• Los usuarios deben firmar los guiones de pruebas
• Las pruebas necesitan que los requerimientos estén
completos para comenzar el diseño de las pruebas
• No probamos sobre sistemas inestables
• Repetiremos todas las pruebas cuando el sistema cambie
• Las pruebas deben permanecer “independientes” del
desarrollo

Lean Testing
• Flujo de entrega de Software
• QA al final del ciclo es puede ser desperdicio
• El software es “digerido” en parte pequeñas

Lean Testing
• Documentacion “Viva”
• Funcionalidad basada en ejemplos y automatizable

Lean Testing
• Documentacion “Ligera”
• Ideas concretas en lugar de llenar plantillas extensas

Lean Testing
• Pruebas manuales sin guiones
• En lugar de sobre-producir guiones, se aprende sobre el
software explorando ideas de pruebas.

Lean Testing
• Backlog de requerimientos y defectos
• El usuario diferencia entre una nueva funcionalidad o un
defecto? O quiere que el Sistema se comporte bien?

Lean Testing
• Concentrarse en una sola actividad. La multitarea
es desperdicio
5

Lean Testing
• Aprendizaje en pares o equipos

Lean Testing
• Cuanto mas rápido se encuentre un defecto,
generará menos desperdicio

Lean Testing
• ACTIVIDAD
• Push vs Pull
• Aviones

Lean Testing
• Algunas estrategias para tratar con los desperdicios
en los procesos de prueba:
• Documentar requerimientos como ejemplos
potencialmente automatizables
• Automatizar las pruebas en distintos niveles
• Ideas de pruebas en lugar de guiones de prueba
• Documentación ligera y mapas mentales
• Aprendizaje entre pares
• Probador integrado dentro del equipo
• Seguimiento de defectos similar a los requerimientos
• Planes de prueba por iteraciones, no usar formatos IEEE

Whole Team Approach
Trabajas en un equipo o en un SILO?
5

Whole Team Approach
• El Problema de los SILOS
• Se comparte información?
• Se recibe apoyo siempre?
• Se logran resultados en forma eficiente?

Whole Team Approach
• En el “Whole Team Approach” todos somos
responsables por la Calidad
• No solo los testers o el equipo de QA son los
responsables de la calidad
• No se piensa en “departamentos” sino en habilidades y
recursos para entregar el mejor producto posible
• Todo el equipo es “test-infected”
• Pruebas desde el nivel unitario
Objetivo: Producir Software de Alta
Calidad en un marco de tiempo que
maximice el valor de negocio

Whole Team Approach
• La diferencia entre un equipo multifunctional
Tradicional y un equipo agile es el “Whole Team
Approach
Henry Kniberg
DaveJoe Lisa
Dave
Joe
Lisa
January February March April May June July
6 months
3 months
Release
Release
Somos rapidos!
Soy un poco
lento
Estamos lentos!
Soy rapido!

Whole Team Approach
• Equipos de Alta Performance (VIDEO)

Whole Team Approach
• Generalistas vs Especialistas
• El Equipo tiene todas las habilidades para producir
código de calidad
• Especialistas sin limitación de tareas
• Equipo toma responsabilidad de las tareas de testing
• Arme su T-Shape de conocimiento especializado y habilidades horizontales
• Encuentre un equipo en el que se complementen

Whole Team Approach
• Equipo diseña código testeable
• El equipo utiliza los principios S.O.L.I.D.?
Mezcla creacion de objetos con
logica. No Testeable.
Reemplazamos objetos de
produccion por “dobles”. Testeable.

Whole Team Approach
• En un equipo ágil cualquiera pide y recibe ayuda
• Los testers no se encasillan en pruebas manuales
• El tester no es excluido de las reuniones técnicas o
de negocio
• El tester ayuda a los clientes a proporcionar
ejemplos
• El tester se sienta con el programador
Whole team approach: Mis problemas
son problemas del equipo, los problemas
del equipo son los mios.

Whole Team Approach
Pruebas Automatizadas
• Programadores, testers y otros miembros del equipo
colaboran para automatizar las pruebas
Tradicional Lean/Agil
AUTOMATIZACION

Whole Team Approach
Involucrado continuamente desde el
inicio en:
• Facilitar la comunicación entre los
interesados de negocio y técnico
• Soportar la validación temprana
de los requerimientos
• Ayudar a los interesados del
negocio/clientes a definir los
criterios de aceptación
• Soporte a la creación de pruebas
de aceptación automatizadas
• Expandir el alcance de las
pruebas de aceptación
• Aconsejar al equipo sobre riesgos
y tendencias
• Realizar pruebas
manuales/exploratorias
• Realiza revisiones de código
• Usa herramientas de analisis
estatico
• Realiza pruebas unitarias
automatizadas (TDD)
• Realiza pruebas de integracion
entre components
(Automatizado)
• Soporta a los testers en las
pruebas de
Aceptacion/Sistema
(Automatizado)
* Necesita “habilidades técnicas”
Rol del Tester Ágil Desarrollador con relación a Pruebas

Whole Team Approach
• ACTIVIDAD
• Desarrollo guiado por Pruebas

Whole Team Approach
• Conclusiones
• Ágil es “Calidad” no “Velocidad”
• Todo el equipo es responsable de la Calidad
• El objetivo es producir software de alta calidad en un
marco de tiempo, que maximice el valor de negocio

Contenido
• Manifiesto Ágil
• WholeTeam Approach
• Feedback temprano y frecuente
• Planificación Ágil
• Requerimientos Ágiles
• Test Driven Development
• Acceptance Test Driven Development

Feedback temprano y frecuente
Que tipo de “Feedback” sobre el
producto de software suele dar u
obtener a lo largo del proceso de
desarrollo?
5

• Analistas y Testers dan feedback a los desarrolladores
sobre las Historias de Usuario
• No siempre todos entienden lo mismo…

• Las pruebas automatizadas proporcionan
feedback, temprano y frecuentemente

• Las pruebas automatizadas se añaden y ejecutan
desde el ambiente de Integracion continua (CI)
El servidor de CI asigna una etiqueta a la
versión de código que acaba de compilar
El servidor de CI informa al equipo sobre
la compilación satisfactoria
Si la compilación o pruebas fallan, el
servidor de CI alerta al equipo
El equipo arregla los problemas en la
oportunidad mas cercana

• Feedback a través de Pair programming entre
desarrolladores
Driver
Maneja el teclado
Escribe las pruebas
Escribe el código
Navegante
Se enfoca en el objetivo
Guía al Driver
Propone las siguientes pruebas

• Feedback en iteraciones cortas
• Las iteraciones cortas permiten al equipo obtener
feedback del cliente rápido.
• Todo Proyecto debería tener varias ocasiones para que
los interesados proporcionen su feedback

• Otras actividades de feedback del Tester
• Pedir feedback a los clientes si que se tiene los ejemplos
correctos del comportamiento deseado
• Pedir feedback al Product Owner si los casos de prueba
que escribió reflejan esos ejemplos correctamente
• Asegurarse que los programadores pueden entender
que deben codificar mirando los ejemplos y los casos de
prueba
• Proporcionar feedback a través de las pruebas
manuales/exploratorias
• Proponer mejoras en base al feedback en las
retrospectivas o planificación de la iteración

Planificación Agil
Describa en no mas de 25
palabras el propósito del
último proyecto en el que
participó

Planificación en Capas
Story (Backlog
Item)
Que usuario o stakeholder servirá la
historia?
Como lucírá y comportará?
Como se determina si esta terminada?
Story Details
Acceptance Tests
Producto
o Proyecto
Qué Objetivos de
Negocio debe cumplir el
producto?
Objetivo del Producto
Product Charter
Clientes
Usuarios
Iteracion o
Sprint
Que se construirá? (user
stories)
Como es que éste sprint
nos ayudara a conseguir
los objetivos del release?
Objetivo Iteración
Desarrollo
Release
Como podemos entregar valor
incrementalmente?
Que sub-conjunto de objetivos
de negocio debe alcanzar cada
release?
A que grupos de usuario servirá
el release?
Que características generales
(historias grandes) ofrecerá el
release?
Release Roadmap
Clientes Objetivo
Usuarios Objetivo
39

La Prueba del Ascensor
1. A (cliente blanco)
2. Que (enunciado de la
necesidad o oportunidad)
3. El (nombre del producto)
es un (categoría
del producto)
4. Que (beneficio clave,
razón convincente para
comprar)
5. Al contrario de (alternativa
primaria con la cual
compite)
6. Nuestro producto
(enunciado de
diferenciación primaria)
Enunciado de la Prueba del Ascensor – habilidad de
explicar el producto a cualquier persona en dos
minutos, de esta forma:
PARA los viajeros
QUE quieren ser recompensados con viajes con
Aerolíneas FlyPeru
EL programa de viajero frecuente de FlyPeru es
un programa de lealtad
QUE permite a los miembros fácil y cómodamente
ver y administrar sus puntos acumulados en
tiempo real, y gastar sus puntos en compras
reales con inigualable facilidad.
A DIFERENCIA de otros programas de viajero
frecuente,
NUESTRO PRODUCTO permite a los miembros usar
sus puntos fácilmente para cualquier tipo de
compra en línea o tradicional.
Describa, usando la prueba del ascensor, el propósito del último
proyecto en el que participó (5 min)

Roadmap del Producto
Scrum Alliance website product roadmap
• Una planificación a nivel de producto debería
tener una visión de producto, un backlog de
producto de alto nivel y un roadmap de producto

Actividad
Organizador personal
Agrupar las características que sean
similares o relacionadas. Nombre las
agrupaciones.
Ordenar de izquierda a derecha de manera
que muestre un sentido de secuencia.
Eliminar duplicados si hubiere.
Trabajar en grupo.
10

User Story Mapping
• Story Mapping una técnica
que permite Organizar y
Priorizar historias de usuario
• Organiza las historias de
usuario en un mapa
• Hace visible el flujo de cadena
de valor.
• Ayuda a completar el backlog
• Provee un contexto que
facilita la priorización.
• Permite planificar las entregas
visualizando el valor de cada
una de ellas.
Jeff Patton

User Story Mapping
Cliente de Correo Electronico. Ejemplo tomado de: Winnipeg Agilist

User Story Mapping
• Contar como funciona el producto describiendo
las principales actividades que hacen los usuarios
tiempo
tiempo
• Añadir tareas debajo de cada actividad mostrando
el flujo de izquierda a derecha.

User Story Mapping
• Ordena verticalmente las tareas que el usuario hace al mismo
tiempo
– Si al contar la historia que digo que el usuario hace típicamente "¿esto
o esto o esto, y luego hace eso“. “o“ significa apilamiento vertical, “y
después" significa ordenarlas en sentido horizontal.
tiempo

User Story Mapping
• El backbone de la aplicacion es la lista de actividades
esenciales.
• El walking skeleton es el software que construimos
que soporta el minimo numero de tareas necesarias
que los usuarios necesitan para hacer su trabajo
time
necessity
The backbone
The walking skeleton

User Story Mapping
time
opcionalidad
necesario
menos
opcional
mas
opcional
primer release
segundo release
tercer release
• Escoja grupos de historias que juntas entreguen funcionalidad completa para el
negocio y los usuarios
• Asegurarse de entregar las características esenciales en el primer release
• Mejorar la implementación de las funcionalidad con cada unos de los releases
• Teniendo el mapa organizado por necesidad, sólo necesitamos
cortarlo en rebanadas

User Story Mapping
• Priorizacion con los criterios MoSCoW
Must - Tiene que tener si no ya seria una
hamburguesa
Should - Debe tenerla para poder armar la
hamburguesa
Could - Podría tener, para hacerla más sabrosa
Won’t - No es necesario que tenga, pero sería
agradable
Could - Podría tener, para hacerla más sabrosa

User Story Mapping
Formen equipos,
para los siguientes proyectos:
• Bolsa de Trabajo (ej. Laborum)
• Ventas por Internet (ej. Linio)
• Help Desk (ej. Aranda)
• Delivery Comida OnLine (ej. Lima Delivery)
En equipo crear el User Story Mapping del
proyecto elegido
30

Requerimientos Agiles
1. Como usuario quiero poder colocar libros en una lista de
favoritos para que sea visible a otros visitantes del sitio.
2. Como dueño de una tienda online, quiero administrar
productos para brindarle a mis clientes los mejores
productos.
3. Como consumidor, quiero ver mi uso diario de energía en un
histograma para que yo pueda entender rápidamente mi
pasado, presente y consumo de energía proyectado.
4. Como administrador de contenido, puedo publicar noticias
en el Sitio Corporativo.
5. Como usuario, deseo buscar vuelos disponibles.
6. Como usuario, deseo poder pagar mi reserva con VISA,
MasterCard, American Express y Dinners.
7. Como moderador del foro, deseo aprobar o rechazar
comentarios, para mantener limpio el foro.
15Dados los product backlog items, determine cuales estarían
listos para formar parte de un Sprint Backlog?

• Que tan grandes son las Historias?
Épica
Característica
(Feature)
Historia de
Usuario
Representan múltiples características o muchas historias
Pueden tomar meses para construirse y trabajar e nivel de
release.
Es en lo que los usuarios finales tienden a enfocarse.
Más pequeñas que las épicas, pero mas grandes que las
historias
Pueden tomar semanas, posiblemente una o mas iteraciones
para construirlo.
Es en lo que el cliente o dueño de producto tiende a enfocarse.
Son los pequeños incrementos de valor
Toma días, quizás una semana o dos a lo mucho
para construirse.
Es en lo que el equipo de desarrollo tiende a
enfocarse.
Foco
principal
de esta
sesion

• Epicas, Caracteristicas (Feature) e Historias de Usuario

• Las características (Features) son servicios proporcionados por el Sistema que
resuelven necesidades de los. Las características caben en Releases. Las Historias
caben en iteraciones o sprints.
Agile Software Requirements – Dean Leffingwell
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
Feature
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
2 weeks
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
Feature
Feature
Feature
Feature
Feature
2 weeks 2 weeks
Release 1

Patrones para dividir Historias
de Usuario

Flujo completo (1 de 2)
Dada la siguiente historia de usuario
“Como Analista de Crédito, deseo aprobar una solicitud de
crédito”
No se ve demasiado compleja….
Despues de indagar (conversar) sobre el proceso de
aprobación de créditos, resulta que existen topes para la
aprobación de solicitudes, así como también se requiere
en algunos casos la aprobación de riesgos, jefe de tienda y
dos analistas de crédito mas.

Flujo completo (2 de 2)
“Como Analista de Crédito, deseo aprobar una solicitud de
crédito”
puede refinarse en:
“... deseo aprobar una solicitud de crédito de otro Analista”
“... deseo aprobar una solicitud de crédito pre-aprobada
por Riesgos”
“... deseo aprobar una solicitud de crédito pre-aprobada
por el Jefe de Tienda”

Variaciones en las Reglas de Negocio
“Como usuario, deseo buscar Órdenes de servicio”
puede refinarse en:
“... deseo buscar por Nro. de Orden”
“... deseo buscar rango Fecha de Registro”
“... deseo buscar por Cliente”

Complejidad
“Como usuario, deseo poder vincular una red social a mi
actual perfil”
puede refinarse en:
“... deseo autenticarme con mi perfil de la red social”
“... deseo poder publicar en el timeline”
“... deseo poder acceder a la lista de contactos”
“... deseo poder obtener las fotos de mi perfil”

Operaciones (CRUD)
“Como usuario puedo administrar mi cuenta”
Puede refinarse en:
“...puedo inscribirme para una cuenta”
“...puedo editar mi configuracion de cuenta”
“...puedo cancelar mi cuenta”

Dividir un Spike*
Como usuario quiero pagar mediante Click2Sell
Puede refinarse en:
Investigar el procesamiento con Click2Sell
Implementar el procesamiento con Click2Sell
* La división en Spike debe ser la última opción.

Actividad
Aplicar los patrones de división a los
PBIs de la actividad anterior
30

De los PBIs que se obtuvieron en la
práctica anterior, que información
adicional les falta para que puedan ser
estimadas por el equipo de desarrollo?

Historias de Usuario
• Una historia de usuario describe funcionalidad que
será valiosa para un usuario o comprador de un
sistema o software
• Una Historia consta de:
Una descripción escrita de la
historia utilizada para la
planificación
y como un recordatorio
Conversaciones sobre la
historia que sirven para
profundizar en
los detalles de la historia
Pruebas que transmiten y
documentan detalles y que se
pueden utilizar para determinar
cuando una historia esta completa
un usuario
puede limitar
quien puede
ver su
currículum
Probar con Visa (P)
Probar con MstCrd (P)
Probar con Diners (N)
Probar con T.Debido
(P)
Probar con T. Expirada
Probar con dist montos

Las 3 Cs
Card • Las Historias de Usuario se
escriben en Tarjetas
• Suficiente texto para identificar los
requisitos, y para recordar a todos
cuál es la historia. No es
documentación.
Conversation • El requisito se comunica desde el
cliente hacia el equipo de desarrollo a
través de la conversación
• La conversación es en gran parte
verbal, pero puede complementarse
con los documentos.
Confirmation • El cliente le cuenta al equipo
cómo va a confirmar que lo que han
hecho es lo que se necesita.
• El cliente define las pruebas de
aceptación que se utilizarán para
demostrar que la historia se ha
implementado correctamente.
• Son los pasos o escenarios que
ayudan a un desarrollador a probar y
a un cliente o usuario realizar UAT
Como Usuario
Quiero buscar por
nombre para que
pueda encontrar a mis
amigos y asociados
Como Usuario
Quiero subir una
foto para que otros
usuarios puedan
verlo

Las 3 Cs
documentación.
con los documentos.
Como usuario, quiero subir una foto
de mi máquina local para que
cualquier usuario pueda verlo.
❑ Habrá un botón de carga en la
parte superior de mi página de
perfil
❑ Habrá un límite de tamaño de
archivo de 25 MB
❑ Los formatos soportados son:
JPEG, PNG, GIF y BMP
Como usuario, quiero etiquetar mis
amigos y escribir un título antes de
publicar una foto para salvarme
tiempo.
❑ Los campos que se pueden
editar son: título, ubicación, las
etiquetas.
❑ Al guardar la imagen será
publicada

Las 3 Cs
documentación.
con los documentos.
1. Haga clic en el botón "Subir".
2. Especifique un archivo de imagen que
desea cargar.
A. Compruebe que .jpg, .png, .gif y se
admiten extensiones .bmp.
B. Compruebe que otros tipos de
archivos no son capaces de ser
cargados.
C. Compruebe que archivos de más de
25MB dan como resultado un error.
3. Haga clic en "Subir fotos".

• En 2003, Bill Wake, propone el acrónimo
“INVEST” para evaluar las características
de una buena historia de usuario. Estas
características son:
❑ Independent (independiente)
❑ Negotiable (negociable)
❑ Valuable (valiosa)
❑ Estimatable (estimable)
❑ Small (pequena)
❑ Testable (comprobable)
https://www.youtube.com/watch?v=uj5iUbDf-
iw&list=UUQScrIAUqnPqwBu97eO17WQ#t=149

Ejemplos de Historias Inadecuadas

Criterios de Aceptación
• Para que una Historia sea “comprobable”, debería
considerar los siguientes tópicos cuando sean relevantes
Comportamiento Funcional Comportamiento observable externamente con acciones
del usuario bajo ciertas configuraciones.
Características de Calidad Atributos de calidad o requerimientos no-funcionales
como rendimiento, confiabilidad, usabilidad, etc.
Reglas de Negocio Definiciones en base a procedimientos y políticas. Por ejemplo
los procedimientos utilizados por una compañía de seguros para
manejar reclamos de seguro.
Interfaces Externas Pueden ser divididos en diferentes tipos (interfaces de
usuario, interfaces con otros sistemas, etc.).
Restricciones Restringe las opciones del desarrollo. Dispositivos con
embedded software que restringen cosas como tamaño,
peso e interfaces de conexión.
Definiciones de Datos Formato, tipos de dato, valores permitidos y valores por
defecto para un elemento de dato de negocio conocido
(por ejemplo el Código Postal en una dirección de correo)

Criterios de Aceptación
“Como usuario se me debe requerir una validación
antes de utilizar el sitio"
Criterios de Aceptación:
• El usuario esta logueado solo cuando se
proporcionen credenciales apropiadas
• Esta disponible una opción “recordarme”.
• El usuario puede requerir un recordatorio de
contraseña.
• El usuario es bloqueado luego de 3 intentos
fallidos
“Como comprador del Sitio Web quiero poder
pagar con una tarjeta de crédito para poder
confirmar inmediatamente mi compra“
• Acepta Visa, Diners, MasterCard
• Validar Nro de CC cuando sea ingresado
• Validar fecha de expiración y CVV
• Validar la dirección de facturación
• Generar mensajes de satisfacción y fallo
luego del procesamiento.
“Como contador quiero que los reportes automatizados se ejecuten al final
del mes para que los reportes estén listos al llegar a la oficina”
• Si hay un error con la generación del reporte, el Sistema necesita
notificar a soporte de producción con un ticket.
• El reporte necesita ser generado como PDF y auto-impreso.
• La selección de auto-impresion necesita ser configurable por reporte
• El Sistema debería enviar el reporte solo a la impresora configurada.
• Si la impresora tiene un error (falta papel, trabado, etc.) el usuario
debería arreglarlo.

Actividad
En grupos, elija 3 de la lista de
Historias de Usuario
desarrolladas anteriormente y
completelas.
15

Conclusiones
Cómo es que las historias de Usuario
ayudan a tener un entendimiento
compartido?

Test Driven Development
• Test-Driven Development (TDD) es una técnica usada
para desarrollar código guiado por casos de prueba
automatizados. También se le conoce como ”test-
first programming”, ya que las pruebas son escritas
antes que el código.
• Las pruebas son automatizadas y son usadas en la
Integracion Continua
• El proceso de TDD es repetido por cada pequeña
pieza de código, ejecutando las pruebas previas así
como las pruebas añadidas.
• Las pruebas sirven como una forma de especificación
de diseño ejecutable para futuros esfuerzos de
mantenimiento.

• Test-Driven Development (TDD) cycle

•VIDEO
• Red-Green-Refactor Cycle by Uncle Bob

Acceptance Test Driven Development
• El equipo colaborativamente discute los criterios
de aceptación con ejemplos…

• … y luego los destila en un conjunto de pruebas
de aceptación concretas antes que se inicie el
desarrollo.

• ATTD vs TDD

Behaviour Driven Development (BDD)
• Porque este escenario es tan común?

• El entendimiento no siempre es compartido

• Proceso de desarrollo Tradicional
La especificación escrita es muy imprecisa
y las personas suelen interpretar los
requerimientos en una forma distinta.

“Behaviour-Driven Development (BDD)
trata sobre la implementación de una
aplicación mediante la descripción de
su comportamiento desde la
perspectiva de sus grupos de interés”
http://dannorth.net/
“Se usan ejemplos en múltiples
niveles para crear un entendimiento
compartido y superar la
incertidumbre y así entregar el
software que importa.”

Entregar el software que importaRequerimientos
Noalineados
Que
ComoPobre
construcción

• Proceso de desarrollo con BDD

PRÁCTICA (en grupos de 3)
Para cada Historia de Usuario presentada, Identifique al menos 2
escenarios:
Historia de Usuario 1006: Buscar ofertas de trabajo por ubicación
Como un postulante, quiero buscar ofertas de trabajo por
ubicación para encontrar un empleo cerca a mi lugar de
residencia.
Historia de Usuario 1002: Publicar una oferta de trabajo
Como un empleador, quiero publicar una oferta de trabajo para
recibir postulantes al puesto.
10

Usando Ejemplos
PRACTICA (grupos de 3)
Para cada escenario identificado en la práctica anterior,
correspondiente a las siguientes historias:
Historia de Usuario 1006: Buscar ofertas de trabajo por ubicación
Historia de Usuario 1002: Publicar una oferta de trabajo
Describa cada escenario usando el formato:
Dado …
Cuando …
Entonces ...

Usando Ejemplos
Los escenarios pueden ser automatizables

Conclusiones
•Los escenarios en BDD pueden ser
documentados y automatizados, sin
embargo tener en cuenta que:
•Tener conversaciones es mas importante
que capturar conversaciones y mas
importante que automatizar
conversaciones

Conceptos de desarrollo ágil

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Conceptos de desarrollo ágil

Conceptos de desarrollo ágil