Plan de pruebas

MEGAMAXI S.A.

Sistema de Ventas y Facturación
Plan de Pruebas
Version 0.9

[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square
brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should
be deleted before publishing the document. A paragraph entered following this style will automatically be set to
normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select
File>Properties and replace the Title, Subject and Company fields with the appropriate information for this
document. After closing the dialog, automatic fields may be updated throughout the document by selecting
Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done
separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field
contents. See Word help for more information on working with fields.]

S. de Ventas y Facturación Version: 0.9
Plan de Pruebas Fecha: 28/12/2011
Documento Plan de Pruebas

Historial de Revisiones
Fecha Version Descripción Autor
28/12/2011 0.9 Versión Preliminar sin revisión del Jorge Robalino M.
Stakeholder

Confidential © MEGAMAXI S.A., 2012 Page 2


Tabla de Contenido
1. Introducción 4
1.1 Propósito 4
1.2 Alcance 4
1.3 Referencias 4

2. Propósito de la evaluación y motivación para la prueba. 4
2.1 Fundamento 4
2.2 Propósito de la evaluación 4

3. Táctica de la Prueba 4
3.1 Técnicas y Tipos de Pruebas 4
3.1.1 Pruebas de integridad a los Datos y a la Base de Datos. 5
3.1.2 Pruebas de Funcionamiento 5
3.1.3 Pruebas de la Interfaz de usuario 13
3.1.4 Prueba del Control de Seguridad y el Acceso 13
3.1.5 Prueba de Falla y Recuperación 14
3.1.6 Prueba de la Configuración 14

4. Criterio de Entrada y Salida 14
4.1 Plan de Prueba 14
4.1.1 Plan de Prueba para el Criterio de Entrada 14
4.1.2 Plan de Prueba para el Criterio de Salida 14

5. Producibles 15
5.1 Resumen de la evaluación de las pruebas 15
5.2 Registro de Incidentes y Requerimientos de Cambio 15

6. Necesidades Ambientales 15
6.1 Elementos base del Software en el ambiente de la Prueba 15

7. Responsabilidades, roles y necesidades de entrenamiento 15
7.1 Personas y roles 15

8. Riesgos, Dependencias, asunciones y restricciones 16

9. Proceso de Gerenciamiento y Procedimientos 16
9.1 Aprobación y firmas 16



Plan de Pruebas
1.Introducción
1.1Propósito
El objetivo del Plan de Pruebas por Iteración es recolectar toda la información necesaria para planear y
controlar las pruebas de funcionamiento realizadas a una iteración determinada. En él se describe el resultado
esperado al probar el software, y constituye el plan de alto nivel utilizado por la gerencia para dirigir las pruebas
de funcionamiento.

1.2Alcance
El documento busca establecer un set de pruebas para cada módulo que verifiquen la funcionalidad del Sistema
de Información a desarrollar para la empresa.

1.3Referencias
- RUP (Rational Unified Process)
- Requerimientos de Software
- Especificación de Casos de Uso

2.Propósito de la evaluación y motivación para la prueba.
2.1Fundamento
Como se especificó en el documento de Visión, la empresa MEGAMAXI S.A. requiere un Sistema de
VENTAS Y FACTURACION que facilite el trabajo administrativo y permita tener un mayor control sobre su
movimiento diario. El Sistema de Información está compuesto por cuatro módulos: Clientes (Información de
los clientes), Inventario (Productos disponibles en la bodega), Facturación (Generación de facturas a partir de
los clientes y el inventario) y Reportes (Información consolidada que permita a la compañía tomar ciertas
decisiones sobre los clientes y la producción de piezas).

2.2Propósito de la evaluación
El set de pruebas definido en éste documento, se encuentra enfocado a la verificación de la funcionalidad de
cada uno de los módulos descritos anteriormente y la obtención de óptimos resultados esperados por el cliente.

3.Táctica de la Prueba

3.1Técnicas y Tipos de Pruebas



3.1.1Pruebas de integridad a los Datos y a la Base de Datos.

Objetivo de la Táctica: Verificar que los datos ingresados en las tablas de la base de datos no sufran
cambios ó se vuelvan corruptos por la manipulación de cada uno de los
módulos. Además comprobar que las relaciones entre tablas en realidad
estén asegurando la integridad referencial de los datos.
Táctica: • Invocar cada acceso a la base de datos por medio de los procesos y
métodos definidos; enviando datos válidos e inválidos.
• Verificar que cada proceso ocurra de manera correcta y que se
retornen los datos esperados en cada caso específico.
Herramientas Copia de Respaldo de la Base de Datos
necesarias:

Criterio de éxito: Retorno y no corrupción de los datos al exponerlos a los procesos
funcionales del sistema.
Consideraciones Probar con un mínimo de cinco registros por tabla los procesos.
Especiales:
Todos los procesos serán invocados manualmente.

3.1.2Pruebas de Funcionamiento

Adicionar Cliente

Objetivo de la Táctica: Verificar que un cliente es adicionado a la base de datos.
Táctica: • Por medio del formulario de clientes ingresar en los campos los
datos solicitados y presionar el botón de Grabar registro.
• Se enviarán datos incorrectos en los campos para verificar que los
avisos de información inválida sean mostrados.
Herramientas Ninguna
necesarias:
Criterio de éxito: Se revisará la tabla de clientes de la base de datos y se verificará que el
registro diligenciado en el formulario haya sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe haber sido adicionado
a la tabla de clientes.
Consideraciones Ninguna
Especiales:



Buscar Cliente

Objetivo de la Táctica: Verificar que el registro de un cliente es encontrado por el motor de
búsqueda de MS Access.
Táctica: • Por medio del formulario de clientes se ubicará sobre el campo de
texto que se desea realizar la búsqueda, se presionará el botón “Buscar” y
se ingresará en la ventana emergente la palabra a buscar, para finalizar se
presionará el botón “Buscar siguiente”
• Se enviarán palabras que no concuerdan con el tipo de dato del
campo elegido y palabras que no existan dentro de la base con el fin de
verificar que los avisos de información correctos sean mostrados.
necesarias:
Criterio de éxito: En el formulario de Clientes, se debe cargar la información del registro
completo encontrado.
Al presionar nuevamente el botón “Buscar siguiente” se cargará en el
formulario con la información del siguiente registro coincidente en caso de
que exista, por ejemplo: Búsqueda “Pedro” >> Buscar siguiente >>Pedro
Pérez >> Buscar siguiente >> Pedro Puentes.
En caso de enviar datos inválidos el motor de búsqueda no cargará ningún
registro en el formulario de Clientes.
Especiales:

Editar Cliente

Objetivo de la Táctica: Verificar que la edición de un registro de cliente es almacenado
correctamente.
Táctica: • Una vez se ubique el registro a editar por medio de la función
“Buscar Cliente” descrita anteriormente. Se escribirá la información en el
campo que se requiera modificar, posteriormente se presionará el botón
“Grabar”.
• Se ingresarán datos inválidos para el tipo de datos y se intentará
ingresar un campo ya existente en otro registro que sea irrepetible (llave
primaria); por ejemplo el número de cédula, para verificar los que los avisos
de información correctos sean mostrados.
necesarias:
registro editado tenga el cambio solicitado reflejado.
En caso de enviar datos inválidos el registro no debe haber sido modificado
en la tabla de clientes y el sistema debe haber mostrado el aviso emergente
explicando al usuario el problema.



Consideraciones Para la prueba de llave primaria, se requiere que en la base de datos exista
Especiales: un registro con el dato que se pretende repetir.

Eliminar Cliente

Objetivo de la Táctica: Verificar que la eliminación de un registro de cliente es eliminado de la
base de datos.
Táctica: • Una vez se ubique el registro a eliminar por medio de la función
“Buscar Cliente” descrita anteriormente. Se presionará el botón “Eliminar”.
necesarias:
registro haya sido eliminado de la base de datos.
Consideraciones Ninguna.
Especiales:

Adicionar Referencia

Objetivo de la Táctica: Verificar que una referencia es adicionada a la base de datos.
Táctica: • Por medio del formulario de Referencias ingresar en los campos
los datos solicitados y presionar el botón de Grabar registro.
necesarias:
Criterio de éxito: Se revisará la tabla de inventario de la base de datos y se verificará que el
registro diligenciado en el formulario haya sido adicionado correctamente.
a la tabla de inventario.
Especiales:

Buscar Referencia



Objetivo de la Táctica: Verificar que el registro de una referencia es encontrado por el motor de
Táctica: • Por medio del formulario de referencias se ubicará sobre el campo
de texto que se desea realizar la búsqueda, se presionará el botón “Buscar”
y se ingresará en la ventana emergente la palabra a buscar, para finalizar se
necesarias:
Criterio de éxito: En el formulario de Referencias, se debe cargar la información del registro
que exista, por ejemplo: Búsqueda de “Arandela” >> Buscar siguiente
>>Arandela de Planetario >> Buscar siguiente >> Arandela del Bajo.
registro en el formulario de Inventario.
Especiales:

Editar Referencia

Objetivo de la Táctica: Verificar que la edición de un registro de una referencia es almacenado
correctamente.
“Buscar Referencia” descrita anteriormente. Se escribirá la información en
el campo que se requiera modificar, posteriormente se presionará el botón
“Grabar”.
• Se ingresarán datos inválidos para el tipo de datos y se intentará
ingresar un campo ya existente en otro registro que sea irrepetible (llave
primaria); por ejemplo el número de referencia, para verificar los que los
avisos de información correctos sean mostrados.
necesarias:
En caso de enviar datos inválidos el registro no debe haber sido modificado
en la tabla de inventario y el sistema debe haber mostrado el aviso
emergente explicando al usuario el problema.
Consideraciones Para la prueba de llave primaria, se requiere que en la base de datos exista
Especiales: un registro con el dato que se pretende repetir.



Eliminar Referencia

Objetivo de la Táctica: Verificar que la eliminación de un registro de una referencia es eliminado
de la base de datos.
“Buscar Referencia” descrita anteriormente. Se presionará el botón
“Eliminar”.
necesarias:
Especiales:

Adicionar Factura

Objetivo de la Táctica: Verificar que una factura es adicionada a la base de datos.
Táctica: • Por medio del formulario de Factura ingresar en los campos los
datos solicitados y presionar el botón de Grabar registro.
necesarias:
Criterio de éxito: Al momento de diligenciar la factura, cuando se seleccione el nombre del
cliente, el sistema debe cargar automáticamente los datos necesarios para la
factura (Dirección, Teléfono, Ciudad, etc.).
Cuando se seleccione cada uno de los productos que requiere la factura. El
sistema debe cargar automáticamente los datos adicionales de ese producto:
(identificación, descripción, precio base, etc).
El sistema debe calcular los totales de la factura.
Se revisará la tabla de factura de la base de datos y se verificará que el
registro diligenciado en el formulario haya sido adicionado correctamente
incluyendo los campos calculados de manera automática
a la tabla de inventario.
Se verificará que en la tabla de inventario, se haya descontado la cantidad de
cada referencia ingresada a la factura.
Especiales:

Buscar Factura



Objetivo de la Táctica: Verificar que el registro de una factura es encontrado por el motor de
Táctica: • Por medio del formulario de facturas se ubicará sobre el campo de
texto que se desea realizar la búsqueda, se presionará el botón “Buscar” y
se ingresará en la ventana emergente la palabra a buscar, para finalizar se
necesarias:
Criterio de éxito: En el formulario de Facturas, se debe cargar la información del registro
que exista, por ejemplo: Búsqueda de “Pedro” >> Buscar siguiente
>>Factura Pedro Pérez 001 >> Buscar siguiente >> Factura Pedro Pérez
002. >> Factura Pedro Puentes 001, etc.
registro en el formulario de Inventario.
Especiales:

Editar Factura

Objetivo de la Táctica: Verificar que la edición de un registro de una factura es almacenado
correctamente.
“Buscar Factura” descrita anteriormente. Se escribirá la información en el
campo que se requiera modificar, posteriormente se presionará el botón
“Grabar”.
• Se ingresarán datos inválidos para el tipo de datos con el fin de
verificar los que los avisos de información correctos sean mostrados.
necesarias:



Criterio de éxito: El sistema antes de guardar el registro, debe mostrar un aviso indicando que
esta modificación puede alterar incorrectamente las cantidades de productos
del inventario.
Se revisará la tabla de inventario de la base de datos y se verificará que el
Se revisará la tabla de inventario para verificar que en caso de que se haya
modificado una cantidad en la factura, se esté actualizando correctamente en
el inventario.
En caso de enviar datos inválidos el registro no debe haber sido editado en
la tabla de factura y el sistema debe haber mostrado el aviso emergente
explicando al usuario el problema.
Especiales:

Eliminar Factura

Objetivo de la Táctica: Verificar que la eliminación de un registro de una factura es eliminado de la
base de datos.
“Buscar Factura” descrita anteriormente. Se presionará el botón “Eliminar”.
necesarias:
Criterio de éxito: El sistema antes de eliminar el registro, debe mostrar un aviso indicando
que esta eliminación alterará las cantidades de productos del inventario.
Se revisará la tabla de inventario para verificar que en caso de que se haya
eliminado una factura, se estén actualizando correctamente las cantidades en
el inventario.
Se revisará la tabla de factura de la base de datos y se verificará que el
Especiales:



Exportar datos de Factura a MS Excel (opcional)

Objetivo de la Táctica: Verificar que la exportación de los datos de una factura a MS Excel se
realice correctamente.
Táctica: • Una vez se ubique la factura a exportar por medio de la función
“Buscar Factura” descrita anteriormente. Se presionará el botón “Exportar”,
en la ventana emergente, se selecciona la ubicación del archivo y se le
coloca un nombre, por último presiona el botón “Guardar”.
necesarias:
Criterio de éxito: Se revisará en la ubicación elegida para guardar, que el archivo de MS
Excel se haya generado, y se verificará que los datos de la factura hayan
sido creados dentro del archivo.
Los datos deben ser cargados en el orden y las celdas correctas en el archivo
de Excel para su posterior impresión.
Especiales:

Generar Reportes

Objetivo de la Táctica: Verificar que la eliminación de un registro de una factura es eliminado de la
base de datos.
Táctica: • Se presiona en el menú el botón “Reportes”, posteriormente se
presiona el botón con el nombre del reporte específico; por ejemplo:
“Productos en Stock”.
necesarias:
Criterio de éxito: El reporte seleccionado se debe visualizar con los datos solicitados
calculados correctamente.
Se verificará manualmente, que los datos calculados en el reporte sean
correctos.
Especiales:



3.1.3Pruebas de la Interfaz de usuario

Objetivo de la Táctica: Realizar una verificación sobre la interfaz gráfica del sistema, que asegure:
la facilidad de manejo, la intuición sobre los elementos , sencillez y tiempos
de respuesta entre ventanas.
Táctica: Se iniciará la verificación de la interfaz gráfica a través de una navegación
completa por las diferentes secciones y funcionalidades que componen el
sistema. Revisando que todos los elementos se encuentren en el lugar
indicado.
Se le pedirá a una persona que no haya tenido contacto con el sistema que
navegue, esto con el fin de poner a prueba la intuición, los tiempos de
respuesta y recibir los comentarios y críticas constructivas.
Herramientas Navegador Web: Internet Explorer (preferiblemente), mozilla, opera, etc.
necesarias:
Criterio de éxito: La aceptación por parte del usuario del diseño y los tiempos de respuesta
cortos y efectivos entre ventanas.
Consideraciones Realizar la prueba en 3 computadores con diferentes características de
Especiales: hardware.

3.1.4Prueba del Control de Seguridad y el Acceso

Objetivo de la Táctica: Revisar que el sistema de seguridad de la aplicación ofrezca un nivel
confiable para la empresa.
Táctica: Se digitará la clave de acceso a la aplicación y se revisará su desempeño.
Se tratará de ingresar por medio de datos inválidos.
necesarias:
Criterio de éxito: El sistema no debe permitir por ningún motivo el ingreso al interior a través
de contraseñas incorrectas ni por medio de trucos que violen la seguridad
del aplicativo.
Especiales:



3.1.5Prueba de Falla y Recuperación

Objetivo de la Táctica: Verificar el correcto funcionamiento del software y sus datos después de un
corte de energia mientras se utilizaba el sistema.
Táctica: Mientras se encuentra el sistema en funcionamiento se suspenderá la
corriente eléctrica, con el fin de verificar que los datos y el sistema en
general no sufra daños al momento de la recuperación.
necesarias:
Criterio de éxito: Los datos y el sistema en general deben operar de manera normal una vez se
recupere del corte de energía.
Especiales:

3.1.6Prueba de la Configuración

Objetivo de la Táctica: Probar el sistema en computadores con diferentes tipos de configuración de
hardware para detrminar su desempeño y funcionamiento.
Táctica: Se ejecutará el sistema en tres equipos diferentes, posteriormente se probará
su rendimiento en condiciones mínimas de hardware.
Herramientas Ninguna.
necesarias:
Criterio de éxito: Se espera obtener un desempeño no tan variable entre máquinas,
especialmente un buen comportamiento en el computador con unos recursos
de hardware por debajo de los que tendrá la máquina donde residirá el
sistema.
Consideraciones Los equipos donde se realizará la prueba tendrán grandes diferencias de
Especiales: recursos.

4.Criterio de Entrada y Salida
4.1Plan de Prueba

4.1.1Plan de Prueba para el Criterio de Entrada
Una vez desarrollado cada uno de los módulos del aplicativo se comenzará a realizar el set de pruebas.

4.1.2Plan de Prueba para el Criterio de Salida
El sistema será sometido a tres ciclos de pruebas: I). Pruebas a cada módulo, II). Pruebas luego de la
integración entre módulos y III). Pruebas después de corregidas las fallas del segundo ciclo, este último con el
fin de asegurar que la correción de errores no haya generado unos nuevos.



5.Producibles
5.1Resumen de la evaluación de las pruebas
Se generará un resumen luego de finalizar cada ciclo de pruebas.

5.2Registro de Incidentes y Requerimientos de Cambio
Luego de cada ciclo de pruebas, se documentará cualquier tipo de cambio que sea necesario realizar para
asegurar la funcionalidad solicitada por el cliente.

6.Necesidades Ambientales
6.1Elementos base del Software en el ambiente de la Prueba
Los elementos base siguientes del software se requieren en el ambiente de la prueba para este plan de prueba.

Nombre del elemento del Software Version Tipo y Otras Notas
Microsoft Windows XP Professional ServicePack 2 Sistema Operativo
Internet Explorer 5.0 ó superior Internet Browser
MS Excel 2000 y 2003 Hojas de Cálculo
MS Access 2000 y 2003 Bases de Datos

7.Responsabilidades, roles y necesidades de entrenamiento
7.1Personas y roles

Recursos Humanos
Rol Recursos Mínimos Responsabilidades o comentarios
Recomendados específicos

(number of full-time roles allocated)

Gerente de Pruebas - Jorge Robalino M. • Planeación de la logística
• Evaluar la efectividad de las pruebas
Persona que hace las - Francy Martinez • Implementar y realizar las pruebass
pruebas
• Documentar los incidentes
Administrador de la base -Edgar Jaramillo, Ing. Ensures test data (database) environment and
de datos, Gerente de la assets are managed and maintained.
base de datos
Responsibilities include:
• Soporte y administración de los datos de
prueba.



8.Riesgos, Dependencias, asunciones y restricciones

Contingencia (Riesgos
Riesgos Estrategias de Mitigación observados)
El criterio de entrada Se verificará que el software tenga • Conocer al detalle los
de requisito previo no desarrollada la funcionalidad a probar. prerrequisitos.
se reúne.
Los datos de la Se procederá a cargar unos nuevos datos de • Redefinir los datos de prueba.
prueba demuestran prueba.
ser inadecuados.
La base de datos La base de datos estará en monitoreo y • Restaurar datos y cargar
requiere actualización actualizaciones constantes. nuevamente el sistema.
• Limpiar la base de datos.

9.Proceso de Gerenciamiento y Procedimientos
9.1Aprobación y firmas
Cada ciclo del plan de pruebas debe ser aprobado por tres personas:
 Carlos Alberto Valencia – Administrador MEGAMAXI
 Jorge Robalino – Gerente de Pruebas
 Francy Martinez – Ejecutora de las pruebas.


Plan de pruebas

Más contenido relacionado

La actualidad más candente (20)

Similar a Plan de pruebas (20)

Plan de pruebas