Está en la página 1de 47

Agile Testing

[ Pruebas de Software en Proyectos
Basados en Metodologías de
Desarrollo de Software Ágil ]
VERIFICACIÓN Y VALIDACIÓN DE SOFTWARE
Ingº Rembrandt Ubalde Enriquez, ISTQB®
rembrandtubalde@gmail.com

Agenda
Introducción: Metodologías y
Procesos
Metodologías Ágiles y SCRUM
Testing Agile y la Integración
Continua

METODOLOGÍAS Y
PROCESOS

El éxito es raro
Fallidos
2014 15%
2010 23%

Problemáticos
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 Difícil .

Gestión de Proyectos del Siglo XX Tiempo Funcionalidad Recursos Calidad “El triángulo de Hierro” (Tetraedro más bien?) Imagen copyright de Tetra Pak .

“Mantra” del Siglo XXI Hacer más con menos! Pero si tus únicas variables son: Funcionalidad Recursos Tiempo Calidad … entonces cómo 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 Filosofía: “Contabilidad de Costes” Filosofía: “Lean Manufactoring” y “Teoría de las Restricciones” .

recurso. acostúmbrate Medida principal Finalización de tarea Sólo entregables que cuentan para el cliente Definición de calidad Conformidad con la especificación Valor para el cliente Tolerancia a la variabilidad Las tareas se pueden identificar y estimar determinísticamente La variabilidad es parte de todos los flujos del proceso Productos intermedios Documentos. y/o calidad Detectar y eliminar cuellos de botella Aproximación a la confianza Monitorizar y medir. modelos y otros artefactos Solo lo suficiente para minimizar la incertidumbre Aproximación a la resolución de desviaciones Ajustar tiempo. funcionalidad.Dos Paradigmas de Proceso Work-down Sacar trabajo adelante Value-up Incrementar valor Planificación y gestión del cambio Get planning and design right up front El cambio ocurre. rendimiento relativo al plan Orgullo del equipo humano y del trabajo colaborativo .

hay bloqueos y marchas atrás 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 Sólo en proyectos de bajo riesgo. funciona el paradigma work-down ya que se puede repetir el proceso . Einstein En general El proceso no fluye suavemente.Work-Down vs. Value-Up Work-Down es un caso especial Similar a la Física: Newton vs.

METODOLOGÍAS ÁGILES .

El manifiesto ágil http://www. preferimos lo primero .org “Preferimos…” Individuos e interacción a procesos y herramientas Software funcional a documentación exahustiva Colaboración con el cliente a negociación de contratos Respuesta ante los cambios al seguimiento de un plan Aunque hay valor en lo segundo.agilemanifesto.

Principios del manifiesto Adaptabilidad Colaboración Integración continua Simplicidad .

no una biblia intocable El cliente propondrá cambios que han de introducirse en el desarrollo Los presupuestos han de contar con esos cambios La métrica ha de reflejar el impacto de los cambios Se consigue un software más satisfactorio .Adaptabilidad El análisis inicial es una guía.

no los procesos Todo el mundo tiene algo que decir El equipo ha de estar motivado Implicación de los desarrolladores Libertad de exploración La visión general del proyecto es conocida por todos Las reuniones son imprescindibles Cortas.Colaboración El equipo es importante. pero frecuentes Se discute el estado del proyecto La organización es dinámica Liderar un equipo. concretas. no gestionarlo .

Integración continua El software se entrega por partes Las diversas entregas han de ser ejecutables Cada integración supone una evualuación de la misma Eso permite corregir errores y cambiar funcionalidad El cliente tiene un papel en la integración continua .

Simplicidad Lo simple es bello Mantener una estructura organizativa sencilla No complicar innecesariamente los procesos No saturar el proyecto con documentación superflua Crear un sistema de comunicaciones rápido y ágil .

Conceptos Roles Actividades Iteraciones .

Roles Un rol es una función dentro del equipo de desarrollo Los roles pueden desempeñarse por más de una persona Una persona puede desempeñar más de un rol Las actividades están asociadas a roles Los roles pueden tener ciertos permisos dentro de la organización .

Una iteración será un conjunto de actividades Las actividades se asignan a personas que pertenecen a roles Es deseable monitorizar las . codificación. testeo..Actividades Las tareas se definen como actividades Incluyen cualquier cosa que haya de hacerse durante el proyecto Captura de requerimientos..

Iteraciones Ciclos de desarrollo cortos Suelen ser de un mes Al principio se decide que actividadaes incluirá cada iteración Al final se obtiene software instalable y ejecutable Integración continua Durante la iteración las reuniones han de permitir controlar el estado de la iteración Las iteraciones son revisables .

SCRUM Es una implementación de metodología á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 dinámica 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 día se realiza una reunión para realizar el seguimiento del sprint (SCRUM) Reuniones cortas (15 minutos) .

.

.

.

.

.

.

.

.

.

.

.

.

 Mercurial o Microsoft Visual SourceSafe) compilarlo. Team Foundation Build para .Integración Continua La integración continua (continuous integration en inglés) es un modelo informático propuesto inicialmente por Martin Fowler que consiste en hacer integraciones automáticasde un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes. CruiseControl o Anthill  (para proyectos Java) o CruiseControl. que se encargan de controlar las ejecuciones.Net. A menudo la integración continua está asociada con las metodologías de programación extrema y desarrollo ágil. Git. descargarse las fuentes desde el control de versiones (por ejemplo CVS. Entendemos por integración la compilación y ejecución de pruebas de todo un proyecto. El proceso suele ser. ejecutar las pruebas y realizar los informes. cada cierto tiempo (horas).Net. . Continuum. Hudson. Subversion. apoyadas en otras herramientas como Ant o Maven (también para proyectos Java). Para esto se utilizan aplicaciones como Bamboo. ejecutar pruebas y generar informes. Jenkins.Net) que se encargan de realizar las compilaciones. o Nant o MSBUILD (para .

como mínimo de forma diaria. .Concepto La integración continua es una práctica de desarrollo de software en la cuál los miembros de un equipo integran su trabajo frecuentemente. Cada integración se verifica mediante una herramienta de construcción automática para detectar los errores de integración tan pronto como sea posible.

Esquema Básico .

.

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

TODOS los test y revisiones deben ejecutar OK. NO tome código del repositorio que no funciona. Ejecute builds privados. Escriba tests unitarios automáticos. Corrija los errores que rompieron el buid inmediatamente. NO haga commit de código que no funciona.Buenas prácticas Construya binarios con cada cambio. . Haga commit con frecuencia.

puesto que es algo que se realiza de forma continua.Beneficios de la integración continua  El principal beneficio de la integración continua es la reducción del riesgo.  También permite reducir la aparición de bugs. . Esto también permite que los usuarios valoren estos cambios y sugieran cambios nuevos de forma rápida. esto permite la rápida adopción por parte de los usuarios de las nuevas características añadidas al proyecto. Se puede predecir el tiempo de integración. puesto que la realización constante de pruebas permite su pronta detección y corrección antes de que entren en producción.  Ya que se dispone en todo momento de ejecutables del proyecto.

.

youtube.com/watch? v=mrUfnPqUwKw https://www.youtube.Videos de Explicación de Integración Continua y Jenkins https://www.com/watch? v=bpWuPaeggzo .