You are on page 1of 20

MASTER TEST PLAN

REINGENIERIA EN EL SISTEMA DE VENTAS


DE HARINAS PANIFICABLES DE LA
EMPRESA MOLINOS MODERNOS

MTP/MM-001
PREFACIO

Este documento describe el plan de pruebas del sistema de


ventas en la empresa Molinos Modernos, cuyo objetivo
principal es documentar y diagramar los procesos aplicados en
dicho sistema,

Alcance Este documento de plan de pruebas describe la planeación de


todas las pruebas que se ejecutaran en el sistema.

REVISIONES DEL DOCUMENTO

Fecha Versión Comentarios Autor


20/10/2017 0.1 Versión inicial Test Manager
29/10/2017 1.0 Revisada por el equipo Test Manager

1
1 Identificador del plan de pruebas
Referencia Descripción
MTP/MM-001 Master Test Planning de Molinos Modernos versión

2
2 Tabla de Contenidos

1. Identificador del plan de prueba……………………………………………2


2. Tabla de contenido…………………………………………………………..3
3. Referencias…………………………………………………………………..4
4. Glosario……………………………………………………………………….5
5. Introducción…………………………………………………………………..6
6. Análisis de riesgo…………………………………………………………….7
7. Características a ser probadas……………………………………………..8
8. Características a no ser probadas………………………………………….9
9. Criterios de Aceptación / Denegación del ítem…………………………..10
10. Entregables……………………………………………………………..11-14
11. Responsabilidades…………………………………………………………15
12. Niveles de Prueba……………………………………………………..16-18
13. Aprobaciones………………………………………………………………19

3
3 Referencias

3.1 Bibliográficas

Systematic Software Testing


by Rick D. Craig and Stefan P. Jaskiel

IEEE Std. 829-1998


Standard for Software Test Documentation
Template for Test Planning

4
4 Glosario

Buddy – Testing: Consiste en que un desarrollador A emita la fase de


pruebas a un desarrollador B.

Sistema Piloto: Consiste en implementar el sistema a uno o varios


usuarios considerados como expertos, para que
efectúen pruebas en base a su trabajo real

Tester: Encargado de ejecutar las pruebas.

QA: Quality Assurance (Control de Calidad)

Testing: Proceso de emisión de pruebas

Pruebas de Consiste en efectuar pruebas desde un punto de vista


Caja Negra: entradas/ salidas en las cuales no se toma en cuenta
el proceso que se realiza internamente.

Pruebas de Consiste en evaluar los procedimientos internos y


Caja Blanca: externos de un sistema

Betha Testing: Una versión de prueba lanzada al público.

5
5 Introducción

5.1 Propósito
La presente documentación brinda soporte al proceso de ventas en la
compañía Molinos Modernos.
Se trata de cubrir todos los casos posibles que pudieran ocurrir en la
ejecución del sistema en el ambiente de producción, con la finalidad de mitigar los
errores en el sistema.

5.2 Objetivos del Plan


• Considerar los escenarios posibles con el fin de mitigar el riesgo que pueda
haber en la ejecución del sistema.
• Definir y detallar todas las tareas que se desarrollarán para probar el
sistema.
• Definir el plan y la persona o grupo responsable de cada tarea.
• Definir las herramientas de prueba y el ambiente necesario a la conducción
de las actividades de test.
• Definir los ítems y funcionalidades que serán probados.

5.3 Alcance de las Pruebas


El Plan de Pruebas del Sistema es una especificación de alto nivel de los
requerimientos funcionales y de calidad que serán probados, del ambiente de
testing, de la estrategia de testing, de las responsabilidades y de los criterios de
éxito.
El comportamiento de un producto bajo testing será comparado con las
especificaciones de los requerimientos que fueron usados para implementar el
sistema, incluyendo todos los cambios que han sido aprobados e implementados.
El alcance del test del sistema es probar la funcionalidad y el rendimiento
del sistema de venta de harinas panificables de la empresa Molinos Modernos.

5.4 Criterios de Entrada


Para poder comenzar la fase de pruebas del sistema, se deben cumplir los
siguientes criterios:
• Test unitarios realizados y completados para cada componente del
sistema.
• Sistema completamente integrado.

6
6 Análisis de Riesgo

Se forma un equipo conformado por clientes, usuarios, vendedores,


desarrolladores, testers, analistas y jefe de proyectos, con el fin de identificar
principales características del sistema y establecer una prioridad de prueba a cada
característica.

Sistema de Ventas Probabilidad


Impacto Prioridad
Características Atributos de Fallo
Cargar Inicialmente productos Baja Alto 4
Cargar libros de ruta/clientes Baja Alto 4
Tomar pedido Baja Alto 4
Planificar entrega Baja Media 3
Despachar y facturar producto Baja Alto 4
Pesar producto Baja Baja 2
Entregar producto Baja Alto 4
Pagar producto al contado Baja Alto 4
Pagar producto al crédito Alto Alto 6
Usabilidad Baja Medio 3
Seguridad Media Alto 5
Desempeño Baja Alto 4

Escala Puntos
Bajo 1
Medio 2
Alto 3

Se determina prioridad de evaluación en base a la escala anteriormente


descrita.

7
7 Características a ser probadas

Teniendo en cuenta todas las características y su prioridad de prueba, se


determinan las características que serán puestas a prueba, o las características
que llevaran a cabo pruebas más minuciosas.
Se establece una línea de corte que divide las características que se
probaran más tiempo, de las que no se probaran o se probaran menos tiempo.

Sistema de Ventas Probabilidad


Impacto Prioridad
Características Atributos de Fallo
Pagar producto al crédito Alto Alto 6
Seguridad Media Alto 5
Cargar Inicialmente productos Baja Alto 4
Cargar libros de ruta/clientes Baja Alto 4
Tomar pedido Baja Alto 4
Despachar y facturar producto Baja Alto 4
Entregar producto Baja Alto 4
Pagar producto al contado Baja Alto 4
Desempeño Baja Alto 4
Planificar entrega Baja Media 3
Usabilidad Baja Medio 3
Pesar producto Baja Baja 2

8
8 Características a no ser probadas

Se define qué características se probaran menos, o no se probaran.


Es imposible probar todo por lo que se define un muestreo para ejecutar las
pruebas, tomando una combinación considerable al tiempo que se poseerá para
ejecutar las pruebas.

Sistema de Ventas Probabilidad


Impacto Prioridad
Características Atributos de Fallo
Pagar producto al crédito Alto Alto 6
Seguridad Media Alto 5
Cargar Inicialmente productos Baja Alto 4
Cargar libros de ruta/clientes Baja Alto 4
Tomar pedido Baja Alto 4
Despachar y facturar producto Baja Alto 4
Entregar producto Baja Alto 4
Pagar producto al contado Baja Alto 4
Desempeño Baja Alto 4
Planificar entrega Baja Media 3
Usabilidad Baja Medio 3
Pesar producto Baja Baja 2

9
9 Criterios de aceptación/ denegación del ítem
Fungen como criterio de aceptación aquellos resultados obtenidos en la
ejecución de cada caso de prueba, los cuales se consideran como acciones
esperadas, en función de los requerimientos del cliente.

Caso de Prueba Criterio de Aceptación


Se sincronizan en el sistema AGM todos los productos que
Cargar inicialmente productos fueron ingresados en el sistema SAP
Se sincronizan en el sistema AGM los clientes y rutas que
Cargar libros de ruta/clientes debe seguir el vendedor
Se sincronizan al sistema SAP los pedidos que fueron
Tomar pedido ingresados en el sistema AGM
En el sistema se asigna la ruta que el transportista deberá
Planificar entrega seguir
Se emite la factura y la orden de despacho para el
Despachar y facturar producto transportista
Pesar producto El peso corresponde a la orden de envío de los productos
Entregar producto El cliente obtiene el pedido según su orden
Se cancela en efectivo/cheque la totalidad del producto contra
Pagar producto al contado entrega
El sistema determina el plazo del crédito según su
Pagar producto al crédito segmentación

10
10 Entregables

10.1 Casos de Prueba


Los casos de prueba permiten a los testers ejecutar en un ambiente de
producción, pasos que los llevarían a simular el ingreso de información en la
vida real.
Se emiten con el fin de probar la funcionalidad del sistema de acuerdo a los
requerimientos especificados por el cliente.

Sincronización de Productos
Paso Descripción Resultado Esperado

Autenticarse en el sistema SAP como analista


1 de ventas
Ingresar a la ruta -> producto -> agregar nuevo
2 producto
3 Dar clic a agregar nuevo producto

Llenar campos: nombre: "Harina de trigo",


precio unitario: "40". Seleccionar: Categoría:
4 "Harinas"
5 Dar clic en guardar
6 Ejecutar Job de migración SAP - AGM
Ingresar al sistema AGM y autenticarse como
7 vendedor
Ingresar a la ruta -> Actualizaciones ->
8 Actualizar productos
9 Dar clic en actualizar productos

Dirigirse a la ruta: -> productos -> buscar


10 producto -> buscar por nombre

Se debe visualizar el producto "Harina de


En el cuadro de texto buscar por nombre, trigo" ingresado previamente en el sistema
11 introducir: "Harina de trigo" SAP

Sincronización de libros de ruta / clientes


Paso Descripción Resultado Esperado
Autenticarse en el sistema SAP como analista
1 de ventas

2 Dirigirse a la ruta -> personal -> vendedores

11
En el cuadro de dialogo vendedores,
3 seleccionar búsqueda por nombre
En el cuadro de texto búsqueda por nombre,
4 introducir: "Belter Aguirre"
Seleccionar el resultado de la búsqueda:
5 "Belter Aguirre"
En la plantilla vendedor, dirigirse a la pestaña
6 rutas-> agregar nueva ruta

En el cuadro de dialogo agregar nueva ruta, en


el campo cliente introducir: "Almacén la
7 Bendición" presionar la tecla tab
Seleccionar la primer dirección registrada: "3ra
calle 20-34 zona 4 de mixco, colonia Nueva
8 Montserrat"
9 Dar clic en el botón "Asignar ruta"
10 Ejecutar Job de migración SAP - AGM
Ingresar al sistema AGM y autenticarse como
11 vendedor
Dirigirse a la ruta: Actualizaciones -> Actualizar
12 rutas/clientes
13 Dar clic en actualizar rutas/clientes

Se visualiza la ruta: Cliente: "Almacén la


Bendición", Dirección: "3ra calle 20-34 zona
14 Dirigirse a la ruta: Rutas/Clientes 4 de Mixco, colonia Nueva Montserrat"

Toma de Pedido
Paso Descripción Resultado Esperado
Autenticarse en el sistema AGM como
1 vendedor

2 Dirigirse a la ruta -> Pedidos -> Agregar Pedido


En el campo cliente introducir: "Almacén la
3 Bendición" presionar tab
4 Dar clic en el botón "agregar producto"

Rellenar los siguientes campos: producto:


5 "Harina de Trigo" cantidad: "10"
6 Dar clic en el botón hacer pedido
Autenticarse en el sistema SAP como
7 planificador
Dirigirse a la ruta -> Pedidos -> Pedidos Se visualiza el pedido a favor de: "Almacén
8 pendientes de entrega la Bendición"

12
Planificación de Despacho
Paso Descripción Resultado Esperado
Autenticarse en el sistema SAP como
1 planificador
2 Dirigirse a la ruta: Transportes

Seleccionar cualquier camión con estado:


"Disponible", que cubra la ruta a zona 4 de
3 Mixco
Dirigirse a la sección: Carga -> Asignar nueva
4 carga

En el cuadro de dialogo nueva carga, presionar Se abre el cuadro de dialogo pedidos


5 el botón "Pedidos pendientes de entrega" pendientes de entrega

En el cuadro de dialogo pedidos pendientes de


6 entrega, seleccionar "Almacén la Bendición"

Se visualiza mensaje de éxito, en el cual


En el cuadro de dialogo nueva carga, presionar hace referencia al número de camión y el
7 el botón "Asignar nueva carga" número de pedido que este tiene asignado

Despacho y Facturación
Paso Descripción Resultado Esperado
Autenticarse en el sistema SAP como
1 facturador
Dirigirse a la ruta: Facturación -> Nueva
2 Factura
En el cuadro de dialogo Nueva Factura, en el
campo pedido, ingresar el número de pedido:
"5024" (El cual corresponde al pedido de
3 Almacén la Bendición)

El sistema genera e imprime la factura


4 Presionar el botón generar factura correspondiente

Pesaje
Paso Descripción Resultado Esperado
Autenticarse en el sistema SAP como
1 basculista

13
Dirigirse a la ruta: Notas -> Nota de salida ->
2 nueva nota de salida

En el cuadro de dialogo nueva nota de salida,


ingresar: transportista: "Edgar Paredes",
3 camión: "14", factura: "502"
El sistema genera e imprime la nota de
4 Presionar el botón generar nota de salida salida correspondiente

14
11 Responsabilidades

Esta sección establece las responsabilidades de cada grupo que participa


en la fase de pruebas.

11.1 Responsabilidades del Grupo de Desarrollo


• Ejecutar las pruebas unitarias
• Ejecutar y probar la integración de bajo nivel
• Corregir los problemas reportados

11.2 Responsabilidades del Grupo deTesting


• Planificar las pruebas del sistema
• Configurar el ambiente de prueba
• Ejecutar las pruebas del sistema
• Escribir el reporte de test

11.3 Responsabilidades de la Gerencia


• Proveer recursos
• Aceptación final y aprobación de la liberación del producto

15
12 Niveles de Prueba
12.1 Pruebas Unitarias
Las pruebas unitarias constituyen una parte esencial en el ciclo de vida de
pruebas, ya que se realizan a bajo nivel, y permiten evaluar la ejecución de
módulos individuales (clases, formularios).
12.1.1 Estrategia
Las pruebas unitarias serán llevadas a cabo por los desarrolladores, un
desarrollador A emite pruebas unitarias a un módulo desarrollado por un
desarrollador B, a este tipo de pruebas se le llama “Buddy Testing”.
Las pruebas unitarias se ejecutaran bajo el método de Caja Blanca,
verificando el procedimiento que se realiza para analizar entradas y salidas.
12.1.2 Análisis de Audiencia
Los participantes en las pruebas unitarias serán únicamente los
desarrolladores, ya que pueden sugerirse y orientar el desarrollo de acuerdo
a la especificación de los requerimientos
12.1.3 Gestión de la configuración
Debido a que los desarrolladores ejecutaran las pruebas unitarias, el ambiente
de desarrollo será el entorno de pruebas, por lo que la información cargada
debe ser lo más real posible, o ser extraída del ambiente de producción.
Los requisitos de hardware no son tan demandantes debido a que no se busca
verificar el desempeño del sistema, sino la funcionalidad de cada módulo.

12.2 Pruebas de Integración


Las pruebas de integración permiten a los desarrolladores poseer un mapa
sobre cómo ir integrando modulo por modulo, con el fin de evaluar la
interacción entre un módulo y otro.
Se evalúa la comunicación entre clases.
12.2.1 Análisis de Audiencia
Debido a que provee un mapa sobre como integrar, los desarrolladores
testers serán los encargados de verificar la comunicación entre los diversos
módulos que conformaran el sistema.
12.2.2 Gestión de la configuración
A pequeños rasgos no se requiere un hardware con alta demanda, ya que
solo se desea evaluar la comunicación entre módulos.
Tampoco es necesario obtener data real del ambiente de producción.
Pero a manera de que las pruebas sigan avanzando, la configuración se torna
cada vez más formal.

16
12.3 Pruebas de Sistema
Las pruebas de sistema evalúan la funcionalidad del sistema completo
conforme a los requisitos del cliente.
Son emitidas por el encargado de control de calidad, quien evalúa la
funcionalidad tratando al sistema como una caja blanca, de la cual se
desconoce los procedimientos ejecutados internamente, y únicamente se
evalúan entradas y salidas.
12.3.1 Análisis de Audiencia
Según lo anteriormente citado, es el encargado de control de calidad quien
realizara las pruebas de sistema.
En el proceso el desarrollador ofrece soporte al encargado de control de
calidad con el fin de especificar el funcionamiento del sistema.
12.3.2 Fuentes de Información
Para las pruebas de sistema se considera una fuente de información real,
debido a que se necesita evaluar el sistema conforme a acciones que
pudieran ejecutarse en la realidad.
Para emular el ambiente real, se extraen back-ups generados en el ambiente
de producción. De esta forma se asegurara de que se cuenta con información
real y verídica.
12.3.3 Gestión de la Configuración
Las bases de datos deben ser extraídas del ambiente de producción.
Ya que también se requiere evaluar el desempeño del sistema, las
características del hardware deben ser las más mínimas que se poseen en el
ambiente de producción. De esta forma se asegurara de que el sistema puede
desempeñarse de buena manera hasta en los requisitos mínimos para
ejecutarlo.

12.4 Pruebas de Aceptación


Las pruebas de aceptación registran la conformidad o la no conformidad de
los clientes/usuarios ante el sistema desarrollado
Se derivan de las pruebas de sistema, que a diferencia de las anteriores, estas
son emitidas por el usuario final, algunas veces acompañado del tester/ y o
desarrollador
12.4.1 Análisis de Audiencia
En las pruebas de aceptación participa principalmente el usuario final,
acompañado de un tester y/o desarrollador
12.4.2 Fuentes de Información
Ya que son los usuarios finales los encargados de realizar las pruebas de
aceptación, la información debe ser real. Por lo cual que al igual que las

17
pruebas de sistema, la información es extraída a través de back-ups
generados en el ambiente de producción.
12.4.3 Betha Testing
Se considera implementar una versión de prueba, ya que si los usuarios
finales detectan un error en su ejecución, este puede ser informado al
departamento de desarrollo, sin afectar su trabajo real.
12.4.4 Implementación
Se considera utilizar la estrategia de implementación “piloto”, la cual consiste
en implementar el sistema a una o un grupo de personas, para que a
diferencia del betha testing, se interactúe con información y trabajo real.
Esta estrategia de implementación permite implementar por fases el sistema
a todos los usuarios.

18
13 Aprobaciones

______________________ ______________________
Gerente de Ventas Jefe de Proyectos

______________________ ______________________
Test Manager Control de Calidad

19

You might also like