lOMoARcPSD|10963556

lOMoARcPSD|10963556

Tabla de contenido
 lOMoARcPSD|10963556

Modelo de Casos de Prueba....................................................................................................4

Introducción............................................................................................................................5
1. Alcance de las pruebas del sistema información.............................................................6
2. Definiciones y acrónimos................................................................................................6
2.1. Definiciones..............................................................................................................6
2.2. Acrónimos....................................................................................................................7
3. Referencias......................................................................................................................7
4. Visión general del documento.........................................................................................8
4.1. Objetivos......................................................................................................................8
4.2. Documentos relacionados.............................................................................................8
5. Descripción del Ambiente de pruebas (precondiciones y postcondiciones)...................8
5.1. Cuadro de resumen relacionados a las pruebas............................................................9
5.2. Requerimientos de pruebas incluidos.........................................................................10
5.3. Casos de pruebas incluidos.........................................................................................10
5.4. Casos de pruebas excluidos........................................................................................10
5.5. Entorno y configuración de las pruebas.....................................................................10
5.5.1...........................................................................................Criterios de inicio10
5.5.2..........................................................................Bases de datos de pruebas11
5.5.3.................................................................Criterios de aprobación / rechazo11
5.6. Estrategias de pruebas................................................................................................12
5.6.1...............................................................................Escenarios de la prueba12
5.7. Orden de ejecución de pruebas...................................................................................12
5.8. Equipo de pruebas......................................................................................................13
6. Casos de prueba pruebas unitarias.................................................................................13
6.1. Interfaz Web...............................................................................................................14
6.1.1........................................................................ Requerimientos Funcionales14
6.1.2................................................................... Requerimientos No Funcionales15
6.1.3.............................................................................Procedimiento de prueba15
1 de 22

6.2. Base de datos..............................................................................................................15

6.2.1........................................................................ Requerimientos Funcionales15
6.2.2................................................................... Requerimientos No Funcionales16
6.2.3..............................................................................Procedimiento de prueba16
6.3. Procedimiento de prueba (para todas las pruebas unitarias)......................................16
7. Casos de prueba pruebas integrales...............................................................................16
7.1. Interfaz Web...............................................................................................................17
7.1.1........................................................................ Requerimientos Funcionales17
7.1.2................................................................... Requerimientos No Funcionales17
 lOMoARcPSD|10963556

7.2. Base de datos..............................................................................................................18

6.2.1. Requerimientos Funcionales................................................................................18
7.2.2. Requerimientos No Funcionales..........................................................................18
7.3. Procedimiento de pruebas..........................................................................................18
8. Registro de resultados de las pruebas unitarias.............................................................19
9. Registro de resultados de pruebas integrales.................................................................19
10. Ajustes y Recomendaciones.......................................................................................20
11. Casos de pruebas (Plantilla de casos de prueba)........................................................21
12. Conclusión.................................................................................................................22
 lOMoARcPSD|10963556

Modelo de Casos de Prueba

Versión 1

Historia de revisiones

Fecha Versión Descripción Autor

Luz Camargo
23/03/2023 1.0 versión correspondiente a la etapa
inicial

Responsable de verificación: Luz Camargo

 lOMoARcPSD|10963556

Introducción

El desarrollo de software o de aplicaciones es una actividad que es llevada a cabo por seres
humanos, por consiguiente, es posible hallarse con ciertas deficiencias, errores y fallas, por
lo cual para eludir aquellas situaciones debería existir una estrategia de pruebas, que si bien
no descarta en su integridad los errores si reducirá la posibilidad de fallas.
La implementación de estas pruebas es importante porque garantizan la calidad del
software, permitiendo a los desarrolladores encontrar errores del sistema y luego hacer una
depuración. Por más que se desee evitar dichos errores y fallas, se dificulta un poco debido
a que son indescifrables, por esa razón es fundamental el conveniente proceso de pruebas
de software que posibilite asegurar a partir de la perspectiva de calidad un óptimo producto.
Por lo tanto, en el ejercicio de la administración de calidad, las pruebas que se realizaran al
programa son el mecanismo por el que es proceso de verificación y validación tiene triunfo.
Este proceso es:
 lOMoARcPSD|10963556

1. Alcance de las pruebas del sistema información

Con la ejecución de las pruebas de software se busca encontrar fallas para poder depurarlos
y aumentar la calidad del software, para lograr así que el sistema de información cumpla
con los requerimientos del cliente y también para evitar los sobrecostos de mantenimiento.
Además, es importante que en el proceso de verificación y validación del software se tomen
en cuenta:
- Requerimientos funcionales y requerimientos no funcionales del software.
- Fallos e inconsistencias del sistema.
- Pruebas estáticas y pruebas dinámicas del sistema

2. Definiciones y acrónimos
2.1. Definiciones
Casos de Prueba: Un conjunto de entradas, condiciones de ejecución y resultados
esperados, diseñados para un objetivo particular.
Prueba: Una actividad en la cual un sistema o componente es ejecutado bajo condiciones
específicas, se observan o almacenan los resultados y se realiza una evaluación de algún
aspecto del sistema o componente.
Equivocación: Una acción del ser humano que produce un resultado incorrecto.
Error: La diferencia entre un valor calculado, observado o medido y el valor verdadero,
especificado o teóricamente correcto.
Fallo: La incapacidad de un sistema o de alguno de sus componentes para realizar las
funciones requeridas dentro de los requisitos de rendimiento especificados.
Defecto: Un paso, proceso o definición de dato incorrecto en un programa de computadora.
EL resultado de una equivocación.
Depuración: El proceso de localizar, analizar y corregir los defectos que se sospecha que
contiene el software.
Verificación: Un conjunto de actividades que aseguran que el software implementa
correctamente una función específica. (¿Estamos construyendo el producto
correctamente?).
Validación: Un conjunto diferente de actividades que aseguran que el software construido
sea justo a los requisitos del cliente. (¿Estamos construyendo el producto correcto?).
Funcionalidad: satisfacción a las necesidades de adaptabilidad, exactitud,
interoperabilidad, cumplimiento y seguridad
Usabilidad: facilidad para usar, siendo entendible, operable.
 lOMoARcPSD|10963556

Testware: Es el producto resultante de las pruebas.

2.2. Acrónimos
SQA: Software Quality Assurance (Aseguramiento de Calidad de Software)
GUI: Graphical User Interface (Interfaz Gráfica)
PDL: Program Desing Language (Lenguaje de Diseño de Programas)
UD: Use-Definition Chain (Cadena Definición-Uso)
OO: Object-Oriented (Orientado a Objetos)

3. Referencias

Proyecto Tipo de proyecto

Proyecto de desarrollo de una página web
Sistema de inventario para la gestión de inventario.

Documentos de evaluación relacionados

Casos de prueba (plantilla de casos de prueba)

Equipo de proyecto

Equipo de Arquitectos
trabajo Luz Camargo del proyecto Luz Camargo
 lOMoARcPSD|10963556

4. Visión general del documento

El propósito del proyecto de pruebas es dar información fundamental para planificar las
pruebas del sistema de información en desarrollo. La construcción de programa tiene
algunas etapas, a partir de su diseño hasta su utilización o puesta en marcha, debería pasar
por diversos instantes donde el programa va evolucionando. Ciertamente el Testing o las
pruebas son relevantes y elementales, debido a que en varios casos se hace mal o no se
hace. Como entendemos las pruebas son un grupo de ocupaciones dentro del desarrollo de
programa. Hay diversos tipos de pruebas y dependiendo de ellas, estas ocupaciones tienen
la posibilidad de ser implementadas en cualquier instante del desarrollo del sistema. Cabe
resaltar que el control de calidad del programa lleva ciertos aplicativos que permiten revisar
a partir del punto estático y de caja blanca, o sea son pruebas donde se examina el programa
sin ejecutarlo por medio del código fuente. Tenemos la posibilidad de descubrir
herramientas escritas en programa independiente, código abierto o programa privativo.
Estas herramientas van a poder ser usadas para diversos tipos de pruebas como:
Herramientas de administración de pruebas, herramientas para pruebas funcionales,
herramientas para pruebas de carga y rendimiento.

4.1. Objetivos
Entregar ciertas pautas y definir la estrategia que se llevara a cabo para así obtener la
certificación del software Sistema de inventario – página web. Con el fin de establecer una
cronología y condiciones para la aplicación de las pruebas de manera que pueda resultar un
sistema completo y tenga gran acogida por parte de los interesados, para así poder entrar en
marcha con todas las funcionalidades requeridas

4.2. Documentos relacionados

Documento Versión
Plantilla stakeholder 1.0
Plantilla caso de pruebas 1.0

5. Descripción del Ambiente de pruebas (precondiciones y postcondiciones)

Las pruebas de software se integran dentro de las diferentes fases del ciclo de vida del
software. En este sentido, se ejecuta el aplicativo de inventario a probar mediante de
técnicas experimentales se trata de descubrir que errores tiene. Para determinar la calidad
que se deben efectuar una medidas o pruebas que permitan comprobar el grado de
cumplimiento respecto

2 de 22
 lOMoARcPSD|10963556

de las especificaciones iniciales del sistema. Existen muchas pruebas de software, pero en
este caso se va a escoger dos que son:
 Casos de pruebas unitarias.
 Casos de pruebas integrales.
Estas pruebas de software son ocupaciones claves para que los procesos de validación y
verificación tenga triunfo, debido a que ayuda a dar el producto con la calidad suficiente
para saciar las necesidades del comprador y con la certeza de que el producto a dar cumple
las especificaciones definidas. En este sentido, las pruebas que se hará se tengan en cuenta
como un proceso que aspira conceder confianza y con el producto a conceder. Como parte
del proceso de validación y verificación se debe tomar elecciones en el ámbito. Se necesita
probar cada ítem desarrollado en pruebas en una maquina libre, se necesita generar las
mismas condiciones que hay en el ámbito ya desarrollado.

5.1. Cuadro de resumen relacionados a las pruebas.

Ingreso, modificación y eliminación de usuarios
Módulos de sistemas
a ser aprobados Ingreso, modificación y eliminación de usuarios
Proyecto, revisión y aprobación.
En estos módulos se realizarán pruebas para validar:
− la representación de los datos, ingresados o modificados
Objetivos de las
pruebas − la operación de los productos del sistema Plan 1.0
− La secuencia lógica de las funcionalidades y transacciones.

− la respuesta y realización de las transacciones a cada

modulo
Los módulos se deben ejecutar en forma independiente, pero
Detalle del orden de consecutivos en el orden siguiente:
ejecución de los Ingreso, modificación y eliminación de usuarios
módulos
Ingreso, modificación y eliminación de
usuarios
Proyecto, revisión y aprobación.
Las pruebas son responsabilidad del testing operacional del equipo
Responsabilidad de de proyecto, quien en conjunto con el usuario deben seleccionar las
la prueba pruebas que se aseguren de la efectividad del sistema.

Mediante los siguientes cuadros se describen los requerimientos de las pruebas del sistema
de información de inventario incluidos y excluidos en la presente certificación del sistema
Plan 1.0
 lOMoARcPSD|10963556

5.2. Requerimientos de pruebas incluidos

Nombre Descripción Tipo Nivel de criticidad
(Bajo, medio, alto)
N/A N/A N/A N/A

5.3. Casos de pruebas incluidos

Nombre Descripción Tipo Nivel de criticidad
(Bajo, medio, alto)
N/A N/A N/A N/A

5.4. Casos de pruebas excluidos

Nombre Descripción Tipo Nivel de criticidad
(Bajo, medio, alto)
N/A N/A N/A N/A

5.5. Entorno y configuración de las pruebas

Para el proceso de pruebas del proyecto se requiere de la disponibilidad de los siguientes
entornos, a saber:
a) Computador con sistema operativo Windows 10 con acceso a internet.
b) Equipo de cliente: usado como equipo de prueba.
Nombre del dispositivo: PC DESKTOP- KRTPH
Procesador: Intel(R) Core (TM) i3-230 Memoria
RAM: 4,00 GB
Disco de estado sólido (DSS): 256 GB
c) Base de datos MySQL
d) Apache XAMPP
Este programa se encontrará instalado en el equipo, debido a que se va a laborar como un
servidor local, para hacer los exámenes en los equipamientos de prueba y para configurar
más adelante la versión final del plan en los equipamientos del comprador. Todos esos
programas instalados y configurados por el equipo de trabajo a cargo del proyecto Sistema
de inventario pensado para una Papelería.

Se aprobará el proyecto con un 100% de las pruebas ejecutadas, pero con un 90% de
aceptación. Esto quiere decir el 90% de las pruebas deben ser exitosas y sin errores.
El restante 10% pueden existir errores medios o bajos, pero no graves. En caso de
ocurrir que el proyecto no cumpla con el nivel exigido, el proyecto se rechaza
completo en su etapa de certificación.
 lOMoARcPSD|10963556

5.6. Estrategias de pruebas

Es preciso afirmar por parte del equipo de desarrollo y por parte del cliente al producto
Sistema de información de inventarios (página web). Por ende, se debería comprobar:
1ra. Fase: Que las funciones de los módulos de ingreso de usuarios, modificación de datos y
supresión de datos sean operativas.
2da.Fase: Que la contestación y ejecución de las transacciones a cada módulo sean
eficientes. Conjuntamente los sub-objetos para los módulos se resume de la siguiente
forma:
− Construcción, modificación y supresión de usuarios
− Ingresar datos, modificación y supresión de datos de los diferentes módulos
− Que los documentos y ocupaciones se generen con su estado que corresponde en el
sistema.
5.6.1. Escenarios de la prueba
Para cumplir con los objetivos planteados deben existir tres escenarios, que son:
1. Pruebas de Apertura: La página no debe presentar anomalías, además, debe estar el
servidor y la base de datos definidos.

2. Pruebas de GUI o Interfaz: El comportamiento de la aplicación web con casos de

bordes inválidos y válidos, donde las pruebas de borde se definen como aquellas
pruebas en las cuáles los datos de prueba a utilizar son valores límites. Incluyendo
que las métricas de usabilidad y funcionalidad a utilizar sean: Comprensión global
de la APP, aspectos de interfaces, métricas de confiabilidad y navegación.

3. Pruebas de Operación o Funcionales: Se tendrá en cuenta el comportamiento de la

aplicación para el módulo de ingresos datos, módulo de modificación datos y el
módulo de eliminación datos.

5.7. Orden de ejecución de pruebas

1. Configuración de los Equipos del Cliente y del Servidor de Aplicación Web y de
Base de Datos.
2. Ejecución de proceso (manual) de ingreso y modificación de los datos de los
módulos para alimentar el sistema de información de Inventario.
3. Ejecución del proceso de generación de datos, donde las tablas y campos a utilizar
serán llenados manualmente.
 lOMoARcPSD|10963556

5.8. Equipo de pruebas

Nombres Responsabilidades
Luz Camargo Arquitectos de productos, responsable de evaluar las
condiciones de término para el proceso de pruebas junto al
jefe de proyectos
Luz Camargo Jefe de proyectos, responsable de evaluar las condiciones de
término para el proceso de pruebas junto al arquitecto de
producto
Luz Camargo Analista funcional, responsable de la resolución de las
incidencias de certificación para los módulos.
Testing de Solución, responsable de la generación del plan
Luz Camargo de pruebas

5. Casos de prueba pruebas unitarias

Para que la prueba unitaria, tenga un éxito se debe cumplir los siguientes requisitos:
1. Automatizable: no debería existir intervención manual esto es especialmente, útil
para la integración continua.
2. Completa: deben cubrir la mayor cantidad de código
3. Repetible o reutilizable: no se debe crear pruebas que solo puedan ser ejecutadas
una sola vez también es útil para la integración continua.
4. Profesionales: las pruebas deben ser consideradas igual que el código con la misma
profesionalidad y documentación.

Pruebas unitarias
 Aislar cada parte del programa y mostrar que las
Objetivo de la prueba partes individuales son correctas.
 Proporcionar fragmento del código.
 Fomentar el cambio: facilitan a uno como
desarrollador mejorar su estatura lo que se llama
refactorización, puesto que permite hacer pruebas
sobres lo cambios y así asegurarse de que los nuevos
Descripción de la prueba cambios no han introducido errores.
 Simplifica la integración: puesto que permite llegar a
la fase de integración con un grado alto de seguridad
de que el código está funcionando correctamente.
 Documentar el código: las propias pruebas son
documentación del código puesto que ahí se puede ver
cómo utilizarlo.
 lOMoARcPSD|10963556

 Separación de la interfaz y la implementación entre los

casos de pruebas y las unidades bajo prueba
realizadas.
 Los errores están más acostados y son más fáciles de
localizar: dado que tenemos pruebas unitarias que
pueden desenmascararlos.
Es fundamental percibir que las pruebas unitarias no
descubrirán todos los errores del código, puesto que solo
Técnicas prueban las unidades por si solas. Por consiguiente, no se
descubrirán errores de unión, inconvenientes de
rendimiento y otros inconvenientes que están afectando a
todo el sistema en general. Equiparar el resultado
deseado con el resultado obtenido.

Se desea hacer prueba unitarias e integrales en el sistema de inventario en los diferentes

ítems, definir casos de prueba aplicando cobertura de decisión/condición para el fragmento
de códigos

5.1. Procedimiento de prueba (para todas las pruebas unitarias)

Las pruebas unitarias serán ejecutadas por cada implementador utilizando el método que
más crea conveniente. Se tomará como criterio de aceptación de las pruebas, que los test
cases cubran el 100% de las sentencias del código. Y como criterio de aceptación del
componente a verificar, que este pase correctamente todas las pruebas.

6. Casos de prueba pruebas integrales

Construir el sistema a partir de los distintos componentes y probarlo con todos integrados.
Esta prueba se debe realizar progresivamente.
Pruebas integrales
 Identificar errores introducidos por la combinación de
ítem probados unitariamente.
 Determinar como la base de datos de prueba como
será cargada.
Objetivo de la prueba  Verificar que las interfaces entre el usuario funcionan
correctamente
 Verificar que las especificaciones de diseño sean
alcanzadas.
 Determinar el enfoque para avanzar desde un nivel de
interacción de los ítems
 lOMoARcPSD|10963556

 Describe como verificar que las interfaces entre los

componentes de software funcionan correctamente.
 Determinar la base de datos
Descripción de la prueba  Determinar el enfoque para avanzar desde un nivel de
integración.
 Decide que acciones tomar cuando se descuben
problemas
Técnicas Verificación de resultados
 lOMoARcPSD|10963556

Registro de resultados de las pruebas unitarias

Caso de prueba: OP01

Técnica de pruebas de caja negra: Requerimiento Funcional / Caso de uso
Datos de entrada: El usuario entra a la Aplicación con el usuario y contraseña dados por el
administrador.
Resultado esperado (Salida): El sistema registra el usuario y la contraseña del usuario e
ingresa a la página principal correspondiente a cada usuario (administrador, usuario).
Caso de prueba: OP02
Técnica de pruebas de caja negra: Requerimiento Funcional / Caso de uso
Datos de entrada: El Administrador ingresa a la sección de <proveedores, clientes,
productos= da clic en el botón <Eliminar=, sale una alerta <¿Esta seguro que desea
eliminar? Si | No=. El administrador debe escoger alguna opción.
Resultado esperado (Salida): El usuario desaparece de la lista. (Se debe actualizar la
página para ver el cambio).

7. Registro de resultados de pruebas integrales

Caso de prueba: OP01

Técnica de pruebas de caja negra: Requerimiento Funcional / Caso de uso
Datos de entrada: El usuario entra a la Aplicación con el usuario y contraseña dados por el
administrador.
Resultado esperado (Salida): Los datos modificados o agregados sean guardados en la base
de datos sin ninguna complejidad.
Caso de prueba: OP02
Técnica de pruebas de caja negra: Requerimiento Funcional / Caso de uso
Datos de entrada: El Administrador ingresa a la sección de <proveedores, clientes,
productos= da clic en el botón <Eliminar=, sale una alerta <¿Esta seguro que desea
eliminar? Si | No=. El administrador debe escoger alguna opción.
Resultado esperado (Salida): que los datos modificados o agregados sean guardados en la
base de datos sin ninguna complejidad.
 lOMoARcPSD|10963556

8. Ajustes y Recomendaciones

Un proceso de pruebas formales está compuesto por 5 etapas:

Los usuarios tienen la posibilidad de preferir un producto de calidad que comprar un producto
de baja calidad, esto puede ser nocivo para la compañía. En el planeta de hoy, la calidad es
una prioridad en cualquier organización. Las pruebas de programa son relevantes y
elementales para identificar errores, fallas en el sistema y para lograr probar que el
programa cumple con los requisitos del comprador. Además de que esto ayuda al equipo de
desarrollo a arreglar las fallas y dar un producto de calidad. Hay diversos aspectos en el
proceso de desarrollo de programa en los cuales el error humano puede llevar a que el
programa no cumpla con los requisitos del comprador:
1. El individuo / comprador que da los datos requeridos en nombre de la compañía no
sepa en realidad lo cual es preciso o puede olvidar proveer más detalles, lo cual esto
lleva a que falten requisitos.
2. El personal que recopila los requerimientos del comprador puede no cumplirlos por
completo al documentarlos
3. En la etapa de diseño, tienen la posibilidad de exponer inconvenientes y esto puede
conducir a errores en el futuro
4. Los errores tienen la posibilidad de aparecer además en la etapa de desarrollo, así
sea por falta de vivencia del programador o un error humano.
5. Es viable que los consumidores no cuenten con el hardware o programa necesarios
para probar las funcionalidades del producto y que, al liberar el producto a los
usuarios finales, ellos logren descubrir errores en la aplicación
6. La compañía y su fama es dependiente de la calidad de sus productos y en algunas
ocasiones inclusive las ganancias tienen la posibilidad de depender de eso.
 lOMoARcPSD|10963556

10. Casos de pruebas (Plantilla de casos de prueba)

Plantilla de Casos de Pruebas de Software

Proyecto: Sistema de administracion de invetario
Ciclo de Pruebas: [Descripción del Ciclo de Pruebas]
Información para el Seguimiento

Id Caso de Descripción Fech Área Funcional ƒ Funcionalidad ƒ Datos ƒ Resultado Requerimientos de Procedimientos Dependencias con Resultado Estad Última Observaciones
Prueba a Sub Característica Acciones de Esperado Ambiente especiales otros Obtenido o Fecha de
proceso Entrada de Pruebas requeridos casos de Prueba Estado
El comportamiento del Permite el registro
Registrar, sistema debera Modulo de registro y Generar error si dejo EI sistema genero La plataforma genera cada
CP0 reestableccer de los usuarios y al
describir el paso a paso registro, restablecer reestablecimeinto de campos en blanco correctamente eI caso Correct caso sin ningun error
1 contraseña del mismo tiempo o
del caso de uso contraseña contraseña exitoso requerido
genera un link si el
usuario cuando una persona mismo desea
desee registrarse o reestablecer contraseña
reestablecer
contraseña
El comportamiento del crea proveedores y
CP0 Crear proveedor, sistema debera describir Modulo proveedor y crear proveedores y Generar error si dejo EI sistema genero Correct Genera cada caso sin
clientes nuevos los
2 clientes el paso a paso del caso clientes clientes sin ningun error campos en blanco correctamente eI caso o ningun error
cuales seran requerido
de uso cuando el guardados en la base de
personal genere reportes
datos
El comportamiento del Modifica los datos
Modificar proveedor, Modulo proveedor y modificar los datos de Generar error si dejo La plataforma genera cada
sistema debera describir relacionados a los EI sistema genero
CP0 clientes clientes manera exitosa campos en blanco Correct caso sin ningun error
el paso a paso del caso proveedores y clientes y correctamente eI caso
3 requerido o
de uso cuando el sera actualizados en la
personal genere base de datos
reportes
El comportamiento del
CP0 Registrar entrada sistema debera describir Modulo de Notifica la entrada de actualizar existencias EI sistema genero Correct Genera cada caso sin
correctamente eI caso
4 de productos el paso a paso del caso inventarios cada producto y actualiza requerido o ningun error
de uso cuando el el KARDEX
personal genere reportes
El comportamiento del
CP0 Registrar salida sistema debera describir Modulo de Notifica la salida de actualizar existencias EI sistema genero Correct La plataforma genera cada
correctamente eI caso
5 de productos el paso a paso del caso inventarios cada producto y actualiza requerido o caso sin ningun error
 de uso cuando el el KARDEX
personal genere reportes
El comportamiento del
sistema debera describir Permite hacer Modificar productos sin Generar error si dejo EI sistema genero
CP0 Modificar el paso a paso del caso Modulo de modificacion de ningun error campos en blanco correctamente eI caso Correct Genera cada caso sin
6 productos productos informacion de los requerido o ningun error
de uso cuando el
personal realice productos
modificacion de
los productos
El comportamiento del EI sistema genero
CP0 Consultar sistema debera describir Modulo de Busqueda de Busqueda de productos Producto que no exista Correct Genera cada caso sin
correctamente eI caso
7 productos el paso a paso del caso productos productos exitosa se le notificara al o ningun error
requerido
de uso cuando el personal
personal consulte los
articulos
El comportamiento del La plataforma funciona
CP0 Generar reportes sistema debera describir Modulo de Reportes en formato Que el proceso de Generar error sino a EL sistema genero Correct
correctamente al momento
8 el paso a paso del caso reportes PDF reportes sea realizado seleccinado el reporte que correctamente el o
de generar los reportes
de uso cuando el correctamente desee obtener reporte
personal genere reportes
 lOMoARcPSD|10963556

11. Conclusión

En el instante que sabemos que un óptimo diseño y una buena planificación y ejecución de
pruebas, vamos a entender el valor que tiene todo el proceso de desarrollo de nuestra
aplicación, comenzando a partir de la recolección de datos con los diferentes
procedimientos, pasando por el diseño en UML hasta conseguir el desarrollo del sistema de
información con la tecnología elegida. Realizando un diagnóstico de las necesidades del
comprador, plasmando en casos de uso y en las interfaces de cliente tenemos la posibilidad
de ser asertivos en el cumplimiento con el comprador.