HU Seleccionada para el desarrollo e implementación:

Utilizando la técnica de Planning Poker de la entrega pasada y conversando sobre cual se debería de implementar, se llegó a la conclusión que la HU a desarrollar para este hito es la HU_12 - P38: Firma digital.

Desglose de tareas para la implementación de la HU_12 - P38: Firma Digital

Se expresará a continuación el desglose de tareas que fue utilizado para la implementación de la HU_12:

• Agregar a la base de datos una columna para la autentificación de PIN.

• El modelo tiene que poder:

  • Registrar un PIN autentificador para cada usuario de la página que lo necesite.

  • Comprobar si se ingresó el PIN correcto creado y perteneciente del usuario.

• Tener un front donde se pueda ingresar el código autenticador (PIN) por primera vez para convertirlo en PIN personal.

• Poder recuperar desde el front el PIN y guardarlo en el modelo.

• Implementar el uso del autenticador de PIN donde sea necesario corroborando con el modelo si el PIN ingresado es correcto.

Todas estas tareas se realizaron en orden de arriba hacia abajo, concluyendo con la historia de usuario terminada y funcional, conllevando unas estimadas 6-7 horas de trabajo en su implementación.

Pruebas Unitarias

Para las siguientes pruebas unitarias consideraremos las siguientes dos historias de usuario para los endpoints funcionalmente activos:

• HU_9 - P01: Carga de documentos personales.

• HU_12 - P38: Firma Digital.

Con estas dos historias de usuario se desglosarán los siguientes casos de prueba:

• Casos 1 y 2, pertenecientes a la historia de usuario HU_9:

  • 1) Caso de éxito (Clase de equivalencia válida): Enviar el formulario con todos los documentos obligatorios requeridos, esperamos un código 200 (OK).

  • 2) Caso de error (Clase de equivalencia inválida): Intentar enviar la solicitud omitiendo un documento crítico, como por ejemplo no enviar la imagen trasera del carnet, esperamos que el sistema rechace la petición retornando un error.

• Casos 3 y 4, pertenecientes a la historia de usuario HU_12:

  • 3) Caso de éxito (Valor frontera válido): Enviar el RUT del usuario y el PIN con la longitud y formato exacto requerido (6 numeros), esperamos que el sistema lo valide y retorne un código 200 (OK) con la confirmación.

  • 4) Caso de error (Valor frontera inválido): Enviar el RUT y un PIN con una longitud insuficiente, por ejemplo 5 numeros en lugar de 6, esperamos que el sistema lo intercepte antes de consultar la base de datos y retorne un error de validación (código 400 Bad Request) indicando que el código debe tener exactamente 6 numeros.

Resultados de las pruebas

A continuación se demostrarán los resultados de los casos de prueba

Tablas