AP09-AA10-EV02-Diseno-Ejecucion-Pruebas-SI - Lucia Posse

FACTURACIÓN Y CONTROL CUENTAS POR PAGAR.
Diseño y ejecución de plan de pruebas del sistema de información.
Lucia Alejandra Posse Forero.
Teléfono (+57) 316 6762505 - www.luciaposse.com

Tabla de contenido
1. INTRODUCCION...............................................................................................................3
2. ALCANCE DE LAS PRUEBAS DEL SISTEMA DE INFORMACION..............................4
3. DEFINICIONES Y ACRONIMOS.......................................................................................4
4. REFERENCIAS..................................................................................................................6
5. VISION GENERAL DEL DOCUMENTO............................................................................6
6. DESCRIPCION DEL AMBIENTE DE PRUEBAS Y PRECONDICIONES........................6
7. PLAN DE PRUEBAS.........................................................................................................7
7.5.1 Módulo Login.............................................................................................................9
7.5.2 Módulo usuario........................................................................................................13
7.5.3 Módulo Terceros.....................................................................................................18
7.5.4 Módulo Facturación.................................................................................................23
7.5.3 Módulo inventarios..................................................................................................28
7.11 ANÁLISIS DEL RESULTADO DEL PLAN DE PRUEBAS............................................33
7.10.1 MÉTRICAS DE EJECUCIÓN............................................................................................ 33
7.12 AJUSTES Y RECOMENDACIONES........................................................................33
1. INTRODUCCION...............................................................................................................3
2. OBJETIVOS.......................................................................................................................4
4. PERFIL DE LOS USUARIOS............................................................................................5
5. CRONOGRAMA................................................................................................................5
6. PLAN DE CAPACITACION...............................................................................................6
REQUERIMIENTOS:................................................................................................................6
7. CONSIDERACIONES O RECOMENDACIONES ADICIONALES....................................6

8. ANEXOS............................................................................................................................7

[1.] INTRODUCCION
El desarrollo de software, desde su diseño hasta su puesta en producción, debe pasar

por varios momentos en los que este software va evolucionando, sin embargo, hay
una fase que se debe considerar y reconocer su importancia y necesidad.
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de

software. Dependiendo del tipo de pruebas, estas actividades podrán ser
implementadas en cualquier momento de dicho proceso de desarrollo. Existen
distintos modelos de desarrollo de software, así como modelos de pruebas. A cada
uno corresponde un nivel distinto de involucramiento en las actividades de
desarrollo.
El control de la calidad de software lleva consigo aplicativos que permiten realizar
pruebas autónomas y masivas permitiendo así la verificación desde el punto de vista
estático y de caja blanca, es decir pruebas donde se analiza el software sin ejecutar el
software mediante el código fuente del mismo.

[2.] ALCANCE DE LAS PRUEBAS DEL SISTEMA DE INFORMACION
El proceso de verificación y validación del software del proceso de aseguramiento de

la calidad, 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.
[3.] DEFINICIONES Y ACRONIMOS

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.
Casos de Prueba: Un conjunto de entradas, condiciones de ejecución y resultados

esperados, diseñados para un objetivo particular.
Requerimiento funcional: Se refiere a las funciones del software, todo sobre ‘’lo que el
sistema debe hacer
Requerimiento no funcional: Son considerados como atributos de calidad del

software y se refiere a características como seguridad, usabilidad, escalabilidad, etc.
Prueba Funcional: Comprueban las características del aplicativo, verificando que

comporte como lo esperado.
Testing manual: Son pruebas (exploratorias, usabilidad, funcionales, etc) que realiza
una persona a partir de casos de prueba con el fin de detectar bugs y reportarlas.
Testing automatizado: Son pruebas que permiten utilizar herramientas de software de

forma repetitiva y automática sobre otro software.
Tester: Profesional que se encarga de asegurar la calidad y simular el rendimiento de

un producto software realizando determinadas pruebas para encontrar fallos (bugs).
Prueba de caja blanca (White box testing): Son pruebas realizadas por las personas
que se relacionan con el código (developers) en el que se examina la estructura del
software como el código, flujos de datos y la lógica del sistema.
Prueba de caja negra (Black box testing): Es un método que está enfocado en
examinar la funcionalidad del aplicativo sin tener acceso directo al código y
desconociendo la estructura interna del sistema
Prueba de caja gris: Una combinación de caja negra y caja blanca que permite mayor
interacción con el sistema y el código pero manteniendo un nivel de restricción

Equivocación: Una acción del ser humano que produce un resultado incorrecto.
Gestión de la Calidad Control de Calidad Plan de Aseguramiento de la Calidad (PAQ)
Verificación Y Validación Sistema de Gestión de la calidad 5 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.
Validación: Un conjunto diferente de actividades que aseguran que el software

construido se ajusta a los requisitos del cliente.
Testware: Es el producto resultante de las pruebas. 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)
[4.] REFERENCIAS
AP01-AA2-EV05-Especificacion-Requerimientos II
1.[5.] VISION GENERAL DEL DOCUMENTO

Este documento, tiene como finalidad entregar las pautas y definir la estrategia que se
seguirá para llevar a cabo la certificación del software de la aplicación web para la
empresa Foto estudio Posse y el sistema de facturación y control de cuentas por
cobrar versión 1.0,
El objetivo general del plan es establecer un cronograma y condiciones para la

aplicación de las pruebas de tal forma que se genere la certificación requerida.
2.[6.] DESCRIPCION DEL AMBIENTE DE PRUEBAS Y PRECONDICIONES
Las Pruebas se integran dentro de las diferentes fases del ciclo de vida del software.
Así se ejecuta un programa y mediante técnicas se trata de descubrir sus errores
conseguir la calidad esperada. Para determinar dicho nivel de calidad se deben
efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento
respecto de las especificaciones iniciales del sistema
Es necesario probar los nuevos programas en un entorno de pruebas separado
físicamente del de producción. Para crear un entorno de pruebas en una máquina
independiente de la de producción es necesario crear las mismas condiciones que en
la máquina de producción.
Es posible clasificar las pruebas en dos grandes grupos, en uno están las pruebas de
caja negra y caja blanca y por otro están las pruebas manuales y automáticas. Para
efectos de este documento realizaremos las pruebas de caja negra, con un enfoque
funcional y nos centraremos en las funciones entradas y salidas.
3.[7.] PLAN DE PRUEBAS

El plan de pruebas permite, especificar la secuencia de pasos a seguir de acuerdo con
la cantidad y distribución de módulos que contiene la aplicación. A continuación, se
muestra el plan de pruebas de software.
El plan de pruebas pretende mostrar que las funcionalidades de cada módulo, de

manera que se logre determinar que ejecutan las acciones cuyo objetivo deben
cumplir: Permitir la autenticación del usuario, creación de terceros, generar facturas y
generación de diferentes reportes
3.1[7.1] ALCANCE DE LAS PRUEBAS
Realizar pruebas funcionales a los siguientes módulos: Modulo usuarios,

modulo facturación, terceros, modulo inventarios, módulo de reportes y login junto
con cada una de las funcionalidades que se identificaron y eligieron para probar:
Modulo usuarios: Crear usuario, editar usuario, Eliminar usuario, actualización de

cambios, cancelación Terceros cambios realizados y listado de usuarios creados.
Modulo Terceros: Crear tercero, editar tercero, Eliminar tercero, actualización de
cambios, cancelación de cambios realizados y listado de tercero creados.
Modulo facturación: Crear facturas, editar facturas, Eliminar facturas, actualización de
cambios, cancelación de cambios realizados y listado de facturas creados.
Modulo inventario: Crear productos, editar productos, Eliminar productos,
actualización de cambios, cancelación de cambios realizados y listado de productos
creados.
Modulo reportes: usuarios, terceros, productos y facturas
Login: Registro de usuario, validación de usuario, ingreso al sistema,
Diligenciamiento de formulario
3.2[7.2] METODOLOGIA
A continuación se detalla la metodología usada en el proceso de pruebas, la
cual se compone de las etapas de planeación, diseño y ejecución:
Planeación Durante la planeación se realiza una prueba exploratoria de la aplicación

para visualizar las funcionalidades que contiene cada módulo y si existen fallas que
pueden ser reportadas.
Diseño Se utiliza un formato para registrar el nombre de la prueba, las

precondiciones, acciones y resultados esperados y las postcondiciones.
Ejecución De acuerdo con el formato establecido se procede a ejecutar la prueba de

cada funcionalidad que compone el módulo seleccionado y se registran los hallazgos.
3.3[7.3] CRITERIOS DE ACEPTACION
La aplicación Facturación y control de cuentas por cobrar y pagar, fue evaluada y se

ejecutaron el 100% de los casos de prueba planteados en cada uno de los módulos
seleccionados. Se encontraron defectos y se realizaron sugerencias para la mejora en
versiones posteriores, sin embargo, se espera que el cliente del visto bueno al validar
las métricas que se entregan.
Criterios de aceptación
El proceso de pruebas funcionales se da por terminado una vez que:
Se han ejecutado el 100% de los casos de prueba diseñados para este proyecto y su
resultado ha sido exitoso.
El 100% de los defectos detectados en la ejecución de pruebas han sido solucionados

y se ha validado dicha solución por parte de pruebas.
Cuando, a pesar de no cumplirse en su totalidad el punto anterior, el dueño del

negocio, gerente manifieste que los defectos no son críticos para salir a producción
(los defectos pasarían inmediatamente a un estado terminal de “Siguiente Versión”).

3.4[7.4] CRONOGRAMA DE PRUEBAS
Se encuentra en la propuesta de las pruebas para 14 mesmeses,
3.5[7.5] DISEÑO DE CASOS DE PRUEBA
El diseño de casos de prueba permite establecer las precondiciones,

postcondiciones y los pasos a seguir, de acuerdo con los criterios de aceptación
sobre el módulo que se evalúa; para la aplicación seleccionada, se diseñaron casos
de prueba correspondientes a los módulos: Mis alertas, búsqueda de ofertas y login.
En esta sección se detalla el diseño de casos de prueba y su ejecución
7.5.1 Módulo Login
Nombre de caso de prueba: Validación Usuario
Número de la prueba: VAL_Cp01
Descripción de la prueba Este caso de prueba tiene como objetivo

verificar la existencia del usuario en el
sistema
Precondiciones de la prueba El usuario debe tener acceso al sistema
El usuario debe dar clic en el botón Login
El usuario debe tener un usuario creado en
el sistema
Paso a paso de la prueba

1. Se ingresa al sistema
2. Dar clic en el opción Login en la pantalla de bienvenida de la pagina
3. Digitar los campos usuario y contraseña

Postcondiciones
Criterios de aceptación Exitoso (S/N)

Permite digitar un usuario y X
una contraseña
Permite acceder al sistema en X
caso de encontrar registrado al
usuario
Bloquea el acceso al sistema X
en caso de encontrar algún
error en los campos usuario y
contraseña

Nombre de caso de prueba: Ingreso Sistema
Número de la prueba: ING_Cp02
Descripción de la prueba Este caso de prueba tiene como objetivo verificar

que el ingreso al sistema se puede realizar sin
ningún inconveniente
Precondiciones de la El usuario debe tener acceso al sistema
prueba El usuario debe dar clic en el botón Login
El usuario debe tener un usuario creado en el
sistema
El sistema debe tener campos donde digitar un

usuario y una contraseña
El caso de prueba 2 –
validación usuario debe
haberse ejecutado
correctamente

1. Se ingresa al sistema
2. Dar clic en el opción Login en la pantalla de bienvenida de la pagina
3. Digitar los campos usuario y contraseña

Postcondiciones
El sistema accede al ingresar el usuario y la contraseña
El sistema avisa al usuario si existe alguna inconsistencia en el nombre de

usuario o la contraseña
En caso de no haber inconsistencias, el sistema permite ingresar
El usuario queda con vía libre para navegar por el sistema
El sistema habilita los módulos permite acceder al módulo principal de

navegación
Permite digitar un X
usuario y una contraseña
Permite acceder al X
sistema en caso de
encontrar registrado al
usuario
sistema por medio de la
login
7.5.2 Módulo usuario
Nombre de caso de prueba: Crear Usuario
Número de la prueba: USUARIOC_CP03
Fecha de inicio y fin de 30/10/2020

ejecución:
Descripción de la prueba Este caso de prueba tiene como objetivo

verificar que se puede registrar un nuevo usuario
en el sistema
Precondiciones de la prueba El usuario debe tener acceso al sistema
El usuario debe dar clic en el botón Crear usuario
El usuario debe tener una cuenta de correo ,
contraseña y datos
El usuario debe estar autenticado en el sistema.
No debe existir una usuario con el mismo login
Ningún campo debe quedar vacío
1. Ingresar a la sitio web
2. Dar clic en el botón Usuarios en la parte superior izquierda de la pagina
3. Al desplegarse el módulo de Usuario, dar clic en el botón ‘Crear usuario’
4. Diligenciar la información y guardar los cambios
Postcondiciones
Permite acceder al sistema X
Permite ingresar al módulo X
usuario
Permite crear el usuario X
Nombre de Caso de prueba: Editar Usuario
Número de la prueba: USUARIOE_CP04

Descripción de la prueba El objetivo de la prueba es verificar que la
aplicación permite modificar los datos de unos
usuarios existentes y almacenarlos.
Precondiciones de la El usuario debe estar autenticado en el sistema.
prueba
En el módulo usuario debe tener diligenciados los
campos obligatorios.
Debe existir una usuario previamente creado
Debe seleccionar al menos una casilla a modificar
Ningún campo puede quedar vacío.

Paso a paso de la prueba:
1. Presionar botón Editar del módulo de usuarios

2. En el campo a modificar, borrar el texto actual y digitar texto diferente.
3. Presionar el botón Guardar.
Postcondiciones:
Debe mostrar una notificación en pantalla que confirma los cambios realizados
en la usuario. Debe mostrar los nuevos datos del usuario editado en el mismo
pantalla de la sección Usuarios
Criterios de aceptación Exitoso S/N No. Soporte
Al dar clic sobe vinculo Editar usuario, debe X

mostrar el formulario en el mismo pantalla
Debe permitir borrar y digitación nuevo texto en X
el campo a modificar.
Debe permitir la selección de una o más casillas X
diferentes actuaizar
Debe notificar confirmación de cambios X
realizados al presionar botón Guardar.
Nombre de Caso de prueba: Eliminar Usuario
Número de la prueba: USUARIOE_CP05

aplicación permite borrar por completo un usuario
existente.
prueba
Debe existir un usuario previamente creado.
1. Presionar el botón Eliminar usuario.

2. Confirmar acción presionando botón Eliminar

Postcondiciones:
El sistema debe confirmar la eliminación y no mostrar el usuario nuevamente
en ninguna consulta
Debe permitir la eliminación total del usuario al X

presionar botón Eliminar.
No debe permitir deshacer la acción realizada. X
Puede impedir la ejecución de la acción al X
presionar el botón Cancelar.
En la sección usuarios, el usuario eliminado no X
debe aparecer.

Nombre de Caso de prueba: Listar Usuario
Número de la prueba: LISTU_CP06
Descripción de la prueba El objetivo de la prueba es visualizar los usuarios

creados que se encuentran almacenados en la
base de datos.
prueba
El usuario deberá acceder al sub modulo
“Consulta”
1. Ingresar al módulo de Usuario

2. Ingresar submodulo consulta
3. Visualizar lista de usuarios

Postcondiciones:
Los usuarios que se visualizan en la pantalla corresponden a las creadas.
En la pantalla se visualizan los botones para Crear, Editar y Eliminar usuarios,

con los cuales únicamente se pueden realizar cambios.
Debe visualizarse el título de la usuario y demás X

campos asociados
Debe visualizarse los botones para crear, editar X
o eliminar cada usuario.
7.5.3 Módulo Terceros
Nombre de caso de prueba: Crear tercero
Número de la prueba: TERCEROC_CP07
Descripción de la Este caso de prueba tiene como objetivo verificar

prueba que se puede registrar un nuevo Tercero
(Proveedor o cliente) en el sistema
Precondiciones de la El Usuario debe tener acceso al sistema
prueba El Usuario debe dar clic en el botón Crear Tercero
El Usuario debe estar autenticado en el sistema.
No debe existir una Tercero en la aplicación
Paso a paso de la
prueba
2. Dar clic en el botón del módulo Terceros en la parte superior de la pagina
3. Al desplegarse el módulo de Tercero, dar clic en el botón ‘Crear Tercero’

Postcondiciones
sistema
Permite ingresar al X
módulo terceros
Permite crear el Tercero X
Nombre de Caso de prueba: Editar Tercero
Número de la prueba: TERCEROE_CP08

aplicación permite modificar los datos de los
Terceros existentes y almacenarlos.

prueba
En el módulo Tercero deben tener diligenciados los
campos obligatorios del tercero a editar
Debe existir una Tercero previamente creado

1. Presionar botón Editar del módulo de Terceros

2. en el campo a modificar, borrar el texto actual y digitar texto
diferente.
3. Presionar el botón “Actualizar”.
Postcondiciones:
en el Tercero. Debe mostrar los nuevos datos del Tercero editado en el mismo
pantalla de la sección Terceros

Al dar clic sobe vinculo Editar Tercero, debe X

mostrar el formulario en la misma pantalla
Debe permitir borrar y digitar un nuevo texto en X
diferentes actualizar
Nombre de Caso de prueba: Eliminar Tercero
Número de la prueba: TERCEROE_CP09

aplicación permite borrar por completo un Tercero
existente.
prueba
Debe existir un Tercero previamente creado.

3. Presionar el botón Eliminar Tercero.

Postcondiciones:
El sistema debe confirmar la eliminación y no mostrar el Tercero nuevamente
en ninguna consulta
Debe permitir la eliminación total del Tercero al X

En la sección Terceros, el Tercero eliminado no X
debe aparecer.

Nombre de Caso de prueba: Listar Tercero
Descripción de la prueba El objetivo de la prueba es visualizar los Terceros

creados que se encuentran almacenados en la
base de datos.
prueba
“Consulta”
1. Ingresar al módulo de Tercero

3. Visualizar lista de Terceros y sus respectivos campo

Postcondiciones:
Los Terceros que se visualizan en la pantalla corresponden a los creados.
En la pantalla se visualizan los botones para Crear, Editar y Eliminar Terceros,

con los cuales únicamente se pueden realizar cambios.
Debe visualizarse el título de la Tercero y demás X

campos asociados
o eliminar cada Tercero.
7.5.34 Módulo inventarios Facturación
Nombre de caso de prueba: Crear Producto factura
Número de la prueba: ProductoFACTURASC_CP011

Descripción de la Este caso de prueba tiene como objetivo verificar
prueba que se puede registrar un nuevoa ProductoFactura en
el sistema
No debe existir una Producto en la aplicación
[2.] Dar clic en el botón del módulo ProductoFacturas en la parte superior de la pagina
[3.] Al desplegarse el módulo de inventario, dar clic en el botón ‘Crear Producto
2.[4.] Diligenciar la información y guardar los cambios
Postcondiciones
sistema
módulo
productoFacturas
Permite crear el X

ProductoFactura
Nombre de Caso de prueba: Editar ProductoFactura
Número de la prueba: PRODUCTOFACTURAE_CP12

aplicación permite modificar los datos de los
ProductoFacturas existentes y almacenarlos.
prueba
En el módulo inventario deben tener diligenciados
los campos obligatorios del productoFactura a editar
Debe existir una ProductoFactura previamente

creado


[1.] Presionar botón Editar del módulo de ProductoFacturas

1.[2.] En el campo a modificar, borrar el texto actual y digitar texto
diferente.
2.[3.] Presionar el botón “Actualizar”.
Postcondiciones:
en el ProductoFactura. Debe mostrar los nuevos datos del ProductoFactura
editado en la misma pantalla de la sección Inventarios
Al dar clic sobe vinculo Editar ProductoFactura, X

debe mostrar el formulario en la misma pantalla
Debe permitir borrar y digitar un nuevo texto en X

Nombre de Caso de prueba: Eliminar ProductoFactura
Número de la prueba: PRODUCTOFACTURAE_CP13

aplicación permite borrar por completo un
ProductoFactura existente.
prueba
Debe existir un ProductoFactura previamente
creado.
[1.] Presionar el botón Eliminar ProductoFactura.

[2.] CConfirmar acción presionando botón Eliminar
Postcondiciones:
El sistema debe confirmar la eliminación y no mostrar el ProductoFactura
nuevamente en ninguna consulta

Debe permitir la eliminación total del X

ProductoFactura al presionar botón Eliminar.
En la sección ProductoFacturas, el X
ProductoFactura eliminado no debe aparecer.
Nombre de Caso de prueba: Listar ProductoFactura

Descripción de la prueba El objetivo de la prueba es visualizar los
ProductoFacturas creados que se encuentran
almacenados en la base de datos.
prueba
“Consulta”
1. Ingresar al módulo de inventarios

[3.] Visualizar lista de ProductoFacturas y sus respectivos campo
Postcondiciones:
Los ProductoFacturas que se visualizan en la pantalla corresponden a los

creados.
En la pantalla se visualizan los botones para Crear, Editar y Eliminar

ProductoFacturas, con los cuales únicamente se pueden realizar cambios.
Debe visualizarse el título de la ProductoFactura X

y demás campos asociados
o eliminar cada ProductoFactura.

7.5.3 Módulo inventarios
Nombre de caso de prueba: Crear Producto
Número de la prueba: PRODUCTOSC_CP015
Descripción de la Este caso de prueba tiene como objetivo verificar que

prueba se puede registrar un nuevo Producto en el sistema
No debe existir una Producto en la aplicación
4. Dar clic en el botón del módulo Productos en la parte superior de la pagina
5. Al desplegarse el módulo de inventario, dar clic en el botón ‘Crear Producto’
Postcondiciones
sistema
módulo productos

Permite crear el Producto X
Nombre de Caso de prueba: Editar Producto
Número de la prueba: PRODUCTOE_CP16
Descripción de la prueba El objetivo de la prueba es verificar que la aplicación

permite modificar los datos de los Productos existentes
y almacenarlos.
prueba
En el módulo inventario deben tener diligenciados los
campos obligatorios del producto a editar
Debe existir una Producto previamente creado

3. Presionar botón Editar del módulo de Productos

4. En el campo a modificar, borrar el texto actual y digitar texto diferente.
5. Presionar el botón “Actualizar”.
Postcondiciones:

Debe mostrar una notificación en pantalla que confirma los cambios realizados en el
Producto. Debe mostrar los nuevos datos del Producto editado en la misma pantalla
de la sección Inventarios
Al dar clic sobe vinculo Editar Producto, debe X

mostrar el formulario en la misma pantalla
Debe permitir borrar y digitar un nuevo texto en el X
campo a modificar.
Debe notificar confirmación de cambios realizados X
al presionar botón Guardar.
Nombre de Caso de prueba: Eliminar Producto
Número de la prueba: PRODUCTOE_CP17
Descripción de la prueba El objetivo de la prueba es verificar que la aplicación

permite borrar por completo un Producto existente.
prueba
Debe existir un Producto previamente creado.
1. Presionar el botón Eliminar Producto.


Postcondiciones:
El sistema debe confirmar la eliminación y no mostrar el Producto nuevamente en
ninguna consulta
Debe permitir la eliminación total del Producto al X

Puede impedir la ejecución de la acción al presionar X
el botón Cancelar.
En la sección Productos, el Producto eliminado no X
debe aparecer.

Nombre de Caso de prueba: Listar Producto
Descripción de la prueba El objetivo de la prueba es visualizar los Productos

creados que se encuentran almacenados en la base
de datos.
prueba
El usuario deberá acceder al sub modulo “Consulta”
3. Ingresar al módulo de inventarios

5. Visualizar lista de Productos y sus respectivos campo
Postcondiciones:
Los Productos que se visualizan en la pantalla corresponden a los creados.
En la pantalla se visualizan los botones para Crear, Editar y Eliminar Productos, con
los cuales únicamente se pueden realizar cambios.
Debe visualizarse el título de la Producto y demás X

campos asociados
Debe visualizarse los botones para crear, editar o X
eliminar cada Producto.

7.11 ANÁLISIS DEL RESULTADO DEL PLAN DE PRUEBAS
El análisis del resultado del plan de pruebas se realiza mediante las métricas
que permiten medir la cantidad de casos exitosos, no exitosos, aquellos no
ejecutados y la sumatoria por cada funcionalidad. En esta sección se presentan las
métricas identificadas para el proyecto y los informes de seguimiento y final se
encuentran en la matriz de trazabilidad de requisitos adjunta.
7.10.1 Métricas de ejecución
Matriz de ejecución: Métricas de Ejecución de los Casos de Prueba

A continuación se detalla la cantidad de casos de prueba exitosos, fallidos y no
ejecutados.
Responsabl Funcionali Cicl Exitosos No Exitoso No se CP

e dad o ejecutó Totale
# % # % # % s
Lucia Posse Login 1 2 100% 2 0% 0 0% 26
0
Lucia Posse Usuarios 1 4 100% 0 20% 1 200 45
4 0 %
Lucia Posse Terceros 1 42 10050 4 33.350% 0 0% 64
% 2 %
Lucia Posse Facturación 1 4 100% 0 0 0 0% 4
Lucia Posse Inventarios 1 24 10050 2 50% 0 0% 4

% 4 %
7.12 AJUSTES Y RECOMENDACIONES.
Luego de la ejecución de las pruebas de cada módulo, fue posible encontrar defectos y
sugerencias.
Se determinó que la naturaleza de una de las sugerencias realizadas es de tipo:
Funcionalidad, porque en el caso de la edición y la eliminación de terceros e inventarios se
detectaron deficiencias, como botones sin funcionar correctamente, Se estimó que la
severidad es de alto impacto dado que, para su implementación se necesita: Ajustar estos
parámetros. Sin embargo, la prioridad es baja, porque se tiene proyectado implementarla en
el ambiente de pruebas para la próxima versión
El proceso de pruebas es indispensable para garantizar la calidad de un sistema de

información, por este motivo se debe evaluar cada uno de los módulos y su funcionamiento.
La calidad no solo se evalúa en la parte lógica, sino que también garantizara el
funcionamiento en las interfaces que permiten la navegación en el sistema

AP09-AA10-EV02-Diseno-Ejecucion-Pruebas-SI - Lucia Posse

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

AP09-AA10-EV02-Diseno-Ejecucion-Pruebas-SI - Lucia Posse

Cargado por

Copyright:

Formatos disponibles

FACTURACIÓN Y CONTROL CUENTAS POR PAGAR.

Diseño y ejecución de plan de pruebas del sistema de información.

Lucia Alejandra Posse Forero.

Teléfono (+57) 316 6762505 - www.luciaposse.com

4. PERFIL DE LOS USUARIOS............................................................................................5

7. CONSIDERACIONES O RECOMENDACIONES ADICIONALES....................................6

Teléfono (+57) 316 6762505 - www.luciaposse.com

Teléfono (+57) 316 6762505 - www.luciaposse.com

El desarrollo de software, desde su diseño hasta su puesta en producción, debe pasar

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de

Teléfono (+57) 316 6762505 - www.luciaposse.com

El proceso de verificación y validación del software del proceso de aseguramiento de

[3.] DEFINICIONES Y ACRONIMOS

Teléfono (+57) 316 6762505 - www.luciaposse.com

Casos de Prueba: Un conjunto de entradas, condiciones de ejecución y resultados

Requerimiento no funcional: Son considerados como atributos de calidad del

Prueba Funcional: Comprueban las características del aplicativo, verificando que

Testing automatizado: Son pruebas que permiten utilizar herramientas de software de

Tester: Profesional que se encarga de asegurar la calidad y simular el rendimiento de

Teléfono (+57) 316 6762505 - www.luciaposse.com

Fallo: La incapacidad de un sistema o de alguno de sus componentes para realizar

Depuración: El proceso de localizar, analizar y corregir los defectos que se sospecha

Validación: Un conjunto diferente de actividades que aseguran que el software

Testware: Es el producto resultante de las pruebas. Acrónimos  SQA: Software

GUI: Graphical User Interface (Interfaz Gráfica)

1.[5.] VISION GENERAL DEL DOCUMENTO

Teléfono (+57) 316 6762505 - www.luciaposse.com

El objetivo general del plan es establecer un cronograma y condiciones para la

2.[6.] DESCRIPCION DEL AMBIENTE DE PRUEBAS Y PRECONDICIONES

3.[7.] PLAN DE PRUEBAS

Teléfono (+57) 316 6762505 - www.luciaposse.com

El plan de pruebas pretende mostrar que las funcionalidades de cada módulo, de

3.1[7.1] ALCANCE DE LAS PRUEBAS

Realizar pruebas funcionales a los siguientes módulos: Modulo usuarios,

Modulo usuarios: Crear usuario, editar usuario, Eliminar usuario, actualización de

Planeación Durante la planeación se realiza una prueba exploratoria de la aplicación

Diseño Se utiliza un formato para registrar el nombre de la prueba, las

Ejecución De acuerdo con el formato establecido se procede a ejecutar la prueba de

3.3[7.3] CRITERIOS DE ACEPTACION

La aplicación Facturación y control de cuentas por cobrar y pagar, fue evaluada y se

El 100% de los defectos detectados en la ejecución de pruebas han sido solucionados

Cuando, a pesar de no cumplirse en su totalidad el punto anterior, el dueño del

Teléfono (+57) 316 6762505 - www.luciaposse.com

Se encuentra en la propuesta de las pruebas para 14 mesmeses,

3.5[7.5] DISEÑO DE CASOS DE PRUEBA

El diseño de casos de prueba permite establecer las precondiciones,

7.5.1 Módulo Login

Nombre de caso de prueba: Validación Usuario

Número de la prueba: VAL_Cp01

Descripción de la prueba Este caso de prueba tiene como objetivo

Paso a paso de la prueba

Teléfono (+57) 316 6762505 - www.luciaposse.com

Criterios de aceptación Exitoso (S/N)

Teléfono (+57) 316 6762505 - www.luciaposse.com

Número de la prueba: ING_Cp02

Descripción de la prueba Este caso de prueba tiene como objetivo verificar

El sistema debe tener campos donde digitar un

Paso a paso de la prueba

Teléfono (+57) 316 6762505 - www.luciaposse.com

El sistema avisa al usuario si existe alguna inconsistencia en el nombre de

En caso de no haber inconsistencias, el sistema permite ingresar

El usuario queda con vía libre para navegar por el sistema

El sistema habilita los módulos permite acceder al módulo principal de