Motivación de la presentación

Transcripción

1 Pruebas de Aceptación como conductor del Proceso Software Patricio Letelier 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 2 Patricio Letelier 1

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: 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 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 Pruebas Unitarias Diseño de Pruebas Programación Aplicación de Pruebas 4 Patricio Letelier 2

3 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 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 6 Patricio Letelier 3

4 2 : Pin Ok() 2 : Pin Ok() 2 : Pin Ok() Ejemplo Nombre del Requisito: Retirar dinero 2 : Pin Ok() Pero Descripción narrativa Diagramas de Secuencia Caso de Uso Plantilla Bocetos de IU 7 Ejemplo Diagramas de Secuencia Pruebas de Aceptación Descripción narrativa (breve) Caso de Uso Plantilla Bocetos de IU 8 Patricio Letelier 4

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. 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 9. Excedido tiempo de espera para introducción de acción Ejemplo Descripción narrativa Caso de Uso Pruebas de Aceptación (Sólo identificación) Bocetos de IU 10 Patricio Letelier 5

6 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 Obligar a definir requisitos que sean 5. No disponibilidad de verificables billetes 6. No disponibilidad de Valorar papel para adecuadamente recibo el esfuerzo asociado a la incorporación de un requisito 7. Intento reintegro saldo < cantidad cliente preferencial Negociar con el cliente el alcance del 8. Excedido tiempo de sistema comunicación con sistema central 9. Excedido tiempo de Planificar espera para el desarrollo introducción iterativo de acción e incremental del sistema 10. Guiar a los desarrolladores Identificar oportunidades de reutilización 11 Conclusiones Requisitos y PAs conducen el proceso de desarrollo La 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 12 Patricio Letelier 6

7 RePRIS 13 Patricio Letelier 7