ESTUDIANTES:

EDWARD YAIR ORTEGA GARRIDO

INSTITUCIÓN UNIVERSITARIA POLITÉCNICO GRANCOLOMBIANO

PRUEBAS Y CALIDAD DE SOFTWARE
PROFESOR:
AVELLANA VARGAS MARGARITA
TABLA DE CONTENIDO

Contenido
1. INTRODUCCION
2. DESARROLLO DE LOS PUNTOS
3. CASOS DE USOS
INTRODUCCION

En el presente documento se estará dando solución a los planteamientos

establecidos en los escenarios de la asignatura. Hoy por hoy las organizaciones
están dispuestas a ofrecer los productos o servicios con los mayores estándares
de calidad, ocurre de la misma manera en las compañías dedicadas al software,
por ende, se buscan implementar distintos modelos con los cuales se puedan
cubrir la disminución de costos y riesgos.
DESARROLLO DE LOS PUNTOS
Punto 1
Describa los elementos de los diversos modelos de calidad que se pueden aplicar
al desarrollo de productos de software, que le permitan realizar un comparativo
entre ellos y determine los pro y contras de cada uno en esfuerzo, tiempo, costo y
beneficios.
Tabla 1. Modelos de Calidad de Software

Modelo Características Pros Contras

CMMI Es el modelo donde se
establecen las mejores
prácticas de la industria
provee a las organizaciones
aquellos elementos
esenciales para los
procesos de negocio.
- Aumentos de la -Es un modelo con
productividad alto costo
-Mejora en la calidad -Requiere de una
del producto fuerte inversión para
ser implementado

-El cliente final está

más informado del
estado actual

BOEHM Es el modelo donde se -Combina elementos -Alto costo en

establecen las mejores
prácticas de la industria
provee a las organizaciones
aquellos elementos
esenciales para los
procesos de negocio.
de otros modelos tiempo, esfuerzo y
dedicación
-Presenta un alto
rango de -Se dedica un
características tiempo importante
para el análisis

-Tiene mejor cabida

en proyectos de
grandes magnitudes
CMM Es un modelo de evaluación -Reducción de -Desviaciones en
de procesos de una tiempos y errores cortos plazos
organización es el modelo
más utilizado mide la
capacidad del proceso -Reducción de
seguido para desarrollar costos
software

FURPS Establece cinco -Genera una vista -Genera mayores

características como
factores de calidad que son:
Funcionalidad, Usabilidad,
Confiabilidad, Prestación y
soporte las cuales son las
que le da su nombre
amplia y comparable costos y tiempos
que se reutiliza en elevados
cada proyecto
-Presenta poca
-Los criterios son de flexibilidad
fácil comprensión

-Presenta un gran
abanico de métricas

MAC CALL El modelo se basa en la -Practico y de fácil -Sus características

descomposición del entendimiento normalmente son
concepto genérico de propiedades
calidad en tres capacidades abstractas mediante
importantes todo desde la -Fácil aplicación -Se métricas
mirada del usuario focaliza en el
producto final
-No siempre
presenta una
-Comprensión de relación entre las
medidas precisas a métricas y las
alto nivel características
 SPICE/ISO/IEC Establece un marco de -Es un modelo más -No presenta una
requisitos para cualquier consensuado y estrategia de mejora
15504
proceso. Proporciona testeado de los procesos
requisitos para los modelos
de evaluación de los
procesos en las -Es coherente con -Poco impacto en el
organizaciones. otros modelos de mercado
calidad
implementados

Punto 2
Lleve a cabo las entrevistas necesarias en la empresa para determinar:
debilidades, fortalezas, oportunidades y amenazas. En general, conocer el modo
de lograr una mejora en los procesos de la empresa.
La organización elegida es “Globaltek Development S.A” es una empresa con un
amplio conocimiento en el área tecnológica referente a desarrollo de software,
donde se ofrecen diferentes servicios.
Dicha organización se centra en desarrollar para cualquier compañía en cualquier
vertical de negocio (Salud, Retail, Financiera, etc.). Manejan distintos lenguajes de
programación (Java, .NET, etc.) donde alojan dichas aplicaciones en
contenedores como Docker.
También tercerizan los recursos de desarrollo a otras entidades, esto con el fin de
ofrecer más core de servicios o productos, en cuanto a desarrollo, pruebas o
consultoría.
.
Los recursos asignados para los diferentes proyectos tienen bien claras sus
funciones, lo que hace que la empresa sea más productiva y ágil. A nivel de
proyectos está:
El gerente de proyecto
El arquitecto de desarrollo
Los desarrolladores
Los diseñadores web
Los tester
DEBILIDADES:
La comunicación con el cliente no es muy asertiva, en todos los casos.
La toma de decisiones no las realiza el líder del proyecto si no el gerente lo que
hace que sea más demorado el proceso.

OPORTUNIDADES:
Oportunidad de llegada a mercados importantes como sector gobierno.
Una estable confianza con el cliente.

FORTALEZAS:
Cuenta con una vasta experiencia en desarrollo de aplicaciones para varias
verticales de negocio.
La combinación y apoyo en las diferentes fases del proyecto agilizan y fortalecen
la entrega final.
La fase de pruebas es muy exhaustiva iniciando desde la fase de desarrollo.

AMENAZAS:
Competitividad recurrente en el mercado.
Compañía no muy robusta respecto a capital y expansión del negocio.

Punto 3
Establezca varios criterios que le permitan validar el estado de avance de su
empresa (puede tomar las KPA del modelo CMM y otros adicionales que
considere afecten su decisión) frente a cada modelo y los elementos que
describió. Indique los dos modelos que considere más adecuados para lograr la
calidad en los productos de software que su empresa desarrolla ya sean internos
o externos.
Usando el modelo CMM se puede mejorar y direccionar el desarrollo del proyecto
para poder tener una orientación hacia un proceso estándar ya estructurado y, por
lo tanto, se pueda reducir el tiempo de aprendizaje sobre cómo hacer lo planteado,
conforme al desarrollo de esto también se pueda ejecutar los niveles del CMM
satisfactoriamente sobre esta metodología de calidad de software.
En los criterios que se pueden evidenciar el avance de la empresa hay que tener
en cuenta las debilidades y las oportunidades que en resumen nos indican un
desarrollo sin metodologías agiles en las cuales se evidencia la poca
comunicación con el cliente. Con un modelo de calidad y optimización se puede
suprimir esta problemática para que ambas partes obtengan un beneficio en
común. En ese orden de ideas esta empresa se encuentra en el nivel 2 de CMM
donde los requerimientos del proyecto no suelen ser claros, comprendidos y
controlados.

Criterios Hallazgos
Gestión de requisitos El modelo actual de la empresa es eficiente
en gran parte lo que hace que los tiempos de
gestión sean bajos y en ocasiones puede
que varíen y a lo mejor no podamos cumplir
con las fechas definidas con el cliente.

Planeación del proyecto
Las instrucciones son muy claras al inicio del
proyecto definidas por el líder del proyecto,
esto conlleva a que los diferentes
involucrados mantengan una buena
comunicación y ejecuten de manera
alineada.

Seguimiento y supervisión del proyecto El control de los avances es eficiente lo que

hace que los involucrados no pierdan tiempo
y deban realizar cambios que no se tengan
contemplados.
 Garantía de calidad de Software El control y seguimiento es claro sobre los
desarrollos, pero también se pueden escapar
detalles fundamentales que pueden influir en
el éxito del proyecto.

Gestión de calidad de software Se cuenta con un proceso estandarizado de

gestión de calidad de software, ya que este
criterio es vital para definir el éxito del
proyecto.

Prevención de defectos No se evidencia alguna prevención de

defectos en el desarrollo.

Teniendo como evidencia cada hito, se tiene en consideración los modelos CMM y
BOEHM donde se tendrá como finalidad el proceso de prevención de defectos y
cambios, con unos modelos de mayor madurez y flexibilidad. Para poder
eficientizar a todos los involucrados en el proyecto.

Punto 4
Establezca la lista de actividades, procesos y procedimientos a lo largo del ciclo de
vida del desarrollo de productos de software que requieren de definición en su
empresa para permitir la implantación de un proceso de pruebas que aumente la
calidad y permita que un plan de pruebas fluya.

Inicialización
Realizar el diagrama de actividad del negocio (mejora del proceso).
Determinar las actividades del negocio a desarrollar.
Describir a los actores del negocio.
Clasificar los objetos y documentos del negocio (Internos, externos, privados,
publico)
Planificación
Determinar la importancia de las actividades a desarrollar.
Determinar los requisitos de la aplicación respecto a las actividades a desarrollar
Diseñar los casos de uso.
Probar los casos de uso.
Determinar los requisitos externos a la aplicación (respecto a norma).
Determinar los requisitos tecnológicos para la aplicación (respecto a norma).
Determinar los requisitos internos de la aplicación (respecto a norma).
Determinar los ciclos de desarrollo.
Determinar la arquitectura de soporte para la aplicación (Diagrama de
Despliegue).
Determinar la arquitectura de la aplicación (Diagrama de paquetes).
Determinar los estándares de codificación. • Elaborar el plan general para el
desarrollo.
Elaborar el plan de control.

Ejecución
Determinar las actividades para la ejecución respecto a un ciclo de desarrollo.
Planificar las actividades de implementación.
Realizar el diseño respecto a las actividades (Diagrama de Secuencia).
Realizar la codificación.
Realizar las pruebas unitarias (Plantilla para documentar esta actividad).
Realizar las pruebas de Integración (Plantilla para documentar).

Control
Definir el conjunto de pruebas.
Planificar las pruebas.
Realizar pruebas de rendimiento.

Realizar pruebas de seguridad.

Realizar inspección de código.
Realizar inspección de artefactos.

Cierre
Plan de prueba de aceptación.
Examen de facilidad de interacción.

Punto 5
De acuerdo con las necesidades establecidas en la entrega anterior, documente
las actividades, procesos y procedimientos que se requieran para llevar a cabo la
mejora de la calidad en el desarrollo de productos de software en la empresa.

Responsables de las Pruebas

Responsable Actividades
Líder de Proyecto Realiza el seguimiento por requerimiento
funcional y en caso de que el líder de
certificación no dé el aval para la puesta en
producción, solicita al comité de control de
cambios la revisión respectiva para poder
generar el plan de acción correspondiente.
 Líder Técnico Aclara las inquietudes sobre el alcance y
algunas validaciones a tener en cuenta
sobre la solución desarrollada, asegura la
ejecución de las pruebas unitarias por parte
del equipo de desarrollo.

Líder de Certificación Realiza la lectura, validación y verificación

de los entregables en los casos en los que
aplique. Contextualiza las pruebas a realizar
al ingeniero o analista de certificación y
realiza seguimientos periódicos durante todo
el proceso de certificación.

Analista de Certificación Realiza la lectura, validación y verificación

de los entregables, realiza la ejecución de
los casos de prueba, en los casos donde
asistió a la reunión de entendimiento y
realizó la estimación de tiempos es quien

contextualiza las pruebas a realizar.

También realiza los reportes de gestión de
incidentes, mantiene informado al líder
encargado con los avances de la ejecución,
brinda soporte a las pruebas de aceptación
ejecutadas por el cliente y realiza revisión
final de los entregables.

Tipos de Pruebas Funcionales:

Pruebas Unitarias: Las pruebas unitarias son las que aseguran que cada célula
del código desarrollado en un componente brinde los resultados adecuados. En
estas pruebas los desarrolladores observan la interfaz y la especificación de un
componente, proporcionando la documentación del desarrollo del código se
prueba exhaustivamente, claro que de forma independiente antes de pasar a otra
unidad.
Las pruebas unitarias admiten pruebas funcionales al ejercer el código que es más
probable que se rompa. Por ello, si usas pruebas funcionales sin pruebas
unitarias, puedes experimentar algunas dificultades para diagnosticar pruebas
fallidas. Así que tenlas muy presente.

Prueba de Componentes: Las pruebas de componentes se ejecutan de forma

independiente para comprobar que el resultado sea el requerido. Su objetivo es
verificar las funcionalidades y/o usabilidades de los componentes, aunque no solo
se limite a eso.
Para ilustrarla mejor, un ejemplo de esta prueba puede ser cualquier elemento que
tenga entrada y deba generar alguna salida. Puede ser el módulo de código,
página web, pantallas e incluso un sistema dentro de un sistema más grande, en
un componente. Aquí algunos usos de los componentes a probar:
Prueba de UI para usabilidad y accesibilidad
Prueba de carga para asegurar el rendimiento
Inyección de SQL a través de componentes de UI para asegurar la seguridad
Prueba de login con credenciales válidas e inválidas
Prueba de Humo: Las pruebas de humo se realizan para verificar si las
funcionalidades más significativas de la aplicación funcionan o no. De forma que lo
más básico del software se ejecute de forma correcta con pruebas sencillas y
rápidas.

Es una de las pruebas funcionales más importantes y debería ser la primera que
se realice en una nueva compilación. La prueba de humo es común y aunque a
veces no se tiene claro su concepto. No se trata de realizar pruebas exhaustivas
sino de verificar que la funcionalidad crítica del sistema realmente funciona bien.

Prueba de Integración: La prueba de integración es uno de los tipos de prueba

funcional más común y se realiza de forma automatizada. Se realizan para probar
componentes individuales con el objetivo de verificar cómo los módulos, que
trabajan de forma individual, funcionan cuando estén integrados.

El objetivo de realizar estas pruebas es porque comúnmente los desarrolladores

se enfocan en construir diferentes módulos del sistema simultáneamente y no se
centran en otros. Las pruebas de integración permiten que los datos y comandos
operativos fluyan entre módulos. Hacer que todo actúe como partes de un solo
sistema en lugar de aplicativos aislados.
Pruebas de Regresión: Es normal que los desarrolladores modifiquen y mejoren
las funcionalidades de su desarrollo. Por ello existe una gran posibilidad de que
puedan causar ‘efectos’ inesperados en su comportamiento. Estas pruebas de
regresión se realizan para asegurar que los cambios o adiciones no hayan
alterado ni eliminado las funcionalidades existentes.

El objetivo de las pruebas de regresión es encontrar errores que puedan haber

sido introducidos accidentalmente en la compilación existente y así garantizar que
los errores eliminados continúen así.

Pruebas de Aceptación del Usuario: Cuando ya hemos seguido e implementado

las pruebas que requerimos para nuestro producto, hacemos las pruebas de
aceptación. Estas hacen parte de la última fase de este proceso de testing. Aquí
los usuarios reales del software lo usan para verificar que cumpla con las tareas
requeridas en un ambiente ‘real’. En ocasiones se realiza cuando se hace la
entrega del producto “como punto de control final entre todos los tipos de pruebas
funcionales”.

Desde el inicio hasta la implementación, el software deberá someterse a varios

tipos de pruebas. El objetivo siempre será asegurar la calidad para evitar
reprocesos y garantizar las funcionalidades de la aplicación, tanto para el usuario
final, como para el cliente.

Análisis de las Pruebas:

En esta fase debemos conocer el histórico del proyecto y solicitamos al PMO los
diferentes documentos los cuales almacenamos en nuestro repositorio, con el fin
de garantizar la trazabilidad. De la misma forma se anexan actas, documentos de
estrategia de pruebas y la estimación de tiempo aprobada.

Diseño de las Pruebas:

En este apartado se especifica la cantidad de las pruebas, la cual permitirá; definir
y asignar prioridades como alta, media o baja además de establecer un orden de
trabajo y dar una estimación del tiempo en probar cada funcionalidad.

Ejecución de las Pruebas:

En esta fase definimos los ciclos que se requieren para garantizar la calidad del
producto hasta llegar a un ciclo de regresión donde se seleccionan solo un
porcentaje sobre los casos fallidos en ciclos anteriores, luego se realizan las
pruebas UAT y de Aceptación del usuario para poder generar la carta de
certificación y poder desplegar el proyecto a Producción.

Punto 6
Defina la estrategia e hilo conductor a largo plazo: las pruebas, las políticas, los
responsables y sus roles, los formatos y medios de comunicación, los
capacitadores, las reuniones de control, la recolección de datos, las métricas, la
frecuencia de las revisiones, la codificación de versiones de componentes, el
esquema de informe de cambios, etc.

Formatos de las Pruebas

Formato de lista de chequeo de prerrequisitos. e

Revisado/
Documentos Disponible Observaciones
Aprobado
No Si No
• Cronograma del Proyecto Si

No Si No
• Casos de Uso Si

• Requerimientos no Si No Si No
Funcionales

Si No Si No
• Especificación de Diseño

• Código Fuente (Pruebas Si No Si No

Caja Blanca)

• Plan de Control de la Si No
Configuración. (Entorno de
Si No
Pruebas)

Si No
• Prototipo (Software)
Si No

Si No
• Plan de QA
Si No
 Si No
• Plan de producción
Si No

Formato de casos de pruebas funcionales

CASO DE USO

PRUEBA

DESCRIPCIÓN

CONDICIONES DE EJECUCIÓN

MÓDULO

ENTRADA RESULTADO EVALUACIÓN DE OBSERVACIONES

ESPERADO LA PRUEBA

Lista de chequeo de casos de pruebas funcionales

Con el fin de garantizar que los casos de prueba contemplen el 100% de los escenarios a
probar para cada caso de uso; en su construcción deberá tenerse en cuenta la siguiente
lista de chequeo.

Cada conjunto de casos de prueba para cada caso de uso deberá contemplar:

ELEMENTO DEL CASO DE USO CASO DE PRUEBA

Datos de entrada Verificar que los datos de entrada cumplan
con:
 Obligatoriedad
Tipo de datos
Longitud
Estructura
Reglas de Negocio Validar reglas de negocio que afecten los
datos de entrada (Dependencia de datos).
Validar reglas de negocio que afecten los
flujos.
Flujos de Excepción Verificar la ejecución de todos los flujos de
Excepción.
Flujo Básico Verificar la ejecución del flujo básico.
Generalidades: Los casos de prueba deben especificar
exactamente rutas, nombres de archivos,
valores para los datos de entrada. Para
asegurar que las rutas y nombres de
archivos se cumplan; deberá instalarse
una árbol de carpetas predefinido en la
estación donde se ejecutará la prueba.

Formato de pruebas de aceptación de usuario

PREGUNTA CRITERIOS DE EVALUACIÓN

1. ¿Hay términos en idiomas diferentes mezclados? = Se encuentran en todo el
sistema

= Se encuentra en algunas
partes del sistema.

= No se encuentran en ninguna
parte del sistema.
2. ¿Es simple el vocabulario utilizado? = El vocabulario es demasiado
técnico.

= El vocabulario presenta
algunas dificultades de
comprensión.

= El vocabulario es
 completamente comprensible.
3. ¿Se proporciona tiempo suficiente para realizar las entradas = El tiempo es muy limitado.
por teclado?

= El tiempo es limitado para

algunas funcionalidades.

= El tiempo es completamente
suficiente.
4. ¿Hay algún tipo de asistencia para los usuarios que hacen = No existe ninguna ayuda.
uso del sistema por primera vez?

= Se encuentra ayuda en
algunas partes.

= Existen ayudas en todo el

sistema.
3. ¿El sistema es fácil de operar para alguien que no recibió = El sistema es de difícil
capacitación en su operación? comprensión.

= El sistema es fácil de operar

en algunas de sus
funcionalidades.

3 = El sistema es
completamente fácil de operar.
6. ¿Se entienden la interfaz y su contenido? = No se entiende su interfaz.

= La interfaz se entiende en
algunas partes.

= La interfaz es completamente
entendible.
7. ¿Resulta fácil identificar un objeto o una acción? = Es difícil identificar los objetos
o acciones.

= Se pueden identificar los

objetos y acciones en algunas
partes del sistema.
 = Todos los objetos y acciones
son fácilmente identificables.
8. ¿Resulta fácil entender el resultado de una acción? = Los resultados de las acciones
no son entendibles.

= Los resultados de las acciones

son entendibles en algunas
partes o la mayor parte del
sistema.

= Todos los resultados de las

acciones son entendibles.
9. ¿Está diseñada la interfaz para facilitar la realización = La interfaz es difícil de usar.
eficiente de las tareas de la mejor forma posible?

= La interfaz es difícil de usar en

algunas partes del sistema.

= La interfaz es completamente
sencilla de usar.
10. ¿Son apropiados los mensajes presentados por el = Los mensajes nones son
sistema? apropiados.

= Los mensajes son apropiados

en algunas partes del sistema.

= Todos los mensajes son

apropiados y fáciles de
comprender.
11. ¿Actúa el sistema en la prevención de errores? 1 = El sistema no previene
errores del usuario.

= El sistema previene algunos o

la mayoría de los errores del
usuario.

= El sistema previene cualquier

error que pueda cometer el
usuario.
12. ¿El sistema informa claramente sobre los errores = El sistema no informa de
 presentados? manera adecuada sobre los
errores cometidos.

= El sistema informa de manera

adecuada algunos o la
mayoría de los errores
cometidos por el usuario.

= El sistema informa de forma

adecuada todos los errores
cometidos por el usuario.
13. ¿Se utiliza mensajes y textos descriptivos? = Los mensajes de texto no son
descriptivos.

= La mayoría de los textos son

descriptivos o fáciles de
interpretar

= Todos los textos son

descriptivos o fáciles de
interpretar.
14. ¿Permite una cómoda navegación dentro del producto y = La navegación no es sencilla.
una fácil salida de éste?

= La navegación presenta
algunas dificultades.

= La navegación es sencilla,
requiere de pocos vínculos para
accedes a las funcionalidades
del sistema.
15. ¿Se permite al usuario personalizar la interfaz? = La interfaz no es
personalizable.

= La interfaz es personalizable
con algunas restricciones.

= La interfaz es completamente
personalizable.

Formato de casos de pruebas técnicos

Formato que se utilizará para documentar las pruebas técnicas; estas pruebas serán
documentadas conforme avance el desarrollo de la solución y se tengan versiones
liberadas sobre las que se aplicarán estas pruebas.

CASO DE USO
PRUEBA
DESCRIPCIÓN

CONDICIONES DE
EJECUCIÓN
MÓDULO

ENTRADA RESULTADO EVALUACIÓN OBSERVACIONES

ESPERADO DE LA
PRUEBA

Formato de matriz de casos de uso VS casos de prueba funcionales

Formato de matriz de trazabilidad que se llevara para asegurar que sean probados todos
los aspectos definidos dentro de los casos de uso.

Caso de Uso Aspecto a Evaluar Caso de Prueba

 1. Datos Entrada
Obligatoriedad <Identificación del caso de
prueba que evalúa
Obligatoriedad>
Longitud <Identificación del caso de
prueba que evalúa Longitud>
Tipo de Dato <Identificación del caso de
<Identificación del caso de prueba que evalúa Tipo de
uso> dato>
2. Reglas de Negocios
Relacionadas con datos de
entrada
<Lista de casos de prueba> <Identificación del caso de
prueba que evalúa la regla
de negocio>
3. Reglas de Negocios
<Lista de casos de prueba> <Identificación del caso de
prueba que evalúa la regla
de negocio>
4. Flujos de Excepción
<Lista de flujos de <Identificación del caso de
excepción> prueba que evalúa los flujos
de excepción
5. Flujos Alternos
<Lista de casos de flujos <Identificación del caso de
alternos> prueba que evalúa los flujos
alternos.>
6. Flujo Básico <Identificación del caso de
prueba que evalúa el flujo
básico.
Formato de matriz de requerimientos no funcionales VS casos de pruebas
técnicos

Formato de matriz de trazabilidad que se llevará para asegurar que sean probados todos
los aspectos técnicos de la solución; en esta matriz se registrará cada caso de prueba
técnico y requerimiento no funcional que será verificado.

CÓDIGO DE LA PRUEBA REQUERIMIENTO NO

TÉCNICA FUNCIONAL OBSERVACIONES
VERIFICADO

Formato de lista de chequeo

Formato que se utilizará para lista de chequeo de las pruebas ejecutadas.

TIPO DE Versión Fecha de EJECUTADA CUMPL NO Observaciones

PRUEBA de Ejecució E CUMPLE
n
Ejecución
Punto 7
Defina las plantillas, procedimientos, listas de chequeo, herramientas de uso
básicas para su trabajo usando la plataforma y entorno de software presente en la
empresa. Recuerde que nada justifica la compra de herramientas automatizadas
si no hay resultados visibles de mejora con el software básico de la empresa.
Herramientas que le permitan administrar el know-how, capacitar al equipo, medir
su desempeño y documentar las experiencias adquiridas.

Elementos de Pruebas

Genesis Gourmet consta de nueve módulos usuario, mesas, ambientes,

facturación, permisos, pedidos, reportes, correos, cliente, productos cada uno de
ellos tiene las siguientes características:
En el módulo Usuarios manejará pestañas registrar y ver.
En el módulo Mesas manejará pestañas registrar y ver.
En el módulo Ambientes manejará pestañas registrar y ver.
En el módulo Facturas manejará pestañas registrar y ver.
En el módulo Permisos manejará pestañas registrar y ver.
En el módulo Pedidos manejará pestañas registrar y ver.
En el módulo Reportes manejará pestañas registrar y ver.
En el módulo Correos manejará pestañas registrar y ver.
En el módulo Clientes manejará pestañas registrar y ver.

En el módulo Productos manejará las pestañas registrar, ver, registrar tipo

producto y ver tipo producto.
En el módulo Clientes manejará las pestañas registrar ver.
En el módulo Cocina manejará las pestañas ver.

Integrantes Formatos
Edward Yair Ortega Casos de prueba

Edward Yair Ortega Matriz de resultados

Edward Yair Ortega Plan de aceptación
Edward Yair Ortega Plan de pruebas

3. PRUEBAS

CASO DE USO Autenticarse en el

sistema
PRUEBA CP1
DESCRIPCIÓN Comprobar que el
gerente pueda
loguearse en el
sistema
CONDICIONES DE EJECUCIÓN Tener abierta la
pagina de inicio de
sesión del sistema
MÓDULO Gerente

ENTRADA RESULTADO EVALUACIÓN DE OBSERVACIONES

ESPERADO LA PRUEBA
999999, 1234 Ingresar a interfaz del Aprobada Para iniciar sesión se debe
rol correspondiente dar click en el boton
en este caso la ingresar, al dar enter no
interfaz del módulo envia los datos por lo tanto
del gerente. no loguea.

CASO DE USO Gestionar usuarios

PRUEBA CP2
 DESCRIPCIÓN Comprobar que el
gerente pueda activar
usuarios

CONDICIONES DE EJECUCIÓN Estar logueado en el

sistema.

MÓDULO Gerente

ENTRADA RESULTADO EVALUACIÓN DE OBSERVACIONES

ESPERADO LA PRUEBA

12345, activo Cambio de estado en Aprobada El boton de activar solo

la tabla. aparece si el estado del
usuario es "Inactivo". Al
activar el usuario este
puede ingresar al sistema.

CASO DE USO Gestionar perfil

PRUEBA CP1
DESCRIPCIÓN El proveedor puede
modificar sus datos.
CONDICIONES DE EJECUCIÓN Estar logueado en el
sistema.
MÓDULO Proveedor

ENTRADA RESULTADO EVALUACIÓN DE OBSERVACIONES

1031168192, Andres, Luna,
asluna7@misena.edu.co, cll 65,
7623428, 18, 1996-11-30,
masculino, 1234.
ESPERADO LA PRUEBA
Actualización de Aprobada No sale mensaje de
datos del proveedor confirmación de
en la base de datos. actualización. La
actualización de datos se
muestra luego de que el
proveedor cierre y vuelva a
abrir sesión. No es
obligatorio cambiar todos
los datos.
CASO DE USO Gestionar
postulaciones de
aporte a
pedidos
PRUEBA CP2
DESCRIPCIÓN Comprobar que el
proveedor pueda
aportar cierta
cantidad a un
pedido.

CONDICIONES DE EJECUCIÓN Estar logueado en el

sistema.

MÓDULO Proveedor

ENTRADA RESULTADO EVALUACIÓN DE OBSERVACIONES

ESPERADO LA PRUEBA
1, 1031168192, 1, 320, 1 Disminución en la No aprobada La cantidad si se actualiza
cantidad que aparece en el panel, es decir, se
en el panel, disminuye pero no muestra
deshabilitar botón mensaje ni deshabilita el
aportar, mensaje de boton
confirmación de
aporte

Downloaded by edward ortega (charly87275@gmail.com)

CASO DE USO Gestionar usuarios

PRUEBA CP1
DESCRIPCIÓN Comprobar que el
gerente pueda
inactivar usuarios
CONDICIONES DE EJECUCIÓN Estar logueado en el
sistema.
MÓDULO Gerente
ENTRADA RESULTADO EVALUACIÓN DE OBSERVACIONES
ESPERADO LA PRUEBA
12345, inactivo Cambio de estado en Aprobada El boton inactivar solo
la tabla. aparece si el estado del
usuario es "Activo". Al
cambiar el estado a
"Inactivo" el usuario no
podrá loguearse en el
sistema.

CASO DE USO Gestionar solicitudes

de pedidos
PRUEBA CP2
DESCRIPCIÓN Comprobar que el
gerente pueda
publicar las
solicitudes de
pedidos
CONDICIONES DE EJECUCIÓN Estar logueado en el
sistema.
MÓDULO Gerente

ENTRADA RESULTADO EVALUACIÓN DE OBSERVACIONES

ESPERADO LA PRUEBA
1, publicado Cambio de estado en Aprobada El boton publicar solo
la tabla. Publicación aparece si el estado del
del pedido en la pedido es "Pendiente". Al
interfaz del cambiar el estado a
proveedor. "Publicado" el estado
cambia en la tabla y en la
interfaz del proveedor se
mostrara esa pedido.

Inicio de Sesión

CASO DE USO Ingresar al Sistema

PRUEBA 1.0
DESCRIPCIÓN Este caso de
prueba permite
ingresar al sistema
CONDICIONES DE Óptima
EJECUCIÓN
MÓDULO Login

ENTRADA RESULTADO EVALUACIÓN DE LA OBSERVACIONES

ESPERADO PRUEBA
1. Dirigirse al botón Redirección a la página Aprobada Cumple
“Iniciar sesión “en la parte inicial del rol
Central de la página. correspondiente.
2. Llenar los campos
“Documento” y
“Contraseña”
3. Dar clic en el botón
Ingresar.

1. Si el usuario se 1. El sistema mostrará un

encuentra bloqueado no
podrá ingresar.
2. El Sistema no permitirá
el ingreso de sesión si el
usuario ingresa mal el
documento y/o contaseña
mensaje indicando que
se encuentra bloqueado
2. No podrá ingresar al
sistema y arrojará un
mensaje indicando que
ha ingresado mal el
documento o la
contraseña.

CASO DE USO
PRUEBA 1.0
DESCRIPCIÓN El sistema debe permitir al
administrador modificar
datos del personal en el
sistema
CONDICIONES DE Optima
EJECUCIÓN
MÓDULO Usuarios
ENTRADA RESULTADO ESPERADO EVALUACIÓN DE LA OBSERVACIONES
PRUEBA

CASO DE USO Bloquear usuarios

PRUEBA 1.0
DESCRIPCIÓN El sistema debe permitir al
administrador bloquear
usuarios del sistema.

CONDICIONES DE Optima
EJECUCIÓN
MÓDULO Usuarios

ENTRADA RESULTADO ESPERADO EVALUACIÓN DE LA OBSERVACIONES

PRUEBA
1.Ingresar con el perfil de A continuación le Aprobada Al ejecutar esta acción
administrador al sistema. aparecerá un mensaje no preguntará si
desea o no
2.En la barra de diciendo que el usuario se bloquearlo, la función
navegación, seleccionar el ha bloqueado o se ejecuta
modulo de usuarios. inmediatamente al
3. Seleccionar la opción desbloqueado
seleccionar el botón
de "Listar usuarios" correctamente.
4.Usted va a evidenciar
una tabla con lista con
todos los usuarios.
5. Al final de cada registro
seleccione el notón blanco
con el icono de un
candado.