El objetivo de este proceso es que el usuario final haga una prueba de la aplicación antes de que la release sea liberada.

Para tener un control de lo que se quiere probar se realizará un plan de pruebas genérico, de las tareas relevantes a probar. Esto no quiere decir que el usuario, pruebe más cosas que él considere necesario o haga pruebas aleatorias, pero es para reflejar lo que el usuario NO se debe de olvidar de probar.

Una vez hecho el plan se acordará un día para hacer las pruebas con el cliente o bien para que el cliente las haga, y una vez realizadas, los cambios o errores detectados serán apuntados en el documento de resultado de pruebas.

Esto puede llevar cambios en los requisitos, diseño y componentes. Es importante tener en cuenta que para cambios relevantes deberemos de dirigirnos a la disciplina de Gestión de la configuración en su proceso “Control de Cambios” porque puede afectar a la fecha de entrega de la release y a su contenido.

Los siguientes son los roles participantes en este proceso:

Para garantizar que el usuario prueba la funcionalidad correctamente, elaboraremos un plan de pruebas a partir de los requisitos funcionales, que cubran el número máximo de casos de prueba.

Este documento una vez realizadas las pruebas y pasadas satisfactoriamente, deberá de ser firmado por el usuario, garantizando que se aceptó el software.

Pasos a ejecutar:

Para esta tarea se deben de dar de alta un JIRA con los siguientes datos

2.1. Iniciar la creación de un nuevo Documento de Casos de Prueba de Usuario.

2.2. Escribir las siguientes secciones del documento:

• “2.2.1 Introducción”, en la que se debe describir de manera resumida el alcance del documento de prueba.
• “2.2.2 Definicion de los casos de prueba Por cada caso de prueba que se quiera realizar escribir apartado una tabla como la que aparece en la plantilla en la que se especifican
  • Codigo: codigo identificativo para su posterior especificación.
  • Descripcion: descripción del caso de prueba.
  • Pasos: pantallas que se irán recorriendo y valores que se insertan a alto nivel.
  • Resultado Esperado: resultado esperado de la ejecución.
  • Anexo: codigo de anexo relacionado del apartado anexo , (puede ser una captura de pantalla explicativa).
  • Resultado:dejarlo vacio. será rellenado por el usuario.
• ”2.2.3 Anexos Anexos necesarios para la explicación del Caso de Prueba del Usuario.

Una vez pasadas las pruebas funcionales publicaremos la aplicación al entorno donde el usuario pueda ejecutar las pruebas de usuario (PREPRODUCCION), para que de el visto bueno, antes de pasar a producción.

Existen dos modalidades para pasar estas pruebas:

• Presenciales. Se concierta una reunión con el usuario para enseñarle la aplicación.

• No Presenciales. El usuario accede a la aplicación y la prueba sin estar en presencia de ningún componente del desarrollo de la aplicación. Puede haber soporte telefónico.

En ambos casos es OBLIGATORIO que el usuario rellene el documento de “Casos de Pruebas de Usuario”, en los que se especifica la conformidad con el software entregado. Si no no se considerarán las pruebas pasadas.

Pasos a ejecutar:

Para esta tarea se deben de dar de alta un JIRA con los siguientes datos

En caso de que sean presenciales, nos aseguraremos que

• se sigan todos los casos de pruebas del Documento de Casos de Prueba de Usuario .

En ambos casos habrá que garantizar que el usuario halla rellenado los campos del Documento de Casos de Prueba de Usuario :

• 2.1Por cada tabla de Caso de Prueba del punto 2. Definición de Casos de Prueba rellenar el campo
  • Resultado con un OK o FALLO según el resultado observado. En caso de fallo explicar las razones del fallo.
• 2.2 Aprobacion de la Aplicacion marcado un “S” en caso de que no haya habido ningun error.
• 2.3 Firma del Usuario

Una vez pasadas las pruebas, se atenderán a las no pasadas para dar de alta los JIRAS para que los desarrodores hagan los cambios pertinentes o sean evaluados en la disciplina “Gestión del cambio”.

Las métricas del proyecto se guardarán dentro de la carpeta del proyecto en Proyecto/Documentacion/1.Gestionproyecto/1.4.Metricas. Las métricas de este proceso en concreto se almacenan en la Hoja DSP.

Numero de Casos de Prueba de Usuario escritos para el proyecto.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Despliegue-DSP-Realizar Pruebas de Usuario
• label = DCP

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Despliegue-DSP-Realizar Pruebas de Usuario
• label = SCP

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira