Agile Testing

[ Pruebas de Software en Proyectos

Basados en Metodologas de
Desarrollo de Software gil ]
VERIFICACIN Y VALIDACIN DE SOFTWARE
Ing Rembrandt Ubalde Enriquez, ISTQB
rembrandtubalde@gmail.com

Agenda
Introduccin: Metodologas y
Procesos
Metodologas giles y SCRUM
Testing Agile y la Integracin
Continua

METODOLOGAS Y
PROCESOS

El xito es raro
Fallidos
2014 15%
2010 23%

Problemticos
51%
49%

Existosos
34%
28%

Fuente: The Standish Group International, Extreme Chaos, 2014

Se pasan en coste:
45%
Se pasan en tiempo:
63%
No llegan a la funcionalidad:
67%

El Problema con el Proceso

Predecible
Repetible

Productivo

Complejo
Desconectado
Difcil

Gestin de Proyectos del Siglo

XX
Tiempo
Funcionalidad
Recursos
Calidad

El tringulo de
Hierro
(Tetraedro ms bien?)
Imagen copyright de Tetra Pak

Mantra del Siglo XXI

Hacer ms con
menos!
Pero si tus nicas variables son:
Funcionalidad
Recursos
Tiempo
Calidad

entonces cmo vamos a hacerlo?

Dos Paradigmas de
Proceso

El tradicional: descomponemos
tareas y medimos su grado de
completitud

El alternativo: contabilizamos el
valor para el cliente y lo vamos
entregando incrementalmente

Filosofa: Contabilidad de Costes

Filosofa: Lean Manufactoring y

Teora de las Restricciones

Dos Paradigmas de
Proceso
Work-down
Sacar trabajo
adelante

Value-up
Incrementar valor

Planificacin y
gestin del cambio

Get planning and design

right up front

El cambio ocurre,
acostmbrate

Medida principal

Finalizacin de tarea

Slo entregables que

cuentan para el cliente

Definicin de
calidad

Conformidad con la
especificacin

Valor para el cliente

Tolerancia a la
variabilidad

Las tareas se pueden

identificar y estimar
determinsticamente

La variabilidad es parte de
todos los flujos del proceso

Productos
intermedios

Documentos, modelos y
otros artefactos

Solo lo suficiente para

minimizar la incertidumbre

Aproximacin a la
resolucin de
desviaciones

Ajustar tiempo, recurso,

funcionalidad, y/o calidad

Detectar y eliminar cuellos

de botella

Aproximacin a la
confianza

Monitorizar y medir;
rendimiento relativo al plan

Orgullo del equipo

humano y del trabajo
colaborativo

Work-Down vs. Value-Up

Work-Down es un caso especial
Similar a la Fsica: Newton vs. Einstein
En general
El proceso no fluye suavemente, hay
bloqueos y marchas atrs
La productividad de los recursos no se
distribuye uniformemente a lo largo del
tiempo
Hay varianza en la efectividad a la hora de
completar tareas

Slo en proyectos de bajo riesgo,

funciona el paradigma work-down ya que
se puede repetir el proceso

METODOLOGAS GILES

El manifiesto gil
http://www.agilemanifesto.org
Preferimos
Individuos e interaccin a procesos y
herramientas
Software funcional a documentacin
exahustiva
Colaboracin con el cliente a
negociacin de contratos
Respuesta ante los cambios al
seguimiento de un plan
Aunque hay valor en lo segundo,
preferimos lo primero

Principios del manifiesto

Adaptabilidad
Colaboracin
Integracin continua
Simplicidad

Adaptabilidad
El anlisis inicial es una gua, no una
biblia intocable
El cliente propondr cambios que han
de introducirse en el desarrollo
Los presupuestos han de contar con
esos cambios
La mtrica ha de reflejar el impacto
de los cambios
Se consigue un software ms
satisfactorio

Colaboracin
El equipo es importante, no los procesos
Todo el mundo tiene algo que decir

El equipo ha de estar motivado

Implicacin de los desarrolladores
Libertad de exploracin

La visin general del proyecto es conocida

por todos
Las reuniones son imprescindibles
Cortas, concretas, pero frecuentes
Se discute el estado del proyecto

La organizacin es dinmica
Liderar un equipo, no gestionarlo

Integracin continua
El software se entrega por partes
Las diversas entregas han de ser
ejecutables
Cada integracin supone una
evualuacin de la misma
Eso permite corregir errores y cambiar
funcionalidad

El cliente tiene un papel en la

integracin continua

Simplicidad
Lo simple es bello
Mantener una estructura organizativa
sencilla
No complicar innecesariamente los
procesos
No saturar el proyecto con
documentacin superflua
Crear un sistema de comunicaciones
rpido y gil

Conceptos
Roles
Actividades
Iteraciones

Roles
Un rol es una funcin dentro del
equipo de desarrollo
Los roles pueden desempearse por
ms de una persona
Una persona puede desempear ms
de un rol
Las actividades estn asociadas a
roles
Los roles pueden tener ciertos
permisos dentro de la organizacin

Actividades
Las tareas se definen como
actividades
Incluyen cualquier cosa que haya de
hacerse durante el proyecto
Captura de requerimientos, testeo,
codificacin...

Una iteracin ser un conjunto de

actividades
Las actividades se asignan a personas
que pertenecen a roles
Es deseable monitorizar las

Iteraciones
Ciclos de desarrollo cortos
Suelen ser de un mes

Al principio se decide que

actividadaes incluir cada iteracin
Al final se obtiene software instalable
y ejecutable
Integracin continua

Durante la iteracin las reuniones han

de permitir controlar el estado de la
iteracin
Las iteraciones son revisables

SCRUM
Es una
implementacin de
metodologa gil
Creada por
Hirotaka Takeuchi e
Ikujiro Nonaka en
1986

Principios de SCRUM
Equipo muy simple
Pila de funcionalidades (Backlog)
Reuniones diarias (Scrums)
Iteraciones (Sprints)

Equipo
Propietario del producto
Da los requerimientos
Paga!

Equipo
Autogestionado
Multidisciplinar

Scrum Manager
Supervisa y coordina los roles
Comprueba las tareas

Backlogs
Listado de requisitos
Recopilado por el propietario del
producto
Es una lista dinmica
Se subdivide en los diferentes sprints

Sprints
Representan iteraciones
Por lo general de un mes

Cada sprint posee una pila extraida

del backlog de producto
Los sprints se revisan al final para
evaluarlos (retrospectivas)
Cada da se realiza una reunin para
realizar el seguimiento del sprint
(SCRUM)
Reuniones cortas (15 minutos)

Integracin Continua
Laintegracin continua(continuous integrationeningls) es un
modeloinformticopropuesto inicialmente porMartin Fowlerque
consiste en hacerintegraciones automticasde un proyecto lo ms
a menudo posible para as poder detectar fallos cuanto antes.
Entendemos por integracin lacompilacinyejecucin de
pruebasde todo un proyecto.
El proceso suele ser, cada cierto tiempo (horas), descargarse las
fuentes
desde
elcontrol
de
versiones(por
ejemploCVS,Git,Subversion,MercurialoMicrosoft
Visual
SourceSafe) compilarlo, ejecutar pruebas y generar informes.
Para
esto
se
utilizan
aplicaciones
comoBamboo,Continuum,Hudson,Jenkins,CruiseControloAnthill
(para proyectosJava) oCruiseControl.Net,Team Foundation Build
para.Net, que se encargan de controlar las ejecuciones, apoyadas
en otras herramientas comoAntoMaven(tambin para proyectos
Java), o Nant o MSBUILD (para .Net) que se encargan de realizar
las compilaciones, ejecutar las pruebas y realizar los informes.
A menudo la integracin continua est asociada con las
metodologas deprogramacin extremaydesarrollo gil.

Concepto
La integracin continua es una
prctica de desarrollo de software en
la cul los miembros de un equipo
integran su trabajo frecuentemente,
como mnimo de forma diaria. Cada
integracin se verifica mediante una
herramienta de construccin
automtica para detectar los errores
de integracin tan pronto como sea
posible.

Esquema Bsico

Forma de trabajo
1. Un desarrollador realiza un commit (cambios) sobre el SCM server mientras el administrador de CI lo
consulta por cambios con una frecuencia determinada.
2. Despus del commit el administrador de CI detecta el cambio, toma del repositorio las ltimas
versiones y ejecuta los scripts que integran todo el software.
3. El administrador de CI informa por mail acerca de los resultados a los miembros del grupo de
desarrollo de los resultados del build.

4. El administrador continua consultando al repositorio con la frecuencia determinada.

Buenas prcticas
Construya binarios con cada cambio.
Haga commit con frecuencia.
NO haga commit de cdigo que no funciona.
Corrija los errores que rompieron el buid inmediatamente.
Escriba tests unitarios automticos.
TODOS los test y revisiones deben ejecutar OK.
Ejecute builds privados.
NO tome cdigo del repositorio que no funciona.

Beneficios de la integracin
continua

El principal beneficio de la integracin continua es la reduccin del riesgo. Se puede predecir

el tiempo de integracin, puesto que es algo que se realiza de forma continua.

Tambin permite reducir la aparicin de bugs, puesto que la realizacin constante de pruebas
permite su pronta deteccin y correccin antes de que entren en produccin.

Ya que se dispone en todo momento de ejecutables del proyecto, esto permite la rpida adopcin
por parte de los usuarios de las nuevas caractersticas aadidas al proyecto. Esto tambin
permite que los usuarios valoren estos cambios y sugieran cambios nuevos de forma rpida.

Videos de Explicacin de
Integracin Continua y Jenkins
https://www.youtube.com/watch?
v=mrUfnPqUwKw
https://www.youtube.com/watch?
v=bpWuPaeggzo