PRUEBAS

Estas transparencias están basadas en las desarrolladas por Ammann & Offutt como
acompañamiento de su libro Introduction to Software Testing (2nd Edition)
 EL MAYOR ÉNFASIS EN LAS
PRUEBAS
• La filosofía de los métodos tradicionales de desarrollo de
software indican que hay que hacer:
• Análisis inicial
• Modelado extensivo Se debe revisar más trabajo

• Revelar problemas lo antes posible El problema de raíz es más difícil de

encontrar
Costo
Delta

2
Tiempo
Original Revision
 SUPUESTOS TRADICIONALES

1. El modelado y el análisis pueden identificar problemas

potenciales al principio del desarrollo.
2. Los ahorros implícitos en la curva de costo de cambio
justifican el costo de modelado y análisis durante la vida del
proyecto.
• Esto es cierto si los requisitos son siempre completos y actuales.
• Los humanos son naturalmente buenos para aproximarse y son
cambiantes.
• Estas dos suposiciones han hecho que la Ingeniería de Software
sea frustrante y difícil durante décadas.

3
 ¿POR QUÉ SER METODOLOGÍAS
ÁGILES?
• Los métodos ágiles comienzan reconociendo que ninguna suposición es válida
para muchos proyectos de software actuales.
• Los ingenieros de software no son buenos para desarrollar requisitos
• No anticipamos muchos cambios.
• Muchos de los cambios que anticipamos no son necesarios.
• Los requisitos (y otros "artefactos no ejecutables") tienden a quedar obsoletos
muy rápidamente.
• Rara vez nos tomamos el tiempo para actualizarlos.
• Muchos proyectos de software actuales cambian continuamente.
• Los métodos ágiles esperan que el software comience poco a poco y
evolucione con el tiempo.

4
 APOYO AL DISEÑO EVOLUTIVO
El consejo de diseño tradicional dice anticiparse a los cambio.
Los diseñadores a menudo anticipan cambios que no suceden.

Anticipar el
cambio

Anticipar Evolución del

cambiar eso no Diseño
sucede
No anticipar el
cambio

Tanto los cambios anticipados como los imprevistos afectan al 5

diseño
 UNA VISIÓN LIMITADA DE LA
CORRECCIÓN
• En los métodos tradicionales, tratamos de definir todo el comportamiento
correcto completamente, al principio.
• ¿Qué es la corrección?
• ¿La "corrección" significa algo en grandes productos de ingeniería?
• La gente es MUY MALA para definir completamente la corrección
• En los métodos ágiles, redefinimos la corrección para que sea relativa a
un conjunto específico de pruebas.
• Si el software se comporta correctamente en las pruebas, es "correcto“.
• En lugar de definir todos los comportamientos, demostramos algunos
comportamientos.
• Los matemáticos pueden sentirse decepcionados por la falta de completitud.
• ¡Pero los ingenieros de software no son matemáticos!

6
 LOS ARNESES DE PRUEBA
VERIFICAN LA CORRECCIÓN
• Un arnés de prueba ejecuta todas las pruebas automatizadas de manera
eficiente e informa los resultados a los desarrolladores
• Las pruebas deben ser automatizadas.
• La automatización de pruebas es un requisito previo para el desarrollo
controlado por pruebas.

• Cada prueba debe incluir un oráculo de prueba que pueda evaluar si esa
prueba se ejecutó correctamente.
• Las pruebas reemplazan los requisitos.
• Las pruebas deben ser de alta calidad y deben ejecutarse rápidamente.
• Ejecutamos pruebas cada vez que realizamos un cambio en el software

7
 INTEGRACIÓN CONTINUA

• Los métodos ágiles funcionan mejor cuando la versión actual del software
se puede ejecutar en todas las pruebas en cualquier momento.
• Un servidor de integración continua reconstruye el sistema, devuelve y
vuelve a verificar las pruebas cada vez que se registra una actualización
en el repositorio.
• Los errores se detectan antes.
• Otros desarrolladores son conscientes de los cambios temprano.
• La reconstrucción y la re-verificación deben realizarse lo antes posible
• Por lo tanto, las pruebas deben ejecutarse rápidamente.
• Un servidor de integración continua no solo ejecuta pruebas, sino que decide
si un sistema modificado sigue siendo correcto.

8
LA INTEGRACIÓN CONTINUA REDUCE EL
RIESGO

Inventario de no integrados work

Funcionalidad Integrada
Funcionalidad Total

¡La funcionalidad no integrada es peligrosa! 9

 PRUEBAS DE SISTEMAS EN
MÉTODOS ÁGILES
Los tester tradicionales a menudo
diseñan pruebas de sistema a partir
de requisitos

Requerimientos

?
Requerimientos Pruebas
del
Requerimientos sistema

Pero... ¿Qué pasa si no hay

documentos de requisitos
tradicionales? 10
 HISTORIAS DE USUARIO
Una historia de usuario son unas pocas oraciones que capturan
lo que un usuario hará con el software.

Retirar dinero de la El agente ve una lista de los

cuenta corriente solicitantes de la entrevista de
hoy
El técnico de soporte ve el
historial del cliente bajo
demanda

• En el idioma del usuario final

• Por lo general, de pequeña escala con pocos detalles 11

• No archivado
 PRUEBAS DE ACEPTACIÓN EN
MÉTODOS ÁGILES
Historia de Test de TDD Test
Aceptación
usuario
(Fallo)
1

Cambiar
Archivo de software &
Tests Refactorizar
Test de
Aceptación
(Aprobado) Continúe agregando
pruebas TDD hasta que
pase la prueba de TDD Test
aceptación 2
Cambiar
software &
La refactorización
12 evita
refactorizar
la deuda de
mantenimiento
AGREGAR PRUEBAS A SISTEMAS
EXISTENTES
• La mayor parte del software actual es heredado
• Sin pruebas heredadas
• Requisitos heredados irremediablemente obsoletos
• Los diseños, si alguna vez fueron escritos, perdidos

• Las empresas a veces optan por no cambiar el software por miedo al

fracaso.
• ¿Cómo aplicar TDD al software heredado sin pruebas?
• ¿Crear un conjunto de pruebas completamente nuevo?
• ¡demasiado caro!
• ¿No las hago?
• un proyecto mixto es inmanejable

13
 TDD INCREMENTAL

• Cuando se realiza un cambio, agregue pruebas TDD solo para

ese cambio.
• Refactorizar.

• A medida que avanza el proyecto, la colección de pruebas TDD

continúa creciendo.
• Eventualmente, el software tendrá fuertes pruebas TDD.

14
 EL DÉFICIT DE PRUEBAS

• ¿Las pruebas TDD (de aceptación o de otro tipo) prueban bien

el software?
• ¿Las pruebas logran una buena cobertura en el código?
• ¿Las pruebas encuentran la mayoría de las fallas?
• Si el software pasa, ¿debería la gerencia sentirse segura de que
el software es confiable?
NO!

15
 ¿POR QUÉ NO?

• La mayoría de las pruebas ágiles se centran en “buenos

caminos”.
• Qué debería suceder bajo el uso normal

• A menudo se pierden cosas como:

• Rutas de usuario confusas.
• Rutas de acceso de usuario creativo.
• Rutas de acceso de usuario malintencionadas.

• La literatura de métodos ágiles no da mucha orientación.

16
 DISEÑA BUENAS PRUEBAS

• Utilice un enfoque basado en el ser humano.

• Crear historias de usuario adicionales que describan
rutas para fallos.
• ¿Cómo sabes cuándo has terminado?
• Algunas personas son muy buenas en esto, otras
son malas, y es difícil enseñar

• Usar modelos y criterios

• Modelar el dominio de entrada para diseñar
pruebas
• Modelar el comportamiento del software con
gráficos, lógica o gramática
• Una sensación de finalización incorporada
• Mucho más fácil de enseñar: ingeniería 17
• Requiere conocimientos matemáticos discretos