PLAN DE PRUEBAS

General
Las pruebas son parte importante dentro del desarrollo de software, estas permiten
confirmar que el sistema puede llegar a ser una herramienta útil para los
usuarios, es por eso que deben realizarse de manera minuciosa para tratar de obtener
variaciones con relación al funcionamiento del sistema. Con el fin de obtener un
producto de software con calidad, se ha planeado someter al sistema a un régimen
moderado de pruebas para verificar su buen funcionamiento. Este plan de pruebas
estará dividido por los siguientes puntos:

· Identificar el plan.
· Alcance
· Items a probar
· Estrategia
· Categorización de la configuración
· Manejo de riesgos
· Responsables
· Tangibles

Identificar el plan
Para la elaboración de pruebas se ha pensado en identificar módulos el problema,
con esto se espera tener mejor organizada las pruebas. Después de tener los módulos se
aplicaran a cada uno de ellos los diferentes tipos de pruebas (volumen, desempeño,
etcétera).
A continuación se presenta los módulos que han sido identificados en el sistema:

Módulo de Altas y bajas

Se está consciente de que para un punto de venta es necesario que se lleven a cabo
ciertas acciones que son indispensables para llevar a cabo el manejo de éste, por lo
tanto el registro y actualización de algunos aspectos son importantes para el
negocio, en este caso, este módulo está compuesto de acciones para llevar a cabo
la alta y baja de productos, empleados, proveedores. Las acciones son las siguientes:

· Nuevo producto.
· Nuevo proveedor.
· Nuevo empleado.
· Eliminar Proveedor.
· Eliminar Empleado.

Módulo de Ingreso y Egreso

Acciones que facilitan a los usuarios del sistema entrar y salir de él de manera
segura.

· Login
· Logout

Módulo de venta

Estas funciones se encargan de realizar la venta y la impresión del ticket. La venta

es guardada en unos campos para la base de datos para después ser recolectada y
presentada como un informe de ventas al administrador del punto de venta.

· Realizar venta
· Imprimir ticket

Módulo de consulta

Permite a los usuarios visualizar datos que son importantes para el punto de venta .

· Consultar venta
· Visualizar caducidad
· Buscar producto
· Consultar Proveedor
· Consultar empleado
 Módulo de edición

Para la confiabilidad de los datos es necesario tener disponible la opción de poder

modificar los datos en los registros de la base de datos.

· Editar producto
· Editar empleado
· Editar proveedor

Alcance
Para el desarrollo de las pruebas se ha decidido hacer los diferentes tipos de pruebas del
sistema. A continuación una descripción de las pruebas a realizar:

Volumen y desempeño

Los módulos antes identificados en el sistema serán sometidos a un numero n de datos

diferentes como entradas para hacer una verificar el buen funcionamiento del
sistema a partir de estos cambios.

Utilidad

Verificar con forme al criterio de una persona ajena al equipo acerca de algunos
puntos que nos darían como resultado un sistema usable, por ejemplo:

· Interfaz agradable (Tamaño de fuente , colores, etcétera)

· Revisar si el sistema cumple con todas las funciones ya especificadas en el
documento de requerimientos.
· Responder las siguientes preguntas:
§ ¿El sistema es intuitivo?
§ ¿El sistema es útil para el tipo de trabajo que va a desempeñar?

Configurabilidad
Configurar los navegadores para que no guarden contraseñas ni usuarios.
Confiabilidad
Evaluar después de un lapso de un mes el funcionamiento del sistema (un mes después
de haber trabajado en su entorno real) para saber cómo fue su funcionamiento y
saber si el sistema se ha acoplado al entorno de trabajo.

Seguridad
Comprobar que hay funciones que solo son exclusivas para yun tipo de usuario,
además de tratar de entrar el sistema violando la seguridad.

Aptitud de instalación y compatibilidad

Hacer una prueba estimando la cantidad de software necesario para la instalación
completa del sistema y posteriormente instalarlo en una computadora. Medir el tiempo
de instalación y adaptación del sistema, verificar si el sistema es compatible con otras
aplicaciones ó con los recursos de una computadora diferente en la que se desarrollo.

Carga o tensión
Someter el sistema a un tráfico de eventos para saber cómo responde (saber si
durante ese tiempo el sistema pierde datos o se comporta de manera diferente).

Uso de recursos
Medir la cantidad de RAM que utiliza el sistema.

Reoperabilidad y funcionalidad
Someter a la aplicación a datos que generen errores, tratar de desactivar el sistema
cuando esté funcionando, por ejemplo agregar datos que no sean los admitidos en una
caja de texto o querer hacer una función que tenga como requisito haber hecho otro
proceso, después de esto hacer una estimación de la funcionalidad del sistema.
Items a probar
Con el propósito de evitar errores muy grandes dentro del sistema se prefiere detectarlos de la
manera más rápida posible, para que no se conviertan en un punto vulnerable del sistema. Se
planea realizar pruebas inmediatamente después de haber codificado una parte del sistema.

Estrategia
Se aplicarán todos los tipos de pruebas del sistema tomando como referencia las pruebas de
caja negra (Verificar que las salidas correspondan a las entradas).

No se harán pruebas exhaustivas. Después de aplicar las pruebas a cada uno de los
módulos se llenara como reporte el formato de la página siguiente. Posteriormente se
informará de los errores encontrados al líder, y este se encargara de notificar los cambios
correspondientes al equipo de desarrollo. Una vez implementadas las modificaciones sobre el
sistema, se volverá a someter al sistema a más pruebas hasta que el sistema este libre de
errores, posteriormente se actualizaran las partes de la documentación que hayan sido
afectadas con el mejoramiento de del sistema (Casos de uso, diagramas de secuencia, etcétera).

Para la utilidad, se ha planeado una encuesta que no será escrita, con las peguntas antes
mencionadas en Alcance, para obtener porcentajes de aceptación de cada uno de esos aspectos
y así empezar a planear estrategias para mejorar la aceptación.

Para evaluar la confiabilidad se tiene planeado hacer nuevamente todas estas

pruebas después de un mes de trabajo del sistema en su entorno real, se revisará el estado de
las bases de datos y se realizara una nueva encuesta con los empleados acerca del
funcionamiento del sistema durante ese tiempo, las preguntas estarán relacionadas con la
funcionalidad del sistema y de si se presentó algún problema durante ese tiempo.

En el caso de Aptitud de instalación y compatibilidad se hará un breve reporte con

los problemas detectados para prevenirlos durante la instalación en el entorno real.
Formato de pruebas

FECHA:
DIA/MES/AÑO

Nombre del modulo:

Nombre de la función:

Número de veces que se ha realizado esta prueba:

Descripción de la función:

Breve descripción de la función.

Datos de entrada:

Tipo de datos de entrada y descripción de lo que representa ese dato, por ejemplo:

“Se ingresan dos datos de tipo entero (tipo de datos), que serán la cantidad de
productos a comprar por el cliente (Descripción de lo que representa ese
dato).”

Datos de salida esperados:

Tipo de datos que se obtienen después de que el sistema realiza cierta actividad
de una manera correcta y una descripción de ellos, por ejemplo:

“Despliega una lista de los vinos vendidos, enfrente de cda una de estas. Habrá,
el año de su cosecha y el precio. ”

Salida real

Salidas Observaciones

Se llena todo un círculo para tener asentado que la salida sea la esperada.

Correcto Incorrecto
Salida
Categorización de la información
Las pruebas deberán de ser repetidas en caso de que se hayan hecho modificaciones al
código fuente del sistema.

Las pruebas deberán de ser culminadas en caso de que no encontrar errores en las pruebas
realizadas.

Manejo de riesgos

Modificaciones riesgosas

Hacer cualquier modificación sobre un sistema de software tiene un alto grado de

probabilidad de generar nuevos problemas en el sistema, por lo tanto se tiene
planeado guardar responsable y organizadamente un numero de respaldos antes de
hacer una modificación sobre el sistema.

Las pruebas hechos no son las suficientes

Las pruebas son una parte esencial en los sistemas de software, por lo tanto, lo
ideal es hacer un número de pruebas exhaustivas para generar un software confiable,
un problema latente es no hacer un número de pruebas que refleje un problema en
el sistema, sin embargo se tratará provocar los errores más comunes en los usuarios
para sacar a relucir errores dentro de la programación del sistema y así tener un mejor
sistema de software.

Las pruebas retrasan la culminación del sistema

El objetivo de las pruebas de software es la calidad del sistema, con esto se hace referencia
ante un conjunto de pruebas previamente diseñadas que puedan obtener como salidas
algunos errores, sin embargo, al decirse eso, se tiene pensado en hacer pruebas
exhaustivas, pero hacer esto implicaría el riesgo enorme de retrasar algunas tareas y la
entrega del sistema al cliente, es por eso que se harán pruebas moderadas, pero
consientes para tratar de alcanzar un grado optimo de calidad dentro del servicio que
ofrecerá nuestro sistema.
 Las pruebas hechas no son las suficientes

Las pruebas son una parte esencial en los sistemas de software, por lo tanto, lo
ideal es hacer un número de pruebas exhaustivas para generar un software confiable,
un problema latente es no hacer un número de pruebas que refleje un problema en
el sistema, sin embargo se tratará provocar los errores más comunes en los usuarios
para sacar a relucir errores dentro de la programación del sistema y así tener un mejor
sistema de software.

Responsables
El sistema será probado por personal del proyecto ajeno al equipo de desarrollo para tener una
vista imparcial del sistema.

Tangibles
En la elaboración de todo el plan se tiene como documento generado la bitácora de planeación
de pruebas , los formatos de pruebas que deberán llenarse para su reporte y el plan de pruebas.