Pruebas

ENTRADAS

1- DESCRIPCION DEL EQUIPO XP

Encargado de Seguimiento (Tracker): 
◦ Recoge, analiza y publica información sobre la marcha del proyecto sin afectar demasiado el proceso.
◦ Supervisa el cumplimiento de la estimaciones en cada iteración.
◦ Informa sobre la marcha de la iteración en curso.
◦ Controla la marcha de las pruebas funcionales, de los errores reportados, de las responsabilidades aceptadas y de las prueba añadidas por los errores encontrados.

Entrenador (Coach): 
◦ Experto en XP.
◦ Responsable del proceso en su conjunto.
◦ Identifica las desviaciones y reclama atención sobre las mismas.
◦ Guía al grupo de forma indirecta (sin dañar su seguridad ni confianza).
◦ Interviene directamente si es necesario.
◦ Atajar rápidamente el problema.

Consultor: 
◦ Apoya al equipo XP en cuestiones puntuales.

Jefe del Proyecto: 
◦ Favorece la relación entre usuarios y desarrolladores.
◦ Confía en el equipo XP.
◦ Cubre las necesidades del equipo XP.
◦ Asegura que alcanza sus objetivos. 

2- EQUIPO XP

Cliente: Cesar Inga

Encargado de Pruebas: Taquiri Palomino Eudis

Encargado de Seguimiento(Tracker): Anaya Yaranga Juan

Entrenador (Coach): Rojas Cule Denis

Consultor: Arqque Pantigozo

Programadores:

• Escalante Gomez Robert Blas
• Perez Leyva Luis
• La madrid Martinez Ayrton
• Vasquez Pérez Salvador
• Gutierrez Chura Luis

3- HISTORIAS DE USUARIOS Y TAREAS XP

Historias del Usuario (User-Stories)

◦ Establecen los requisitos del cliente
◦ Trozos de funcionalidad que aportan valor
◦ Se les asignan tareas de programación con un nº de horas de desarrollo
◦ Las establece el cliente
◦ Son la base para las pruebas funcionales

Tareas de ingeniería

Usadas para describir tareas que realizan el proyecto. Deben tener relación con una Historia de Usuario.

HERRAMIENTAS

1- PRUEBA UNITARIA

Una pruebas unitaria es una pieza de código escrita por un desarrollador que “ejercita” una muy pequeña área específica de la funcionalidad, en el código que se está probando.

En otras palabras, una prueba unitaria es realizada para demostrar que la pieza de código haga lo que el desarrollador piense que debería hacer.

2- PRUEBAS FUNCIONALES

Se entiende como las Funcionalidades del Sistema cómo “lo que el sistema hace”. Las Funcionalidades pueden estar descritas en las especificaciones de requerimientos, especificaciones funcionales, casos de uso e inclusive no estar documentadas. Los casos de prueba se definen a partir de estas funciones o características, así como su interoperabilidad entre sistemas.

MODULO DE PAGOS

MODULO DE REPORTES

3- PRUEBA DE REGRESIÓN

Determinar si los cambios recientes en una parte de la aplicación tienen efecto adverso en otras partes. En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante la corrección de errores , mantenimiento o desarrollo de la nueva versión del sistema buscando efectos adversos en otras partes.

SALIDAS

1- PRUEBAS DE ACEPTACIÓN

Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario.

El objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento.