Plan de pruebas de software

BOTICA FARMA
Fecha: [30/03/2019]

Universidad Privada del Norte – Sede Breña

Tabla de contenido

Historial de Versiones 4

Información del Proyecto 4

Aprobaciones 4

Resumen Ejecutivo 5

Alcance de las Pruebas 5

Elementos de Pruebas 5

Nuevas Funcionalidades a Probar 6

Pruebas de Regresión 6

Funcionalidades a No Probar 7

Enfoque de Pruebas (Estrategia) 7

Criterios de Aceptación o Rechazo 8

Universidad Privada del Norte – Sede Breña

Criterios de Aceptación o Rechazo 8

Criterios de Suspensión 8

Criterios de Reanudación 9

Entregables 9

Recursos 10

Requerimientos de Entornos – Hardware 10

Requerimientos de Entornos – Software 10

Herramientas de Pruebas Requeridas 11

Personal 11

Entrenamiento 12

Planificación y Organización 12

Procedimientos para las Pruebas 12

Matriz de Responsabilidades 13

Cronograma 13

Premisas 14

Dependencias y Riesgos 14

Referencias 15

Glosario 15

Universidad Privada del Norte – Sede Breña

Historial de versiones

Fecha Versió Autor Descripción

n
30/03/19 V1.0 Grupo de trabajo Se desarrollaron las vistas graficas del
software.

20/04/19 V1.1 Grupo de trabajo Se implementó el código de las interfaces

de logeo, crear usuarios, añadir,
modificar y eliminar tanto para productos
como usuarios.
04/05/19 V1.2 Grupo de trabajo Se culminó con la codificación del
software.
25/05/19 V 2.0 Grupo de trabajo Se automatizo el código de logeo y se
añadió código para la modificación de
usuarios y medicamentos.

Información del proyecto

Empresa / Organización Botica Farma

Proyecto Desarrollo de un software de ventas para la botica
farma
Fecha de preparación 05/04/2019
Cliente Juanita Perez
Patrocinador principal Juanita perez
Gerente / Líder de proyecto Johan Davila
Gerente / Líder de pruebas Victoria Campos
de software

Aprobaciones

Nombre y Cargo Departamento Fech Firma

Universidad Privada del Norte – Sede Breña

 Apellido u organización a

Resumen ejecutivo 

La “Calidad de un producto” hace referencia a que el producto salga con el más

alto porcentaje de efectividad. El propósito de este plan de pruebas es hacer un
producto con mucha calidad y esto se realiza teniendo en cuenta la calidad como
objetivo a cada momento y realizando las actividades necesarias para que esto se
logre. Este plan de pruebas es necesario para el aseguramiento de la calidad del
sistema. Con este plan se seleccionan y se coordinan las actividades para
asegurar la calidad del software durante el ciclo de vida del proyecto y aún
después al ser entregado al cliente. Los objetivos que se pretenden alcanzar con
la aplicación del plan de pruebas son las siguientes:

● Encontrar la mayor cantidad de errores como sea posible.

● Supervisar si se cumple las especificaciones de diseño establecidas por el

cliente.

● Supervisar si se cumple los requisitos del análisis que se hicieron en la

planificación del diseño y desarrollo del software.

● Realizar las pruebas necesarias de rendimiento y capacidad del sistema.

Universidad Privada del Norte – Sede Breña

● Encontrar los problemas importantes y determinar los riesgos percibidos en
cuanto a la calidad del producto. 

Alcance de las pruebas

Elementos de pruebas

Para realizar con éxito las pruebas de software dividiremos las pruebas en 3
módulos:
● Productos y usuarios
● Ventas
● Reportes

En estos módulos se realizarán pruebas para validar:

● La visualización de los datos, ingresados o modificados.
● La funcionalidad de los servicios, confeccionados para dar respuesta a los
productos del sistema de boticas Farma.
● La respuesta y realización de las transacciones de cada módulo.
● Que los estados de las actividades y documentos generados en el sistema
se reflejen de acuerdo con la secuencia lógica requerida por el usuario.
● La secuencia lógica de las funcionalidades y transacciones.

Nuevas funcionalidades a probar 

Universidad Privada del Norte – Sede Breña

Es un listado de lo que se va a probar “desde el punto de vista del usuario”. No es
una descripción técnica del software sino sus características y funcionalidades. Se
incluyen tanto las que son nuevas como las que se están modificando.

Pruebas de regresión 

Listado de las funcionalidades no directamente involucradas en el desarrollo, pero

cuyos componentes están siendo afectados y por ende deben probarse para
asegurar que continúan funcionando adecuadamente. Al igual que en el punto
anterior, se describen desde el punto de vista del usuario. 

Funcionalidades a no probar 

Universidad Privada del Norte – Sede Breña

  RF11=El sistema permite generar boleta. Debido a que la mayor parte de
los clientes no exigen un comprobante de pago.
 RNF1=El sistema opera en varias plataformas. El cliente solo lo
implementara en un ordenador. Por lo cual no se realizarán pruebas en
otras plataformas.
 RNF2=El sistema cuenta con una BD en SQL. Debido a que solo usa la BD
para listar los medicamentos y usuarios no se necesita realizar pruebas con
profundidad.
 RNF3=El sistema tiene un tiempo de respuesta de 3 segundos
aproximadamente. Para el cliente no es necesario profundizar en las
pruebas en este aspecto.

Enfoque de pruebas (estrategia)

Se requiere certificar por parte del equipo de desarrollo y por parte del usuario al
producto software Botica Farma en dos etapas, que administre y gestione las
tareas y procesos de Botica Farma. Por ende, se debe verificar:

 1ra. Etapa: Que las funcionalidades de los módulos de Proyectos y de

Revisión son operativas.

 2da. Etapa: Que las funcionalidades integradas de los módulos de

Proyectos, Revisión y Aprobación son operativas.

Conjuntamente los sub-objetivos para los tres módulos se resumen de la siguiente

forma:
 El ingreso tanto del administrador como de los vendedores.


Universidad Privada del Norte – Sede Breña

  La creación, modificación y eliminación de usuarios (administradores y
vendedores)
 La creación, modificación y eliminación de medicamentos (nombre, precio,
stock).
 La creación, modificación y eliminación de tareas (procesos de ventas).
 La creación, modificación y eliminación reportes de ventas(boletas).
 La visualización, modificación y eliminación de los reportes.

Criterios de aceptación o rechazo

Errores Graves: información crítica presentada erróneamente, información mal

registrada en la base de datos, caídas de programas, incumplimiento de objetivos
en funciones principales, etc.

Errores Medios (comunes): errores en documentos impresos(boletas) que se

entregan a personas ajenas a la organización, errores en presentación de datos,
incumplimiento de objetivos en funciones secundarias, caídas de programas
auxiliares, etc.

Errores Leves: errores en presentación de datos secundarios, no adecuación a

estándares, comportamientos correctos pero diferentes en situaciones similares,
dificultades de operación, etc.

Descripción

Universidad Privada del Norte – Sede Breña

Se aprobará el proyecto con un 100% de las pruebas ejecutadas, pero con un
90% de aceptación. Esto quiere decir el 90% de las pruebas deben ser exitosas y
sin errores. El restante 10% pueden existir errores medios o bajos, pero no graves.
En caso de ocurrir que el proyecto no cumpla con el nivel exigido, el proyecto se
rechaza completo en su etapa de implementacion.

Criterios de suspensión 

Establece claramente bajo qué condiciones se detienen un conjunto de casos de

pruebas, por ejemplo en caso de existir defectos que impidan la ejecución de más
casos de pruebas, cierto porcentaje de casos fallidos, o cualquier otro que se
especifique. 

Criterios de reanudación

Universidad Privada del Norte – Sede Breña

Luego de haber suspendido las pruebas, aquí se establece bajo qué criterios se
reanudaran. 

Entregables 

Establece que se entregará como parte de la ejecución del plan, por ejemplo:
Documento de plan de pruebas, casos de pruebas, especificación de diseño de
casos, logs de errores, reportes de incidencias, evidencias de pruebas, reportes
emitidos por herramientas de pruebas y cualquier otro que se establezca.

Universidad Privada del Norte – Sede Breña

Recursos

 Requerimientos de entornos – Hardware 

Lista de los requerimientos de equipos, hardware y red necesarios para completar

las actividades del plan de pruebas de software. Incluye servidores de aplicación,
bases de datos, equipos de PC que necesitan los Testers, conectividad a la red
(incluyendo accesos), entre otros. 

Universidad Privada del Norte – Sede Breña

Requerimientos de entornos – Software 

Lista de los requerimientos de software necesarios para completar las actividades

de prueba, puede incluir accesos a Sistemas (en entorno de pruebas) y bases de
datos, así como instalación de software en los Computadores asignados a los
Testers.

Herramientas de pruebas requeridas 

Especifica las herramientas de software, metodologías o técnicas especiales

empleadas en las pruebas, por ejemplo herramientas de automatización de
pruebas, software de gestión de pruebas, entre otros. 

Universidad Privada del Norte – Sede Breña

 Personal

Lista del personal necesario para completar las actividades de pruebas,

especificando sus roles, por ejemplo: Un (1) líder de pruebas, cinco (5) analistas
de pruebas (Testers), dos (2) especialistas en automatización de pruebas, entre
otros. 

Universidad Privada del Norte – Sede Breña

Entrenamiento

Necesidades de entrenamiento en el sistema o aplicación, así como en las

herramientas de prueba a utilizar.

Planificación y organización

Universidad Privada del Norte – Sede Breña

Procedimientos para las pruebas

Especifica los procedimientos o metodología de pruebas a emplear durante la

ejecución del plan de pruebas de software.

Matriz de responsabilidades

Lista cada una de las personas integrantes del equipo de QA y sus

responsabilidades. Se puede hacer uso de una matriz RACI (responsable,
aprobador, consultado, informado). 

Universidad Privada del Norte – Sede Breña

 
Cronograma

Debe estar basado en estimaciones de actividades realizadas por el equipo de

prueba. En él se identifican los hitos relevantes en las pruebas de software, se
establecen las dependencias (actividades predecesoras) y demás aspectos
componentes de un cronograma. 

Universidad Privada del Norte – Sede Breña

Premisas

Las premisas relacionadas con las tareas de pruebas de software, incluyendo

limitaciones de tiempo, disponibilidad de recursos que se asumen, uso de una
metodología de pruebas, uso de una herramienta, entre otros.

Dependencias y Riesgos

Aquí se listan los riesgos asociados con el proceso de pruebas de software, por
ejemplo, algunas fuentes de riesgos suelen ser:

● Dependencias con desarrollos.

Universidad Privada del Norte – Sede Breña

● Dependencias con otros proyectos.
● Disponibilidad de recursos.
● Restricciones de tiempo.
● Premisas que resulten no ser ciertas. 

Los riesgos se pueden clasificar en función de su probabilidad e impacto, cada

uno debe contemplar un plan de mitigación para evitar que ocurra o plan de
contingencia cuando el riesgo no puede mitigarse y tiene que aceptarse.

Referencias 

Lista de todos los documentos que pueden citarse como apoyo o para ampliar el
contenido del plan de pruebas. Algunos ejemplos de lo que se puede hacer
referencia aquí son: 
● Plan de proyecto.
● Especificaciones de requerimientos. 
● Diseño general.
● Diseño detallado. 
● Procedimientos y estándares de desarrollo. 
● Procedimientos y estándares de pruebas. 
● Metodologías, procedimientos y estándares corporativos.

Universidad Privada del Norte – Sede Breña

Glosario

Definiciones de términos usados en la documentación, y general sobre el área de

pruebas.

Universidad Privada del Norte – Sede Breña