Plan de Pruebas
v 5.0
1. Introducción
El siguiente plan de pruebas busca estandarizar el proceso de pruebas para el proyecto de Talent Dot. El plan se desenvuelve de la siguiente manera:
1.1 Propósito
- 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 | Tipo de Prueba | ¿Qué se evalúa? |
|---|---|---|---|
| Unitaria | Desarrollo de funcionalidad específica | Automatizada | Validación de lógica de negocio, manejo de errores |
| Integración | Requisitos con restricciones previas | Manual | Validación de integración, interoperabilidad |
| Cuando todos los elementos de una vista estén completos | Manual | Usabilidad y reglas de negocio | |
| Voz alta | Cuando el requerimiento haya pasado la prueba de integración | Pruebas en voz alta | Usabilidad |
| Sistema | Funcionalidades principales del sistema | Pruebas en voz alta | Rendimiento, escalabilidad |
| Escenario | Simulación de situaciones específicas | Manual | Flujo principal y alternos |
Consideraciones
- 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
- El desarrollador no puede realizar pruebas del requerimiento que desarrolló.
- Ningún integrante del equipo TalentDot puede ejecutar pruebas en voz alta.
- La documentación de las pruebas sigue los estándares establecidos en el 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
1.3 Dependencias
- Pruebas Unitarias: Haber terminado al 100% el desarrollo de un requerimiento de sistema.
- Prueba de Integración: Haber terminado el desarrollo y pruebas unitarias de una historia de usuario.
- Prueba en Voz alta: Haber terminado las pruebas de integración de una historia de usuario.
- Prueba de Sistema: Completar las tareas asociadas a la versión trabajada (MVP o MBI).
- Prueba de Escenarios: Árboles de decisiones completos.
2. Requerimientos para Pruebas
La lista que se presenta en la especificación de requerimientos de software identifica los elementos (requerimientos funcionales y no funcionales) que han sido identificados como objetivo de prueba. Esta lista representa lo que será probado.
3. Milestones
| 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 1 | MVP | 10/05/2024 |
| Prueba de sistema 2 | MBI 1 | 24/05/2024 |
| Prueba de sistema 3 | MBI 2 | 07/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 notificaciones o mensajes de error que den retroalimentación al usuario 3. 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 fueron ejecutadas y cuentan con estatus de éxito |
| Consideraciones especiales | Ninguna |
4.1 Tipos de Pruebas
4.1.1. Pruebas Unitarias
Descripción
Una prueba unitaria comprueba el funcionamiento correcto de un requisito de sistema. El tester deberá diseñar las pruebas usando la "unittest library" de python, proporcionado por Odoo. Posteriormente deberá ejecutar las pruebas y avisar al desarrollador en caso de que se tengan que hacer correcciones.
Para mayor información del uso de la herramienta de testing referirse a este Link
4.1.2. Pruebas Integración
Descripción
Una prueba de integración ayuda a verificar que todos los componentes integrados funcionen correctamente, Son ejecutadas cuando todos los componentes de una historia de usuario o vista estén desarrollados. El tester deberá seguir todos los casos de prueba y asegurar que todas las pruebas pasaron 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 cerrados.
Hacer uso de esta Plantilla
Entrada
| Test Id | Escenario | Parametros | Resultado Esperado | Resultado Obtenido | Fecha Iteración "1 a N" | Estatus |
|---|---|---|---|---|---|---|
| RF1.1 | N/A | N/A | N/A | N/A | N/A | N/A |
| RF1.2 | N/A | N/A | N/A | N/A | N/A | N/A |
| RF1.3 | N/A | N/A | N/A | N/A | N/A | N/A |
| RF1.4 | N/A | N/A | N/A | N/A | N/A | N/A |
Salida
Plantilla de pruebas de integración documentadas.
4.1.3 Pruebas en Voz Alta
Descripción
Una prueba en voz alta es una técnica de prueba de software que se utiliza para evaluar la usabilidad de un producto. El tester deberá seguir los casos de prueba y asegurar que todas las pruebas pasaron 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 cerrados.
Hacer uso de esta Plantilla
Entrada
| Test Id | Escenario / Condición | Resultado Obtenido | Estatus |
|---|---|---|---|
| RF1.1 | N/A | N/A | N/A |
| RF1.2 | N/A | N/A | N/A |
| RF1.3 | N/A | N/A | N/A |
| RF1.4 | N/A | N/A | N/A |
4.1.4 Pruebas de Sistema
Descripción
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.
Hacer uso de esta Plantilla
Entrada
| Test Id. | Escenario / Condición | Resultado Obtenido | Evidencia |
|---|---|---|---|
| RF1.1S | N/A | N/A | N/A |
| RF1.2S | N/A | N/A | N/A |
| RF1.3S | N/A | N/A | N/A |
| RF1.4S | N/A | N/A | N/A |
Salida
Plantilla de pruebas de sistema documentadas.
4.1.5 Pruebas de Escenarios
Descripción
Las pruebas de escenarios simulan situaciones específicas que los usuarios pueden encontrar al interactuar con el software. Estas pruebas se enfocan en validar que el software cumpla con los requisitos funcionales en contextos del mundo real. Se diseñan casos de prueba basados en escenarios de uso identificados previamente y se ejecutan para evaluar el comportamiento del software en cada situación. Los escenarios de uso pueden ser tanto normales como excepcionales, estos estan basados en el árbol de decisiones diseñado previamente.
Hacer uso de esta Plantilla y de los Árboles de decisiones
Entrada
| Escenario de Uso | Escenario | Resultado Esperado | Resultado Obtenido | Estatus |
|---|---|---|---|---|
| RF1 Escenario 1 | N/A | N/A | N/A | N/A |
| RF1 Escenario 2 | N/A | N/A | N/A | N/A |
| RF1 Escenario 3 | N/A | N/A | N/A | N/A |
| RF1 Escenario N | N/A | N/A | N/A | N/A |
Salida
Plantilla de pruebas de escenarios documentadas.
4.2 Herramientas
Las siguientes herramientas serán utilizadas para este proyecto:
| Tipo de prueba | Herramienta |
|---|---|
| Unitarias | Odoo python unit tests |
| Integración | Plantilla |
| Voz Alta | Plantilla |
| Sistema | Plantilla |
| Escenarios | Plantilla Árboles de decisiones |
| Versión | Cambio | Análisis | Autor del cambio | Revisor(es) | Fecha de cambio |
|---|---|---|---|---|---|
| v 1.0 | Creado | N/A | Diego Vega, Ricardo Rosales | Alejandra Cabrera | 06/03/2024 |
| v 2.0 | Creación de plantillas | N/A | Ricardo Rosales, Juan Pablo Cabrera, David Langarica | Alejandra Cabrera | 06/03/2024 |
| v 3.0 | Se agrega link a especificación de requerimientos de software | N/A | Daniel Cajas | Diego Sandoval | 30/04/2024 |
| v 4.0 | Se agrega descripción de pruebas en voz alta | N/A | David Langarica | Ricardo Rosales | 14/05/2024 |
| v 5.0 | Se agrega descripción de pruebas de escenarios | Se agregaron las pruebas de escenarios para probar escenarios alternos al flujo principal del sistema | Ricardo Rosales | Alejandra Cabrera | 15/05/2024 |