Pruebas de Aceptación como Pruebas de Aceptación como

Pruebas de Aceptación como
conductor del Proceso Software
Patricio Letelier
[email protected]
Departamento 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)
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
© Patricio Letelier
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
2
1
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,
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
Un requisito tiene una o más PAs asociadas
Las PAs cubren desde escenarios típicos/frecuentes
hasta los más excepcionales
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
3
PAs … ¿Cuándo?
“Modelo V” para pruebas
Especificación
de Requisitos
Pruebas de
Aceptación
Análisis de
Requisitos
Pruebas de
Sistema
Diseño de
Arquitectura
Pruebas de
Integración
Diseño de
Módulos
Diseño de Pruebas
© Patricio Letelier
www.dsic.upv.es/~letelier
Pruebas
Unitarias
Programación
Aplicación de Pruebas
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
4
2
Aprovechamiento de las PAs
Adicional a su propósito fundamental, las PAs pueden
rentabilizarse usándose para:
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
Planificar el desarrollo iterativo e incremental del
sistema
Guiar a los desarrolladores
Identificar oportunidades de reutilización
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
5
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)
Combinación de los anteriores
© Patricio Letelier
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
6
3
Ejemplo
Nombre del Requisito: Retirar dinero
client
: TMDistributor
client
1 : Pin()
: TMDistributor
client
1 : Pin()
: TMDistributor
client
2 : Pin Ok() 1 : Pin()
: TMDistributor
client
3 : Cantidad()
2 : Pin Ok() 1 : Pin()
☺ Pero …
: TMDistributor
client
3 : Cantidad()
2 : Pin Ok() 1 : Pin()
3 : Cantidad()
2 : Pin Ok()
4 : Saldo insuficiente()
☺
: TMDistributor
1 : Pin()
3 : Cantidad()
2 : Pin Ok()
4 : Saldo insuficiente()
Descripción narrativa
3 : Cantidad()
2 : Pin Ok()
4 : Saldo insuficiente()
3 : Cantidad()
4 : Saldo insuficiente()
4 : Saldo insuficiente()
4 : Saldo insuficiente()
☺
Diagramas de Secuencia
Caso de Uso
Bocetos de IU
Plantilla
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
7
… Ejemplo
client
: TMDistributor
client
1 : Pin()
: TMDistributor
client
1 : Pin()
: TMDistributor
client
2 : Pin Ok() 1 : Pin()
: TMDistributor
client
3 : Cantidad()
2 : Pin Ok() 1 : Pin()
: TMDistributor
client
3 : Cantidad()
2 : Pin Ok() 1 : Pin()
3 : Cantidad()
4 : Saldo insuficiente() 2 : Pin Ok()
: TMDistributor
1 : Pin()
Descripción narrativa (breve)
3 : Cantidad()
2 : Pin Ok()
4 : Saldo insuficiente()
3 : Cantidad()
4 : Saldo insuficiente() 2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente()
Pruebas de Aceptación
4 : Saldo insuficiente()
4 : Saldo insuficiente()
Diagramas
de Secuencia
Caso de Uso
Plantilla
© Patricio Letelier
www.dsic.upv.es/~letelier
Bocetos de IU
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
8
4
… Ejemplo
Identificación de Pruebas de Aceptación
1.
Reintegro usando cantidades predefinidas
2.
Reintegro con cantidad introducida por cliente
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
8.
Excedido tiempo de comunicación con sistema central
9.
Excedido tiempo de espera para introducción de acción
10.
…
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
9
… Ejemplo
Descripción narrativa
Caso de Uso
Pruebas de Aceptación
(Sólo identificación)
Bocetos de IU
© Patricio Letelier
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
10
5
… Ejemplo
Identificación de Pruebas de Aceptación
1.
Reintegro usando cantidades predefinidas
2.
Reintegro con cantidad introducida por cliente
3.
Intento reintegro saldo < cantidad
4.
5.
Cancelación de operación
Obligar a definir requisitos que sean
No disponibilidad deverificables
billetes
6.
adecuadamente
el esfuerzo
No disponibilidad deValorar
papel para
recibo
7.
Intento reintegro saldo < cantidad cliente preferencial
8
8.
Excedido tiempo desistema
comunicación con sistema central
9.
el desarrollo
iterativo
e
Excedido tiempo dePlanificar
espera para
introducción
de acción
asociado a la incorporación de un requisito
Negociar con el cliente el alcance del
10.
…
incremental del sistema
Guiar a los desarrolladores
Identificar oportunidades de reutilización
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
11
Conclusiones
Requisitos y PAs conducen el proceso de
desarrollo
La “cultura”
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
ajeno a otros inconvenientes
© Patricio Letelier
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
12
6
RePRIS
http://in2test.lsi.uniovi.es/repris/
© Patricio Letelier
www.dsic.upv.es/~letelier
Jornadas sobre Testeo de Software,2, 3 y 4 de Mayo de 2007, ITI – UPV, Valencia
13
7