COMO HACEMOS PRUEBAS

LUIS ANGEL OSORIO OSORIO

JOSE FRANCISCO ARCOS COCONI
ALAN YAIR SOLANO CUEVAS
MARIO A. POZOS MELENDEZ
SANTIAGO ALFREDO GONZALEZ MANCILLA
LUIS OSCAR VELAZQUEZ UGALDE
NO SE PUEDE RENUNCIAR A LA FASE DE PRUEBAS
Rara vez un Sprint produce una version potencialmente estable de nuestro Sistema.
Si queremos calidad, es necesario algun tipo de fase de pruebas de aceptacin.
Encargados de pruebas dedicados que no pertenecen al equipo de desarrollo, seran los encargados de
realizar estas pruebas de forma manual.
De esta forma se aseguran situaciones que el equipo de Scrum no pudo imaginar o no se contaba con
las herramientas necesarias para probar.
MINIMIZA LA FASE DE PRUEBAS

La fase de pruebas deja una sensacion no-Agil, por ello se busca minimizar la cantidad de tiempo
invertido de la siguiente manera:
Maximizando la calidad del codigo desarrollado por el equipo Scrum.
Maximizando la eficiencia del trabajo manual de pruebas.
Cmo maximizamos la calidad del cdigo desarrollado por el equipo Scrum?
Incluir encargados de pruebas en el equipo Scrum
Hacer menos cosas en cada Sprint
INCREMENTAR LA CALIDAD INCLUYENDO
ENCARGADOS DE PRUEBAS EN EL EQUIPO

Se supone que en los equipos de Scrum no debe haber roles!

Un encargado de pruebas, es una persona cuya principal habilidad es hacer pruebas.
Los desarrolladores somos malos encargados de pruebas, especialmente cuando debemos probar
nuestro propio codigo.
EL ENCARGADO DE PRUEBAS ES QUIEN DA EL VISTO
BUENO

El encargado de pruebas es quien da el visto bueno. Nada se considera terminado hasta que el lo indica.
Como sabe el encargago de pruebas que algo esta terminado?
Debe probar la funcionalidad en un ambiente de pruebas.
Revisando la lista de comprobacin de terminado (Si se tiene).
Por ejemplo, si la definicin de terminado establece que debera haber una nota de versin, entonces el encargado
de pruebas comprueba que haya una nota de versin.
DEBERAN LAS PRUEBAS DE ACEPTACIN SER PARTE
DEL SPRINT?

Un Sprint tiene un tiempo limitado. Las pruebas de aceptacin es muy difcil de limitar en el tiempo. Por lo
tanto las pruebas permanecern fuera del Sprint
 Si tienes mltiples equipos Scrum trabajando en el
mismo producto, las pruebas manuales de aceptacin
deben hacerse sobre el resultado combinado de todos
los equipos. Si todos los equipos hicieran pruebas
manuales dentro del Sprint, aun necesitaras un equipo
externo que hiciera pruebas sobre el resultado final,
que sera la combinacin deltrabajo de ambos equipos.
CUNDO NO HAY PRUEBAS QUE HACER?
Cuando no hay pruebas que realizar es importante maximizar el trabajo, es imprescindible que es estos
casos el encargado de pruebas sepa programar para empalmarse con el equipo de trabajo para acelerar la
productividad
En caso del que no sepa programar existen algunas tareas no programables
Montar un entorno de pruebas
Clasificar requisitos
Discutir los detalles de instalacin con operaciones
Escribir documentacin de instalacin
Identificar las preguntas clave de los desarrolladores y conseguir respuestas
INCREMENTAR LA CALIDAD HACIENDO MENOS EN
CADA SPRINT

NO METER DEMASIADAS HISTORIAS EN EL SPRINT!

Si tienes problemas de calidad o ciclos de pruebas muy largas.
o Haz menos en cada sprint
Siempre es ms barato producir menos, pero hacerlos estable, en lugar de producir mucho y que tenga
parches de emergencia
CICLOS DE SPRINT VS. CICLOS DE PRUEBAS
En un mundo McScrum perfecto no es nesesario la fase de pruebas ya que cada equipo Scrum entregara
una nueva versin del sistema lista para produccin tras cada Sprint.
CICLOS DE SPRINT VS. CICLOS DE PRUEBAS
CICLOS DE SPRINT VS. CICLOS DE PRUEBAS
CICLOS DE SPRINT VS. CICLOS DE PRUEBAS

Lo primero de todo, maximiza la calidad del cdigo que el equipo Scrum libera. El coste de encontrar y
corregir errores pronto, durante el Sprint, es extremadamente bajo comparado con encontrarlos y
corregirlos ms tarde.
Pero el problema permanece, incluso aunque minimicemos el nmero de errores,aun seguirn
apareciendo errores despus de que se complete el Sprint. Cmo nos enfrentamos a ello?
CICLOS DE SPRINT VS. CICLOS DE PRUEBAS

Enfoque 1: No empieces a desarrollar nada nuevo hasta que est en produccin lo que has
desarrollado
Hemos estado cerca de adoptar este enfoque varias veces, y hemos diseado elaborados modelos de
cmo podramos hacerlo. Y sin embargo siempre hemos cambiado de parecer cuando nos damos
cuenta de los contratiempos.
Tendramos que aadir un periodo de pruebas no acotado en tiempo entre los Sprints, en el que slo
haramos pruebas y correcciones hasta que tuviramos una versin lista para produccin.
CICLOS DE SPRINT VS. CICLOS DE PRUEBAS

No nos gusta el concepto de tener periodos de pruebas no acotados en tiempo entre Sprints,
principalmente porque rompera el ritmo regular de los Sprints. No podramos decir cada 3 semanas
comenzamos un Sprint. Adems, esto no soluciona completamente el problema. Incluso si tenemos un
periodo de pruebas, habran informes urgentes de error apareciendo de cuando en cuando y
tendramos que estar preparados para tratar con ellos.
CICLOS DE SPRINT VS. CICLOS DE PRUEBAS

Enfoque 2: Desarrollamos cosas nuevas, pero priorizamos el poner en produccin lo que ya est
desarrollado
Cuando acabamos un Sprint comenzamos con el siguiente. Pero
esperamos pasar parte del tiempo del prximo Sprint encontrando errores del
ltimo Sprint. Si el prximo Sprint queda seriamente daado porque hemos
tenido que pasar demasiado tiempo arreglando errores del Sprint anterior,
evaluamos por qu ha ocurrido esto y cmo podemos mejorar la calidad. Nos
aseguramos de que los Sprints son suficientemente largos como para soportar
una cantidad aceptable de correcciones del ltimo Sprint.
CICLOS DE SPRINT VS. CICLOS DE PRUEBAS
Gradualmente, durante un periodo de muchos meses, la cantidad de tiempo que pasamos solucionando
errores de Sprints anteriores fue disminuyendo.
Adicionalmente, fuimos capaces de dedicar menos personas involucradas cuando se producan errores, as que
todo el equipo no tena que ser molestado en cada ocasin. Ahora estamos a un nivel mucho ms aceptable.
CICLOS DE SPRINT VS. CICLOS DE PRUEBAS

Mal enfoque centraos en producir cosas nuevas

NO SOBRECARGUES EL ESLABN MS DBIL DE TU
CADENA

Las pruebas de aceptacin son tu eslabn ms lento. Tienes muy pocos encargados de pruebas o las
pruebas de aceptacin tardan demasiado por la mala calidad del cdigo.
NO SOBRECARGUES EL ESLABN MS DBIL DE TU
CADENA

Digamos que el equipo de pruebas puede probar como mucho 3 funcionalidades a la semana y digamos
que los desarrolladores pueden desarrollar 6 nuevas funcionalidades a la semana.

Sera tentador para los gerentes o Dueos del producto planificar el desarrollo de otras 6 nuevas
funcionalidades.

NO LO HAGAN!
PARA ALIGERAR EL CUELLO DE BOTELLA DE LAS
PRUEBAS

Haz que unos cuantos desarrolladores trabajen como encargados de pruebas.

Implementar herramientas y script que hagan las pruebas ms faciles.
Aadir ms cdigo de pruebas automatizadas
Incrementa la longitud de los Sprints y haz que se incluyan pruebas de aceptacin en los Sprints.
Define algunos Sprints como Sprints de pruebas en las que todo el equipo trabaje como un equipo de
pruebas.
Contratar a mas encargados de pruebas(incluso si eso signifique eliminar desarrolladores)
DE VUELTA A LA REALIDAD

En ocasiones se ha conseguido todo esto y se han obtenido efectos positivos pero aun esta lejos de un
proceso aceptable que asegure la calidad.