Plan de pruebas

1. © Patricio Letelier 1
Pruebas de Aceptación comoPruebas de Aceptación comoPruebas de Aceptación comoPruebas de Aceptación como
conductor del Proceso Softwareconductor del Proceso Software
Patricio Letelier
letelier@dsic.upv.es
Departamento Sistemas Informáticos y ComputaciónDepartamento Sistemas Informáticos y Computación
Universidad Politécnica de Valencia
Motivación de la presentación
Dificultades para la introducción de una “cultura”,
disciplina y prácticas de pruebas en un equipo de
desarrollo
Obstáculos o Malas estrategias
Carencia de un proceso de desarrollo que integre las
actividades de pruebas
Sobrevaloración de la automatización de las pruebas
como objetivo inmediato (o único)
2www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
No “Rentabilizar” el esfuerzo invertido en pruebas
Estrategia de implantación de una “cultura” de pruebas a
partir del aprovechamiento de las Pruebas de Aceptación

2. © Patricio Letelier 2
Prueba de Aceptación
“Una PA tiene como propósito demostrar al cliente el
cumplimiento de un requisito del software”
Precisando un poco más una PA:Precisando un poco más, una PA:
Describe un escenario (secuencia de pasos) de
ejecución o uso del sistema desde la perspectiva del
cliente
Puede estar asociada a requisitos funcionales o no
funcionales
3www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
Un requisito tiene una o más PAs asociadas
Las PAs cubren desde escenarios típicos/frecuentes
hasta los más excepcionales
“Modelo V” para pruebas
PAs … ¿Cuándo?
Especificación
de Requisitos
Pruebas de
Aceptación
Análisis de
Requisitos
Diseño de
Arquitectura
Pruebas de
Integración
Pruebas de
Sistema
4www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
Diseño de
Módulos
Programación
Pruebas
Unitarias
Diseño de Pruebas Aplicación de Pruebas

3. © Patricio Letelier 3
Aprovechamiento de las PAs
Adicional a su propósito fundamental, las PAs pueden
rentabilizarse usándose para:
Obligar a definir requisitos que sean verificablesObligar a definir requisitos que sean verificables
Valorar adecuadamente el esfuerzo asociado a la
incorporación de un requisito
Negociar con el cliente el alcance del sistema
Planificar el desarrollo iterativo e incremental del
sistema
5www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
Guiar a los desarrolladores
Identificar oportunidades de reutilización
Requisitos versus Pruebas de Aceptación
“El proceso de desarrollo debe estar dirigido por los
requisitos”. Obvio puesto que los requisitos son el
objetivo a cumplir, sin embargo, …
¿Popularmente cómo se especifican los requisitos?
Textualmente
UML (Diagramas de Casos de Uso y otros diagramas)
Plantillas o fichas
Interfaces de usuario (bocetos)
6www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
Combinación de los anteriores

4. © Patricio Letelier 4
Ejemplo
Nombre del Requisito: Retirar dinero
client : TMDistributor
1 : Pin()
2 : Pin Ok()
client : TMDistributor
1 : Pin()
client : TMDistributor
1 : Pin()
client : TMDistributor
☺ Pero …
3 : Cantidad()
4 : Saldo insuficiente()
2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente()
2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente()
1 : Pin()
2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente()
client : TMDistributor
1 : Pin()
2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente()
client : TMDistributor
1 : Pin()
2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente()
☺
Descripción narrativa
Diagramas de Secuencia
Caso de Uso
☺
7www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
Plantilla Bocetos de IU
Caso de Uso
… Ejemplo
client : TMDistributor
1 : Pin()
2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente()
client : TMDistributor
1 : Pin()
2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente()
client : TMDistributor
1 : Pin()
2 : Pin Ok()
3 : Cantidad()
client : TMDistributor
1 : Pin()
2 : Pin Ok()
3 : Cantidad()
client : TMDistributor
1 : Pin()
2 : Pin Ok()
client : TMDistributor
1 : Pin()
Descripción narrativa (breve)4 : Saldo insuficiente()
4 : Saldo insuficiente()
3 : Cantidad()
4 : Saldo insuficiente()
2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente()
Descripción narrativa (breve)
Diagramas
de Secuencia
Caso de Uso
Pruebas de Aceptación
8www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
Plantilla Bocetos de IU

5. © Patricio Letelier 5
Identificación de Pruebas de Aceptación
1. Reintegro usando cantidades predefinidas
2. Reintegro con cantidad introducida por cliente
… Ejemplo
3. Intento reintegro saldo < cantidad
4. Cancelación de operación
5. No disponibilidad de billetes
6. No disponibilidad de papel para recibo
7. Intento reintegro saldo < cantidad con cliente preferencial
8 Excedido tiempo de comunicación con sistema central
9www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
8. Excedido tiempo de comunicación con sistema central
9. Excedido tiempo de espera para introducción de acción
10. …
… Ejemplo
Descripción narrativa
Caso de Uso
10www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
Bocetos de IU
Pruebas de Aceptación
(Sólo identificación)

6. © Patricio Letelier 6
Identificación de Pruebas de Aceptación
1. Reintegro usando cantidades predefinidas
2. Reintegro con cantidad introducida por cliente
… Ejemplo
3. Intento reintegro saldo < cantidad
4. Cancelación de operación
5. No disponibilidad de billetes
6. No disponibilidad de papel para recibo
7. Intento reintegro saldo < cantidad cliente preferencial
8 Excedido tiempo de comunicación con sistema central
Obligar a definir requisitos que sean
verificables
Valorar adecuadamente el esfuerzo
asociado a la incorporación de un requisito
Negociar con el cliente el alcance del
sistema
11www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
8. Excedido tiempo de comunicación con sistema central
9. Excedido tiempo de espera para introducción de acción
10. …
sistema
Planificar el desarrollo iterativo e
incremental del sistema
Guiar a los desarrolladores
Identificar oportunidades de reutilización
Conclusiones
Requisitos y PAs conducen el proceso de
desarrollo
La “cultura” de pruebas puede introducirse deLa cultura de pruebas puede introducirse de
manera efectiva y “rentable” a partir de pruebas
de aceptación
Enfoque validado en contexto académico e
industrial
La automatización como paso siguiente, y no
12www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
ajeno a otros inconvenientes

7. © Patricio Letelier 7
RePRISRePRIS
http://in2test.lsi.uniovi.es/repris/
13www.dsic.upv.es/~letelier Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia