Casos de uso para el registro de un movimiento en el sistema Marje

Identificador de Plan de Pruebas

• Identificador de documento:

PDPMARJE (PDP=Plan de Pruebas, Nombre del Sistema: Marje)

Control de cambios

Referencias

Documento de requerimientos funcionales

Casos de uso para el registro de usuarios en el sistema Marje

Casos de uso de acceso de usuarios en el sistema Marje

Casos de uso para el registro de un movimiento en el sistema Marje

Introducción

Este documento de Plan de Pruebas,  pretende ser una guía para desarrollar de una forma organizada las diferentes actividades que se realizarán en el proceso del plan de pruebas  en el desarrollo   del   proyecto   denominado   “Sistema de control de compra venta e inventario”, así mismo tiene como propósito establecer técnicas, herramientas y actividades relacionadas con la ejecución y validación del plan de pruebas; tomando en cuenta responsabilidades de cada una de las tareas, los recursos y los prerequisitos que deben ser considerados en el esfuerzo de cada una de las pruebas, permitiendo garantizar el cumplimiento de los requerimientos planteados en el desarrollo del proyecto.

Test Items

A continuación se listan los elementos  que serán objeto de prueba dentro del plan de pruebas:

• Documentación
• Especificación de Requerimientos
• Iniciar sesión
• Cerrar sesión
• Registro de usuarios
• Consulta de movimientos (compras, ventas)
• Recuperar la base de datos
• Generar Estadísticas
• Consulta de Inventario

Riesgos durante la etapa de pruebas

• Identificar tardíamente problemas de compatibilidad con plataformas externas  de alto riesgo o costo.
• No cubrir en las pruebas una cantidad representativa de plataformas que deben ser compatibles con la solución a futuro.
• Realizar las pruebas con un enfoque muy técnico sin detectar aspectos que por diseño supongan complejidades altas en el uso del software.
• No lograr captar la opinión de los usuarios finales para determinar los aspectos de facilidad de uso que ellos esperan.
• No detectar a tiempo aspectos del diseño que se conviertan en impedimentos para permitir la fácil instalación y la administración de la solución.
• Presencia de errores en el producto que sean  muy costosos de corregir cuando este ya se encuentre finalizado.

Features to be Tested [Características a validar]

• Validar usuarios del sistema
• Registrar la venta: los productos comprados
• Calcular el total, incluyendo IVA, abonos
• Reducir stock cuando se realiza la venta
• Registrar ventas efectuadas
• Identificar al cajero: usuario y clave
• Registrar abastecimiento de inventario: compra de mercancía.
• Mostrar Gráficos que representen las ventas.

Features no to be Tested [Características que no se van a validar]

• Conexión del sistema con la base de datos
• Propiedades ACID de la base de datos
• Autentificar cada dato registrado en la base

Approach

El plan de pruebas se basará en su totalidad en pruebas funcionales, instalación, regresión y otras teniendo en cuenta los requerimientos no funcionales.

• Revisión de la documentación: La estrategia para realizar estas pruebas, consiste en la revisión de la documentación y casos de uso verificando su completitud y concordancia en la información que se encuentra en ellos.

• Pruebas unitarias: Las estrategias para realizar estas pruebas consiste en  generar casos de prueba necesarios:

• Para que cada sentencia o instrucción del programa se ejecute al menos una vez correctamente.
• Para que cada condición tenga por lo menos una vez un resultado verdadero y al menos una vez uno falso.

• Pruebas funcionales o de procedimientos: La estrategia para realizar estas pruebas consiste en la elaboración y ejecución de Set de Pruebas, teniendo en cuenta flujo normal y flujos alternativos, usando datos validos e inválidos que permitan verificar lo siguiente:

Los resultados esperados ocurren cuando se usan datos válidos.

Se despliegan mensajes de error cuando se usan datos inválidos.

• Pruebas de Regresión: La estrategia para realizar estas pruebas consiste en repetir las pruebas (funcionales y de carga) ejecutadas antes de corregir defectos o de añadir nuevas funcionalidades, para comprobar que las modificaciones no provocan errores donde antes no los había.  

• Pruebas de las bases de datos: la estrategia para realizar esta prueba consiste en introducir en la base de datos tanto datos válidos como no válidos para observar el comportamiento de ésta.

Se espera tener un estudio de cada una de las funciones de acceso y modificación de la base de datos sin pérdida ni corrupción de datos.

• Las pruebas se realizarán en la base de datos creada en el servidor XAMPP.

Métrica de la fase de Pruebas

Cuando se tiene un número determinado de casos de prueba por cada caso de uso, la forma de medir la extensión de las pruebas será comparando el número de casos de prueba ejecutados satisfactoriamente contra el número de casos de prueba total, esto nos dará a conocer el porcentaje de pruebas ejecutado por el grupo de pruebas.

Éxito de pruebas = (Casos de prueba ejecutados satisfactoriamente *100)/total de casos de prueba

• Pruebas de Aceptación:

Las pruebas de aceptación se basarán en su totalidad en pruebas funcionales, instalación, y otras teniendo en cuenta los requerimientos funcionales. Adicionalmente estas pruebas serán de caja negra.

• Pruebas funcionales o de procedimientos:

La estrategia para realizar estas pruebas consiste en la elaboración y ejecución de Set de Pruebas, teniendo en cuenta flujo normal y flujos alternativos, usando datos validos e inválidos que permitan verificar los casos de prueba. Estos casos de prueba son aprobados por el cliente.

Item Pass/Fail Criterio

...