Plan de pruebas

Materia: Evaluación y Mejora Para el Desarrollo de

Software

Docente: M.D.G. Alejandro Jesús Morales Pérez

Alumnos:

● Baray Osorio Gael

● Fernández Robles Lesly Anette
● Cayetano Morales Alejandra
● Carrasco Díaz Uriel Alejandro

TSU: Tecnologías de la Información

Grupo: T-402 Parcial: 2

Plan de pruebas
San Pablo Huixtepec, Oaxaca a 30 de octubre del 2022
Materia: Evaluación y Mejora Para el Desarrollo de
Software
 Índice

Plan de pruebas .................................................................................. 1

Estrategia ......................................................................................... 1
Objetivos:.......................................................................................... 6
Recursos: ......................................................................................... 6
Entregables ...................................................................................... 6
 Plan de pruebas
Estrategia

Alcance
Las pruebas se realizarán a todos los requerimientos, los cuales son:
• Iniciar caja ingresando el monto inicial y la cantidad por cada denominación,
así como el código del gerente del día y el nombre del cajero.
• Cobrar productos de forma que se puedan ver los movimientos de caja en
tiempo real.
• Cancelación de productos al momento, es decir, mientras se realiza el cobro.
• Dar cambio después de realizar un cobro, indicando la cantidad por
denominación a devolver y a su vez, descontar estas cantidades a las
registradas durante la apertura.
• Retirar dinero de forma que se pueda realizar pago a proveedores,
solicitando la clave del gerente para realizar este movimiento e indicando la
cantidad por cada denominación.
• Ver los movimientos de la caja y las denominaciones finales.

Para lo cual se realizarán las siguientes pruebas:

Nivel P1. Pruebas de escritorio en cada uno de los algoritmos realizados para los
módulos de manera individual.
unitario
P2. Caja blanca: Apertura de caja con denominaciones negativas.
P3. Caja blanca: Realizar cancelaciones durante el cobro para comprobar
Nivel de que se haga la resta al monto a cobrar.
integración P4. Caja blanca: Cerrar caja después de realizar cobros y retiros para
comprobar que se registre correctamente el total de ingresos y egresos.
P5. Caja negra: Realizar apertura de caja, cobro, dar cambio y cierre de
caja.
P6. Caja negra: Realizar apertura de caja, cobro, cancelación, dar cambio
Nivel de y cierre de caja.
sistema
P7. Caja negra: Realizar apertura de caja, retiro y cierre de caja.
P8. Caja blanca: Realizar múltiples peticiones para verificar el nivel de
estrés que soporta el programa.
P9. Caja negra: Crear escenarios para las pruebas y realizarlas con
personas ajenas al equipo de desarrollo, probar todos los módulos del
Nivel de programa.
aceptación P10. Caja negra: Con personas ajenas al equipo de desarrollo probar todos
los módulos del programa, con datos elegidos por la persona que lo
probará.

1
 Riesgos

Reporte de pruebas

Se realizó una serie de pruebas a un grupo de 5 administrativos de la Universidad

Tecnológica de los Valles Centrales de Oaxaca, los cuales fueron: Nereida Sánchez
Pascual, Hortensia Ramírez Cueto, Santiago Gabriel González Orozco, Fátima Alelí
Diaz Mendoza, Jasive Yuridia, se les planteó un escenario en donde como cajeros
de una tienda deben de realizar las operaciones de abrir caja, cobrar, dar cambio,
cancelar y cerrar caja, las pruebas se realizaron con dos equipos de cómputo.
Gracias a esta serie de pruebas pudimos recabar información sobre los posibles
errores y fallos dentro de nuestro sistema los cuales fueron los siguientes:

Errores y observaciones

• Dificultad en la compresión del sistema de monedas y es repetitivo (sólo

denominaciones de 1,5,10,20, 50,100, 200 y 500).
• Definir variables para las respuestas de sí y no para no estar escribiendo
(0,1) y (1,2).
• No se puede retornar(cambiar) una cantidad errónea equivocada al ingresar
las denominaciones en caja.
• Mostraba demasiado la contraseña del gerente (fallo en seguridad).

Cambios

• Mostrar la suma de la cantidad que vamos ingresando en monedas (abrir

caja).
• Reducir las preguntas de tipo “¿quiere seguir con el proceso o cancelar el
proceso?”.
• Generalizar las opciones de respuesta (si/no).
• Colocar mensajes más claros y entendibles para el usuario.

2
 Matriz FMEA
Módulo de Control de
Modo de Fallo Efectos S Causas O D RPN Mejoras
requerimiento detección

Ser confuso al ingresar

las denominaciones No se incluye un Implementar un
contador en acumulador que
No se muestra en pantalla que indique la cantidad de
pantalla el dinero muestre el dinero Pruebas de dinero ingresado en
ingresado almacenado en el apertura de caja base a las
Ingreso de momento con diferentes denominaciones.
denominaciones muy No poder cambiar una 2 9 montos y sin 3 54
tardado denominación en la que No existe forma escenarios Ingresar primero las
nos hayamos de corregir creados denominaciones y
equivocado inmediatamente previamente después con un
cuando se erra en mensaje preguntar si
Abrir Caja Provoca que el proceso la cantidad de una es el monto correcto
de apertura sea más denominación de apertura.
tardado para el usuario

No se oculta la
clave del gerente Implementar la
Seguridad muy baja
Cualquier persona cuando está se encriptación de la
con acceso al ingresa Pruebas clave del gerente
Se pueden realizar
software es capaz de 5 7 realizadas por el 5 175
retiros sin necesidad de
ver el código del Durante toda la equipo de testeo Ocultar los caracteres
solicitar la autorización
gerente ejecución es durante el ingreso de
del gerente
posible visualizar la clave
la clave

Confusión con las Exceso de Estandarizar

opciones de respuesta variables de Pruebas respuestas para las
Proceso de
de sí y no confirmación realizadas por preguntas
cancelación y
Cobrar personas
confirmación erróneo 6 5 5 150
Seleccionar una opción Exceso de externas al Exportar el programa
incorrecta en los menús preguntas de equipo de a un lenguaje que

3
 confirmación desarrollo. posibilite la interfaz
Ingreso de un número gráfica, para hacer
cuando se requiere un No existe más sencilla la
carácter o viceversa estandarización selección de opciones
en las respuestas
Producir cierre de confirmación y
inesperado del selección de
programa opciones.

Producir un error en el
total a cobrar

No tener una
No conocer las
variable definida Revisión del Creación de variables
ganancias al final de la
que almacene los código de control del total de
jornada
ingresos. ingresos.
No visualizar los
5 9 Cuando el 4 180
ingresos obtenidos El reporte del cierre de
Operaciones programa es Definición correcta de
caja podría indicar que
erróneas durante usado por el las operaciones
no se obtuvieron
la ejecución del usuario final. durante el proceso
ganancias
cierre.

Cerrar caja
Revisión del
código
No cerrar la caja, de
Se requeriría reiniciar el No existe Creación de variables
tal manera que te
programa para abrir caja 5 validación de 7 Cuando el 8 280 de control para el
permita abrirla
después del cierre cierre. código es usado cierre de caja
nuevamente
por el usuario
final

4
 Logística
Las pruebas de caja blanca serán realizadas por Gael Baray Osorio, por otro lado,
las pruebas de caja negra se llevarán a cabo por Alejandra Cayetano Morales. Las
pruebas con usuarios externos serán realizadas por ambos testers. Todas las
pruebas se harán utilizando los equipos de computo con los que ya cuenta el equipo.

Tipo
Clave Tester Líder QA Fecha
B N
Gael,
P1 Lesly 11/10/22
Alejandra
P2 Gael Lesly 12/10/22
P3 Gael Lesly 19/10/22
P4 Gael Lesly 20/10/22
P5 Alejandra Lesly 20/10/22
P6 Alejandra Lesly 24/10/22
P7 Alejandra Lesly 25/10/22
P8 Gael Lesly 26/10/22
Gael,
P9* Lesly 27/10/22
Alejandra
Gael,
P10* Lesly 27/10/22
Alejandra

*Estas pruebas requieren realizarse con usuarios ajenos al equipo de desarrollo.

5
 Objetivos:

Según los posibles fallos considerados en la matriz FMEA, no se aceptarán

fallos con un RPN mayor a 150.
Tasa de ejecución: 100%, se deben realizar todas las pruebas programadas.
Tasa de éxito: 90%, una de las diez pruebas realizadas no fue completamente
exitosa.

Recursos:
Recursos Humanos
Concepto Cantidad Costo
Personal administrativo 5 Gratuito

Recursos Materiales: Para estas pruebas no se requerirán materiales más allá de

los ya utilizados en el desarrollo del software.

Entregables

Los resultados se entregarán en un reporte general al líder QA y al programador. El

cual deberá contener los siguientes elementos:

▪ Descripción de la prueba
▪ Datos utilizados para la prueba
▪ Resultados esperados
▪ Resultados reales (incluidas capturas de pantalla de los resultados)
▪ Sugerencia de solución
▪ Estado actual de los defectos encontrados (se han reportado, están en
análisis, descartados, en proceso o corregidos).