1.

Ejemplo de Ficha Técnica para un Escenario

ID escenario 2.0
Empresa Metrocali
Producto Software para gestión de Sistema de transporte masivo MIO
Versión 1,2
Fecha 22 - Mayo- 2013
Tipo de aplicación Escritorio

Personal 1 ingeniero de pruebas

Maquina Cliente
Software
Características Software Versión
Windows 7
Sistema Operativo Fedora 17
Base de datos PostgreSQL 9,2
JRE Standard 7
Para conectarse a la base de datos se debe tener en cuenta que es necesario
agregar una nueva conexión al server 23.23.149.33 con nombre, password y
Observación nombre de usuario jhonmgb, puerto 5432
Hardware
Características Hardware Capacidad
Procesador Core i3 3.0Ghz
Disco duro 5,4K RPM, SATA 100GB
Memoria RAM Ddr2 1GB
1024x768
Resolución Monitor 1366x768
Conexión a internet 2 MB de velocidad
Teclado
Mouse
Datos

* Auxiliar del servicio al cliente registrado y activo ( tiene que poseer una clave para poder acceder al sistema)
* Tarjeta registrada en el sistema la cual se encuentre en estado activo

* Debe existir un usuario del sistema de transporte masivo registrado que tenga asociada una tarjeta
* Deben existir estaciones registradas en el sistema, las cuales se encuentren activas para poder ser desplegadas
en el menú de cargar tarjeta
Observaciones

Dado que para realizar las pruebas no se cuenta con un lector de tarjetas, se debe tener en cuenta que para cargar
la tarjeta, el auxiliar del servicio al cliente debe ingresar manualmente el PIN que trae impreso la tarjeta

Título

Responsable

Revisado por Fecha Revisión

Fecha
Aprobado por
Aprobación
 Versión Fecha Versión

Participantes en Elaboración:

Elaboradores Unidad Organizativa

Desarrollador

Registro de Cambios

Fecha
Versión Causa del Cambio Responsable del Cambio
Cambio

Plan de Pruebas del Sistema de reprocesos GMO

Versión: 2.0 Página 2 de 12
 INDICE

1. FASE DE DISEÑO FUNCIONAL DEL SISTEMA ....................................................................................... 4

1.1 DEFINICIÓN DE ESTRATEGIA DE PRUEBAS .................................................................................... 5
1.2 ESCENARIOS Y ENTORNOS DE PRUEBAS ....................................................................................... 5
1.3 6
1.4 CATÁLOGO DE CASOS DE PRUEBAS DE ACEPTACIÓN .................................................................. 6
2. FASE DE DISEÑO TÉCNICO DEL SISTEMA ............................................................................................ 9
2.1 CATÁLOGO DE TAREAS DE PRUEBAS FUNCIONALES ................................................................... 9
2.2 CATÁLOGO DE TAREAS DE PRUEBAS DE RENDIMIENTO ...........................................................12

Plan de Pruebas del Sistema de reprocesos GMO

Versión: 2.0 Página 3 de 12
2. FASE DE DISEÑO FUNCIONAL DEL SISTEMA

Según el Ing. Alexander Oré B:

Al desarrollar un nuevo software o sistema de información, la primera etapa de pruebas a considerar es la

etapa de pruebas unitarias o también llamada pruebas de caja blanca (White Box), estás pruebas también
son llamadas pruebas modulares ya que nos permiten determinar si un módulo del programa está listo y
correctamente terminado, estas pruebas no se deben confundir con las pruebas informales que realiza el
programador mientras está desarrollando el módulo.

El principal factor que se debe considerar al inicio de las pruebas es el tamaño del módulo a probar, se
debe considerar si el tamaño del módulo permitirá probar adecuadamente toda su funcionalidad de manera
sencilla y rápida. También es importante separar los módulos de acuerdo a su funcionalidad, si los
módulos son muy grandes y contienen muchas funcionalidades, estos se volverán más complejos de
probar y al encontrar algún error será más difícil ubicar la funcionalidad defectuosa y corregirla. Al hacer
esta labor el analista de pruebas podrá recomendar que un modulo muy complejo sea separado en 2 o 3
módulos más sencillos.

Este tipo de pruebas debe ser realizado por personal especializado en Software testing, el cual debe estar
familiarizado en el uso de herramientas de depuración y pruebas, así mismo deben conocer el lenguaje de
programación en el que se está desarrollando la aplicación, en la actualidad existen una gran cantidad de
herramientas que apoyan la labor del analista de pruebas, inclusive se pueden conseguir herramientas para
cada tipo de lenguaje, estas herramientas pueden facilitar el desarrollo de pruebas, elaboración de casos
de pruebas, seguimiento de errores, etc. Algunas de las herramientas que se utilizan para pruebas unitarias
son: JUnit, La Suite de Mercury, CPPUnit etc.

El objetivo fundamental de las pruebas unitarias es asegurar el correcto funcionamiento de las interfaces, o
flujo de datos entre componentes. [24]

Plan de Pruebas del Sistema de reprocesos GMO

Versión: 2.0 Página 4 de 12
 2.1 DEFINICIÓN DE ESTRATEGIA DE PRUEBAS

Para realizar pruebas efectivas un equipo de software debe efectuar revisiones técnicas formales y efectivas.
1. La prueba comienza al nivel de componentes y trabaja hacia fuera, hacia la integración de los
componentes
2. Diferentes técnicas de prueba son apropiadas en diferentes momentos
3. La prueba la dirige el desarrollador del software y un grupo independiente de pruebas
4. La prueba y la depuración son actividades diferentes, pero la segunda se debe incluir en la estrategia de
pruebas
5. La estrategia debe incluir pruebas de bajo nivel y de alto nivel

2.2 ESCENARIOS Y ENTORNOS DE PRUEBAS

NÚM. CONTEXTO DE LAS PRUEBAS PRIORIDAD

Se necesita que los equipos donde se realizan las pruebas tengan conexión a
internet, también que estén dentro del dominio del sistema de información de
1 ALTA
GMO, y que se tengan todas las contraseñas de ingreso al sistema, (todos los
perfiles de usuario posibles)

MODOS DE ACCESO A LA APLICACIÓN Y ESCENARIOS DE USO

NÚM. PRIORIDAD
QUE DEBEN SER PROBADOS
1 Debe tener perfil de acceso de administrador ALTA

Plan de Pruebas del Sistema de reprocesos GMO

Versión: 2.0 Página 5 de 12
 2.3 2.4 CATÁLOGO DE CASOS DE PRUEBAS DE ACEPTACIÓN

Nº FUNCIÓN C NC ESPECIFICACIÓN DE LAS PRUEBAS

1 Ingreso al Se evalúa el ingreso del usuario a la aplicación dependiendo de los privilegios de usuario, se puede solo consultar, o también se
sistema puede modificar y adicionar datos.
X Descripción: Acceso del usuario a la aplicación.
Requisitos probados: REM [UC-0002]
Objetivo: Comprobar que sólo los usuarios autorizados tienen acceso a la aplicación.
Pruebas a realizar:
T-1. Comprobar que un usuario autorizado tiene acceso a la aplicación.
T-2. Comprobar que un usuario autorizado con un password incorrecto no accede.
T-3. Comprobar que un usuario no autorizado recibe el apropiado mensaje de no autorizado y no puede acceder.
T-4. Comprobar que un usuario inexistente no tiene acceso.

X Descripción: Consulta de Aplicación.

Requisitos probados: REM [UC-0002]
Objetivo: Comprobar la correcta recuperación de toda la información asociada a un registro del catálogo de Aplicación
Pruebas a realizar:
T-1. Seleccionando un usuario en la lista se obtienen todos sus datos.
T-2. Comprobar que están todos los datos.

X Descripción: Búsqueda de Usuarios con sus Cuentas Bloqueadas.

Requisitos probados: Prueba genérica.
Objetivo: seleccionar las cuentas de usuarios bloqueadas que vamos a desbloquear
Pruebas a realizar:
T-1. Comprobar que un registro bloqueado efectivamente se desbloquea.
T-2. Comprobar que con un registro no bloqueado la aplicación no hace nada.
T-3. Comprobar que es posible seleccionar varios registros boqueados y no bloqueados y que todos quedan desbloqueados.
Comprobar
Precondiciones: El usuario debe tener acceso a la aplicación.
Plan de Pruebas del Sistema de reprocesos GMO
Versión: 2.0 Página 7 de 12
Plan de Pruebas del Sistema de reprocesos GMO
Versión: 2.0 Página 8 de 12
3. FASE DE DISEÑO TÉCNICO DEL SISTEMA

3.1 CATÁLOGO DE TAREAS DE PRUEBAS FUNCIONALES

Nº FUNCIÓN C NC ESPECIFICACIÓN DE LAS PRUEBAS

Cargar X Prueba a realizar: Comprobar que cuando se ingresa el número del
campos de encargo se obtengan los datos del cliente y los datos de la factura
actualización Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía>solicitar garantía, ingresar número de pedido
Respuesta esperada: se actualiza los datos del cliente y los datos de
la factura en los demás campos
Precondiciones: El usuario debe tener acceso a la aplicación.

Cargar X Prueba a realizar: Comprobar que cuando se ingresa el número del

campos de encargo se pueda editar y guardar la .dirección, teléfono, email y
actualización celular del cliente
Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía>solicitar garantía, ingresar número de pedido y editar campos
Respuesta esperada: se puede modificar los datos del cliente y
guardarlos.
Precondiciones: El usuario debe tener acceso a la aplicación.

Validar X Prueba a realizar: Comprobar que cuando seleccione la descripción

garantía del problema el sistema valide que la fecha de garantía este dentro del
tiempo correcto
Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía>solicitar garantía, ingresar número de pedido, editar campos,
seleccionar descripción, oprimir botón, validar garantías
Respuesta esperada: se puede validar la fecha de la garantía, el
tiempo de la garantía.
Precondiciones: El usuario debe tener acceso a la aplicación.
Enviar datos X Prueba a realizar: Comprobar que cuando seleccione todos los ítems
en el formulario de constancia de recibo y reparación, envié los datos
con el
Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía>solicitar garantía, ingresar número de pedido, editar campos,
seleccionar descripción, oprimir botón, validar garantías, clic en enviar
datos
Respuesta esperada: mensaje de solicitud creada exitosamente, y
mostraren pantalla el número de la encomienda
Precondiciones: El usuario debe tener acceso a la aplicación.
Validar X Prueba a realizar: Comprobar que cuando seleccione las garantías
solicitudes pendientes el sistema muestre todas las garantías.
pendientes Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía>pendientes.
Respuesta esperada: se puede observar todas las garantías que se
encontrar pendientes por valorar

Validar X Prueba a realizar: Comprobar que cuando seleccione una de las

solicitud garantías pendientes el sistema muestre toda la información en otro
 de garantía formulario
Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía>pendientes; ingresar en cualquiera de las garantías
pendientes.
Respuesta esperada: se puede observar la garantía seleccionada con
toda la información
Precondiciones: El usuario debe tener acceso a la aplicación.
Aprobar, X Prueba a realizar: Comprobar que cuando seleccione el formulario
negar, pre- de una solicitud de garantía, al darle el botón Aprobar, negar o pre-
aprobar aprobar no deje avanzar si no ha llenado un text box con la
solicitud de justificación de la respuesta, y que cuando la haya llenado se envíen
garantía los datos correctamente
Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía>pendientes; ingresar en cualquiera de las garantías
pendientes> escribir justificación, enviar.
Respuesta esperada: no deja avanzar si el campo de justificar
respuesta no se ha llenado, luego de ser llenado, se envían los datos
correctamente mediante un mensaje.
Precondiciones: El usuario debe tener acceso a la aplicación.
Validar datos X Prueba a realizar: Comprobar que cuando seleccione el formulario
del cliente en de una merma, al darle el botón Nuevo Presupuesto, se carguen los
merma datos del cliente correctamente
Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía> solicitar>merma> nuevo presupuesto.
Respuesta esperada: Apenas ingresa al label del nuevo presupuesto,
el sistema carga los datos del cliente.
Precondiciones: El usuario debe tener acceso a la aplicación.
Solicitar X Prueba a realizar: Comprobar que cuando seleccione los datos de los
merma suplementos, las medidas de las monturas y los comentarios, almacene
asociada a la correctamente la solicitud de la merma.
garantía Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía> solicitar>merma
Respuesta esperada: cuando carguen los datos del cliente llenado el
campo de nuevo presupuesto y también el usuario llene con éxito los
campos de monturas, comentarios y suplementos, al oprimir el botón
“solicitar merma debe guardar los datos con éxito y salir el mensaje
“Solicitud de merma creada exitosamente”
Precondiciones: El usuario debe tener acceso a la aplicación.

Plan de Pruebas del Sistema de reprocesos GMO

Versión: 2.0 Página 10 de 12
 Mermas X Prueba a realizar: Comprobar que cuando seleccione los datos de los
pendientes suplementos, las medidas de las monturas y los comentarios, almacene
correctamente la solicitud de la merma.
Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía> solicitar>merma
Respuesta esperada: cuando carguen los datos del cliente llenado el
campo de nuevo presupuesto y también el usuario llene con éxito los
campos de monturas, comentarios y suplementos, al oprimir el botón
“solicitar merma debe guardar los datos con éxito y salir el mensaje
“Solicitud de merma creada exitosamente”
Precondiciones: El usuario debe tener acceso a la aplicación.

Indicar el X Prueba a realizar: Comprobar que cuando seleccione el formulario

responsable de mermas pendientes, al darle el botón “PAGA GMO” O “PAGA
de la merma TIENDA” no deje avanzar si no ha llenado un text box con la
justificación de la respuesta, y que cuando la haya llenado se envíen
los datos correctamente
Estimulo (acciones a realizar): Ingresar al sistema, entrar en
garantía> solicitar>merma, llenar campos> justificar respuesta>
“PAGA GMO” O “PAGA TIENDA”
Respuesta esperada: no deja avanzar si el campo de justificar
respuesta no se ha llenado, luego de ser llenado, se envían los datos
correctamente mediante un mensaje.
Precondiciones: El usuario debe tener acceso a la aplicación.
Registrar X Prueba a realizar: Comprobar que cuando seleccione el formulario
nuevo número de mermas pendientes, al consultar una merma debe cargar todos los
de encargo datos pertenecientes y al oprimir el botón “procesar ok” debe abrirse
una ventana emergente donde se pueda ingresar el número del nuevo
encargo y procesarse.
Estimulo (acciones a realizar): Ingresar al sistema, entrar en
mermas> pendientes>”seleccionar merma”> procesar OK
Respuesta esperada: Debe dejar procesar la merma solicitada y debe
mostrar un mensaje de éxito.
Precondiciones: El usuario debe tener acceso a la aplicación.

Plan de Pruebas del Sistema de reprocesos GMO

Versión: 2.0 Página 11 de 12
 3.2 CATÁLOGO DE TAREAS DE PRUEBAS DE RENDIMIENTO

N FUNCIÓN C NC ESPECIFICACIÓN DE LAS PRUEBAS

º
RENDIMIENTO X Descripción: Acceso del usuario a la aplicación.
Requisitos probados: REM [UC-0002]
Objetivo: Comprobar que el tiempo de respuesta de autentificación de
usuario es menor de 5 segundos cuando hay concurrencia de 100
usuarios.
Precondiciones: En estado inicial.
Procedimiento de prueba: Se realizan series de 50 identificaciones
mientras hay 100 usuarios ejecutando concurrentemente otras
acciones.
o
RENDIMIENTO X Prueba a realizar: Comprobar tiempo de respuesta en concurrencia
de identificación de usuarios.
Condiciones de carga: Generación de transacciones de identificación.
Estimulo (acciones a realizar): Completar campos en una transacción
paralela a la carga
Respuesta esperada: Medir tiempos…

RENDIMIENTO X Prueba a realizar: Comprobar tiempo de respuesta en concurrencia

con la operación de consulta a los datos de una aplicación.
Condiciones de carga: Generación de transacciones de consulta.
Estimulo (acciones a realizar):
Respuesta esperada:

Nota:

Al principio de las pruebas hubo muchos ítems que no cumplían, pero poco a poco se fue haciendo la
respectiva corrección al punto de cumplir todos los puntos de este formato.

Plan de Pruebas del Sistema de reprocesos GMO

Versión: 2.0 Página 12 de 12