Plan de Pruebas

v 5.0

1. Introducción

1.1 Propósito

El presente plan de pruebas busca estandarizar el proceso de pruebas para el proyecto Link Bridge.
Las fases que engloba son las siguientes:

• Estrategia de pruebas
  • Planificación
  • Definición de recursos
  • Definición de componentes a probar
    
    
• Ejecución de pruebas
  • Seguimiento del procedimiento establecido
  • Manejo de resultados
    
    
• Manejo de pruebas
  • Restricciones del entorno de prueba

1.2 Alcance

Etapa de prueba	Caso de uso	Back / Front	Tipo de Prueba	Herramienta	¿Qué se evalúa?
Unitaria	Desarrollo de una funcionalidad	Back	Automatizada	Sinon y Chai	Servicio, manejo de errores
Integración	Requisitos con restricciones previas	Back	Manual	Herramienta para probar API's (e.g. Postman)	Reglas de negocio
	Todos los elementos de una vista están completos	Front	Manual	Matriz de pruebas	Funcionalidad, usabilidad y diseño
Sistema	Todos los módulos del sistema están completos	Back y Front	Pruebas en voz alta	Matriz de pruebas en voz alta	Funcionalidad del sistema completo
	Todos los módulos del sistema están completos	Back y Front	Pruebas con expertos	Formato pruebas con expertos	Funcionalidad del sistema completo

Consideraciones

• Entiéndase por “desarrollador” como un miembro del equipo que analiza, diseña e implementa un componente del sistema. Cualquier miembro del departamento puede ser un desarrollador.
• Entiéndase por “tester” como un miembro del equipo que se encargará de realizar las pruebas a un componente desarrollado. Cualquier persona del departamento puede ser un tester de cualquier componente.
• Ninguna prueba de backend evalúa diseño o usabilidad.
• Ninguna prueba de frontend evalúa estructura, tipo de dato o la coherencia de los datos.

Asunciones

• La documentación de las pruebas sigue los estándares establecidos en el presente documento.

Riesgos a considerar para el desarrollo de las pruebas

• Arquitectura: Cambio en la infraestructura del cliente
• Schedule: Subestimación de tiempos y costos
• Ciclo de vida: Deuda técnica
• Requerimientos: Requisitos malentendidos por el equipo de desarrollo
• Dependencia: Uso de versión inestable del framework

Nota: Para más información acerca de los planes de mitigación y contingencia sobre los riesgos listados previamente, revisar la Matriz de Riesgos

1.3 Dependencias

• Pruebas Unitarias: Haber terminado al 100% el desarrollo de una funcionalidad de sistema.
• Prueba de Integración: Haber terminado el desarrollo y pruebas unitarias de una historia de usuario.
• Prueba de Sistema: Completar las tareas asociadas a la versión trabajada (MVP o MBI).

2. Requerimientos para Pruebas

Los elementos identificados como objetivos de prueba se enlistan en la Especificación de Requerimientos de Software.
A continuación se presenta lo que será probado:

• Estructura, tipos de dato
• Funcionalidad, diseño
• Reglas de negocio
• Usabilidad
• Funcionalidad del sistema completo

3. Hitos

Etapa	Descripción	Fecha
Creación del Plan de Pruebas	Primer día del proyecto	07/03/2024
Validación del plan con el equipo	Validación de este documento	08/03/2024
Prueba de sistema MVP	Pruebas de integración	08/05/2024
	Pruebas en voz alta	09/05/2024
	Pruebas con expertos	10/05/2024
Prueba de sistema MBI1		22/05/2024
Prueba de sistema MBI2		05/06/2024

4. Estrategia de Pruebas

Objetivo de una prueba	Asegurar el correcto funcionamiento de cada uno de los elementos analizados.
Técnica	Ejecutar cada caso de prueba, utilizando datos válidos e inválidos, para verificar los siguientes puntos:   1. Al utilizar datos válidos, se obtienen los resultados esperados   2. Al utilizar datos inválidos, existen un manejo de errores apropiado   3. Se incluyen notificaciones o mensajes de éxito/error para retroalimentar al usuario   4. Las reglas de negocio son aplicadas apropiadamente en el producto o componente analizado
Criterios de terminación	Todos los defectos identificados han sido tratados. Todas las pruebas planeadas han sido ejecutadas y cuentan con estatus de éxito.
Consideraciones especiales	Ninguna

4.1 Tipos de Pruebas

4.1.1. Pruebas Unitarias

Una prueba unitaria comprueba la funcionalidad de un requisito de sistema. El tester deberá establecer los criterios bajo los que se evaluará un requisito y consultar al desarrollador en caso de necesitar correcciones.

Backend

Para realizar pruebas unitarias en el backend, se utilizarán las librerías Sinon y Chai. El desarrollador será el encargado de diseñar e implementar la prueba automatizada del servicio correspondiente, documentando apropiadamente en el código los escenarios considerados y corrigiendo los defectos identificados durante el proceso.

Para mayor información del uso de la herramienta de testing, referirse a este link.

4.1.2. Pruebas Integración

Las pruebas de integración verifican que todos los componentes de una historia de usuario o un módulo del sistema funcionen correctamente. Son ejecutadas cuando estos componentes ya han sido desarrollados.

El tester deberá crear los casos de prueba y asegurar que todas las pruebas pasen exitosamente, de lo contrario, deberá avisar a los desarrolladores para corregir los errores. Esta fase termina cuando todos los casos de prueba integrales fueron ejecutados y todos los defectos fueron corregidos.

Backend

Las pruebas de integración del backend se realizan por cada requisito de sistema. El tester debe realizar escenarios prueba en donde verifique que solo usuarios autenticados y con privilegios específicos puedan acceder a sus funcionalidades correspondientes. A continuación se presenta una sugerencia para realizar las pruebas.

Entrada

Escenario	Flujos alternos	Parámetros	Resultado esperado	Resultado obtenido/Comentarios	Estatus
N/A	N/A	N/A	N/A	N/A	N/A

Salida

• Documento con el que dar seguimiento a las pruebas desarrolladas.

Frontend

Las pruebas de integración de frontend se hacen por cada vista del sistema. El tester debe realizar escenarios para que los usuarios que tengan roles específicos puedan acceder a ciertas funcionalidades y en caso de que no, sean redirigidos correctamente. A continuación se presenta una vista general del formato usado para realizar las pruebas.

Entrada

Escenario	Flujos alternos	Parámetros	Resultado esperado	Resultado obtenido/Comentarios	Estatus
N/A	N/A	N/A	N/A	N/A	N/A

Salida

• Documento con el que dar seguimiento a las pruebas desarrolladas.

4.1.3 Pruebas de Sistema

Una prueba de sistema valida que la integración de múltiples módulos y componentes individuales del sistema funcione correctamente de manera conjunta. El tester define las pruebas desde la perspectiva del usuario, interactuando con la aplicación mediante la GUI y analizando la salida de dichas interacciones. Esta prueba busca verificar que se cumplan con los requerimientos y las reglas de negocios establecidas. Se harán pruebas en voz alta con el usuario final.

Pruebas en voz alta

La evidencia de pruebas en voz alta será la grabación de la sesión en la que sean llevadas a cabo.

El sistema será proporcionado a los usuarios y, al detectar algún defecto, los desarrolladores acompañando a los usuarios deberán crear un issue en el defect log correspondiente (frontend, backend), identificarlos con el label de "thinking outloud" e indicar que ya se está dando seguimiento al defecto identificado.

Se recomienda enlistar las tareas que el usuario puede realizar para encaminar la prueba en caso de necesitarse. El siguiente documento presenta una alternativa para realizarlo: Plantilla pruebas en voz alta.

Pruebas con expertos

Las pruebas con expertos se llevarán a cabo haciendo uso de la siguiente plantilla.
Se sugiere que los desarrolladores identifiquen escenarios asociados a los RFs trabajados.

Para cada prueba realizada, se registrarán los comentarios o resultados obtenidos. En caso de no pasar, los desarrolladores acompañando a los usuarios expertos deberán crear un issue en el defect log correspondiente (frontend, backend), identificarlos con el label de "experts" e indicar que ya se está dando seguimiento al defecto identificado.

Entrada

Documento con actividades para el usuario experto.

Test Id	Escenario	Resultado esperado	Resultado obtenido/Comentarios	Fecha	Estatus	Seguimiento
N/A	N/A	N/A	N/A	N/A	N/A	[]

Salida

• Documento con la retroalimentación del usuario.
• Issues para dar seguimiento a los defectos identificados.

4.2 Herramientas

Las siguientes herramientas serán utilizadas para este proyecto:

Backend

• Node JS
• Express
• TypeScript
• Prisma
• SQL derivative DB
• Sinon
• Chai

Frontend

• React con un framework de diseño
• TypeScript
• MUI

5. Requerimientos no funcionales

Todas las funcionalidades serán desarrolladas siguiendo los requerimientos no funcionales listados en la Especificación de Requerimientos de Software. El encargado de probar una historia de usuario deberá identificar los requerimientos no funcionales a los que está alineada y verificar su cumplimiento.

Control de cambios

Versión	Cambio realizado	Análisis	Autor	Revisor(es)	Fecha de cambio
v 1.0	Entrega para plan de proyecto	N/A	Ian Padrón, Armando Rosas, Ramona Nájera	---	04/03/2024
v 2.0	Añadir Control de cambios	N/A	Olimpia García	Ramona Nájera	08/04/2024
v 3.0	Actualización herramientas de prueba	N/A	Armando Rosas, Ramona Nájera	---	21/04/2024
v 4.0	Añadir pruebas en voz alta y para expertos, actualizar RNFs	N/A	Ramona Nájera, Armando Rosas	---	08/05/2024
v 5.0	Actualizar formato pruebas de integración	Se añaden flujos alternos para generar pruebas enfocadas en identificar el límite de un escenario	Olimpia García	Ramona Nájera	27/05/2024