Está en la página 1de 26

MasterBikes

Plan de Pruebas
Versión final

Integrantes:
Andres Aldama
Rodolfo Gonzalez
Luis Henriquez
Alan Valenzuela

Sección: 002V
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

Historia de Revisiones

Fecha Versión Descripción Autor


2020-06-26 1.1.0 Documento inicial Rodolfo González
2020-07-10 1.1.1 Modificaciones Rodolfo González
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

Contenido
1 INTRODUCCIÓN..........................................................................................................................................4
1.1 PROPÓSITO................................................................................................................................................4
1.2 ÁMBITO.....................................................................................................................................................4
1.2.1 Pruebas funcionales.........................................................................................................................4
1.2.2 Riesgos.............................................................................................................................................5
1.2.3 Identificación del proyecto...............................................................................................................7
1.3 BREVE DESCRIPCIÓN.................................................................................................................................7
2 REQUERIMIENTOS PARA PRUEBAS.....................................................................................................9
2.1 CASOS DE USO...........................................................................................................................................9
2.1.1 Caso de uso usuario.........................................................................................................................9
2.1.2 Caso de uso vendedor......................................................................................................................9
2.1.3 Caso de uso técnico........................................................................................................................10
2.1.4 Caso de uso bodega.......................................................................................................................10
2.1.5 Caso de uso supervisor..................................................................................................................11
2.1.6 Caso de uso web service municipalidad........................................................................................11
2.1.7 Caso de uso web service shimano..................................................................................................11
2.2 REQUERIMIENTOS FUNCIONALES............................................................................................................12
2.3 REQUERIMIENTOS NO FUNCIONALES.......................................................................................................12
3 ESTRATEGIA DE PRUEBAS....................................................................................................................13
3.1 TIPOS DE PRUEBAS..................................................................................................................................14
3.1.1 Integridad de la base de datos y de los datos................................................................................14
3.1.2 Pruebas funcionales.......................................................................................................................15
4 RECURSOS..................................................................................................................................................17
4.1 PROFESIONALES......................................................................................................................................17
4.2 AMBIENTE DE PRUEBAS..........................................................................................................................17
4.2.1 Preparación del ambiente de pruebas...........................................................................................18
4.2.2 Diseño del ambiente de pruebas....................................................................................................18
4.2.3 Integración del ambiente de pruebas y configuración...................................................................19
4.2.4 Definición del banco de datos de prueba.......................................................................................20
4.2.5 Generación de datos......................................................................................................................20
5 ACTIVIDADES E HITOS DEL PLAN DE PRUEBAS...........................................................................22
5.1 A: TAREAS DEL PROYECTO.....................................................................................................................24
5.2 B: PRUEBAS DE RENDIMIENTO (PERFORMANCE).....................................................................................25
5.3 C: PRUEBAS DE SEGURIDAD Y DE CONTROL DE ACCESO........................................................................26
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

1 Introducción
1.1 Propósito

La “Calidad de un producto” hace referencia a que el producto salga con el más alto porcentaje de efectividad.
La idea principal 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, ya sea tanto en los TextBox, Labels, los botones, los
ComboBox y toda la usabilidad del sistema.

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

Supervisar si se cumple las especificaciones de negocio 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.

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

1.2 Ámbito

El conjunto de tareas necesarias para conseguir el objetivo del proyecto son el verificar uno por uno cada uno
de los componentes del sistema, se revisarán desde el primer TextBox hasta el último, también se revisarán las
ubicaciones de cada uno de los componentes, que los botones cumplan con las especificaciones para las cuales
fueron diseñados. Además de revisar la correcta persistencia de datos y la usabilidad del sistema.

1.2.1 Pruebas funcionales


El testing señalado es del tipo “Caja Negra”. Este tipo de pruebas busca comprobar el comportamiento de un
componente, sin inspeccionar sus detalles internos.
Con esta finalidad se utilizan datos de entrada (input), se ejecuta un componente de software y se obtiene un
resultado (output).
Los datos de entrada son los utilizados por las transacciones involucradas. Cada argumento de entrada puede
seleccionar uno de los siguientes datos de prueba, dependiendo este del resultado que se desea obtener
(esperado), verificando así el comportamiento del componente a probar usando distintos valores de entrada:
 Valores normales para cada transacción.
 Valores límites para cada transacción.
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

 Valores de borde.
 Valores ilegales.

1.2.2 Riesgos
Algunos riesgos comunes por considerar son:
1. Documentación de especificación errónea o incompleta.
2. Lista de requerimientos inconsistente con los casos de uso.
3. Componentes a probar y componentes comunes correspondan a distintas versiones.
4. Hardware y software no funcionen correctamente.
5. Herramientas de testing automatizado estén mal configuradas.
Los riesgos serán identificados de acuerdo a un concepto de Bajo, Medio o Alto, dependiendo de la
importancia del caso de uso para el cual se está desarrollando el testing.
Así mismo, se han identificado una serie de riesgos (calificados entre 1 y 10 dependiendo de su gravedad) los
que están detallados en el artefacto “Lista de riesgos” con sus alcances y acciones, en el presente plan, son
enunciados para sugerir algunas acciones.

1.2.2.1 Matrices de riesgos

1.2.2.1.1 Pruebas

Nº Riesgo Descripción Gravedad Acción

1 Documentación de especificación Alto Adecuar la documentación a la


errónea o incompleta realidad presente del proyecto.

2 Lista de requerimientos inconsistente Alto Plantear al Cliente que un


con los casos de uso cambio de requerimiento en
esta fase del proyecto es
demasiado riesgoso para el
cumplimiento de este en los
plazos establecidos,
proponiéndole que esto sea
abordado como mejora en una
futura actualización.

3 Hardware y software no funcionen Medio Verificar y reemplazar


correctamente acomodando el HW al SW.
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

4 Costo del proyecto excede el Medio Indicar que por X motivo el


presupuestado. costo del proyecto aumentará
dentro del margen indicado al
comienzo del proyecto, será
decisión del cliente aceptar
este aumento o redefinir los
requisitos del sistema.

5 Tiempos de entrega excede el indicado Medio Redefinir tiempos por etapa,


inicialmente revisando cuales tiempos
puede ser movido a otras
etapas sin afectar cada una de
ellas.

6 Componentes a probar y componentes Bajo Homologar las versiones de


comunes correspondan a distintas ambos componentes para una
versiones. correcta ejecución de pruebas.
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

1.2.2.1.2 Proyecto MasterBike


Nº Riesgo Descripción Gravedad
1 Enfermedad de uno de los integrantes por pandemias Media
Problemas de plataforma, tecnología y comunicaciones
2 Baja

3 Personal con experiencia abandona el proyecto Media


4 Informes poco claros sobre la evolución del proyecto Alta

5 El cliente solicita nuevos requerimientos que impactan el Alta


diseño
Robo de los equipos de hardware adquiridos para la
6 Media
implementación del sistema

1.2.3 Identificación del proyecto

Documento Creado o Recibido o Autor u Notas


(versión / fecha) Disponible Revisado Origen
Visión del producto Si  No  Si  No
Especificación de Requerimientos de  Si  No  Si  No
Software
Modelos de Casos de Uso  Si  No  Si  No
Plan del Proyecto  Si  No  Si  No
Modelos de Diseño  Si  No  Si  No
Prototipos  Si  No  Si  No
Manuales de Usuario  Si  No  Si  No
Modelo de Negocio y Flujo  Si  No  Si  No
Modelo de Datos y Flujo  Si  No  Si  No
Funciones del Negocio y Roles  Si  No  Si  No

1.3 Breve Descripción


El proyecto “MasterBike” contempla la implementación de una plataforma web donde utilizaremos servicios
de tipo REST que es una arquitectura cliente-servidor que promueve la separación en dos componentes: la
lógica de negocio y la lógica de presentación. Esto permite que las capas de presentación puedan modificarse
independientemente de la lógica de negocio.
Funciona a través de protocolo HTTP con servicios web, en este caso se consumirán 2 APIS, la primera será el
uso de servicios en una API central “Servicios Masterbike” para todas las peticiones de la plataforma, la cual su
salida serán arreglos de tipo JSON, por otra parte, los pagos serán procesados por otra API la cual se encargará
de esta lógica.
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

2 Requerimientos para pruebas


La siguiente lista identifica los ítems (casos de uso, requerimientos funcionales y requerimientos no
funcionales) que se han identificado como requerimientos a ser probados.

2.1 Casos de uso

2.1.1 Caso de uso usuario

2.1.2 Caso de uso vendedor


Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

2.1.3 Caso de uso técnico

2.1.4 Caso de uso bodega


Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

2.1.5 Caso de uso supervisor

2.1.6 Caso de uso web service municipalidad

2.1.7 Caso de uso web service shimano


Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

2.2 Requerimientos funcionales


Nombre Requerimiento
RQF-001 Registro de usuarios
RQF-002 Solicitud de Arriendo
RQF-003 Solicitud de reparación
RQF-004 Ver solicitudes reparación
RQF-005 Envió de correos
RQF-006 Consultar stock
RQF-007 Historial mantenciones
RQF-008 Consultar estado reparación
RQF-009 Seguimiento de productos
RQF-010 Mantenedor de usuarios
RQF-011 Mantenedor de proveedores
RQF-012 Mantenedor de empresas/municipalidades
RQF-013 Mantenedor de servicios
RQF-014 Consultar convenio
RQF-015 Consultar productos (Shimano) vía servicio web

2.3 Requerimientos no funcionales


RQNF-01 Plataforma web
RQNF-02 Plataforma escritorio

RQNF-03 Responsivo

RQNF-04 Escalable
RQNF-05 Uso de BBDD común para aplicaciones
RQNF-06 Uso de colores corporativos
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

3 Estrategia de Pruebas

La estrategia que se definido con el equipo de trabajo consiste en realizar un conjunto de pruebas en los
sistemas antes de realizar la Implementación de los sistemas, además para corroborar se realizaran estas
pruebas de forma individual junto a sus análisis respectivos. Se evidenciará estas pruebas en la aplicación
MantisBT.

Después de la realización de la implementación de los sistemas se realizarán nuevamente un conjunto de


pruebas con el análisis respectivo, se realizará las pruebas de forma individual.

A continuación, se mostrarán los respectivos diagramas que ejemplifican la estrategia de realización de las
pruebas.
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

1.1 Tipos de pruebas

3.1.1 Integridad de la base de datos y de los datos


El Administrador de Bases de Datos de MasterBike, deberá asegurar que las bases de datos para pruebas sean
un reflejo de las de producción.
El Administrador de Bases de Datos deberá indicar las herramientas y técnicas para ejecutar esta prueba.

Objetivo de la prueba: Asegurar que los métodos de acceso a la base de datos y los procesos
asociados, funcionan apropiadamente y sin riesgo de datos corruptos.
Técnica a utilizar: Realizar la llamada a una base de datos y ejecutar algún proceso con datos
válidos e inválidos.
Inspeccionar la base de datos para comprobar que los procesos se han
realizado correctamente.
Criterio de validación: Todos los métodos de acceso a la base de datos y sus procesos deben estar sin
datos corruptos.
Consideraciones La prueba puede requerir que el Administrador de bases de datos diseñe una
especiales: herramienta para acceder a los datos directamente.
Se debe utilizar una reducida cantidad de registros para facilitar la inspección
de los datos e identificar eventos erróneos.
Observaciones:
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

1.1.1 Pruebas funcionales


El testing funcional se realizará sobre los requerimientos funcionales antes descritos y sus casos de uso. Estas
pruebas tienen por finalidad comprobar la funcionalidad de la aplicación a partir de datos válidamente
seleccionados sobre las transacciones del sistema.
Este tipo de comprobación se basa en las técnicas de caja negra, que permiten probar la aplicación (y sus
procesos interinos) vía GUI.
Objetivo de la prueba: Asegurar la funcionalidad del conjunto de casos, incluyendo la navegación en
la aplicación, el ingreso de datos, el proceso y la recuperación (resultados).
Que la navegación a través de los casos de prueba refleje apropiadamente las
reglas del negocio y los requerimientos, incluyendo ventana a ventana, campo
a campo y usando los métodos de acceso correctamente (tecla tab,
movimiento del mouse, etc.)
Que los objetos de las ventanas y sus características, tales como menús,
tamaño, posición, estados y foco, estén de acuerdo a los estándares.
Técnica a utilizar: Ejecutar cada caso de uso, su flujo y funcionalidad usando tanto datos válidos
como inválidos para comprobar lo siguiente:
 Que los resultados esperados ocurren cuando los datos válidos son
utilizados.
 Que el mensaje de error es apropiado cuando se utilizan datos inválidos.
 Que cada regla de negocio se utiliza apropiadamente.
 Crear y modificar los procedimientos de prueba para cada ventana, para
comprobar los estados de los objetos y de la aplicación.
Criterio de validación:  Todas las pruebas planificadas se ejecutaron correctamente.
 Todos los defectos identificados han sido asignados.
 Cada ventana debe ser verificada para mantener la consistencia con la
versión maestra y comprobar que esté dentro de los estándares
aceptables.
Consideraciones [Puede que no todas las propiedades sean verificadas, considerar las más
especiales: importantes y/o definidas y no incluir todos los objetos de terceras partes.]
Observaciones:

3.1.2
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

4 Recursos
4.1 Profesionales

Recursos Humanos
Rol Recursos mínimos Responsabilidades específicas / Comentarios
recomendados
(Número de personas full-time)

Diseñador de casos 1 Responsabilidades


de prueba
 Identificar, priorizar e implementar los casos de
prueba.
 Evaluar de forma el esfuerzo de testing.
Testeador 1 Responsabilidades:
 Ejecutar los casos de prueba.
 Guardar estado de los resultados.
 Recuperación de errores.
 Generar peticiones de cambios en la
documentación.
Administrador de 1 Responsabilidades
sistema de las
 Administrar el sistema de control de pruebas.
pruebas
 Instalar / administrar el acceso al sistema de
pruebas.
Administrador de la 1 Responsabilidades:
base de datos /
 Administra los datos de la prueba (Base de Datos)
Encargado de la base
de datos  Asegurar que el entorno de datos de prueba
(base de datos) y los valores que contiene son
controlados y mantenidos.
Diseñador 1 Responsabilidades:
 Identificar y definir las operaciones, atributos y
asociaciones de las clases de prueba.
 Identificar y definir los paquetes de prueba.
Implementador 1 Responsabilidades:
 Implementar las clases de prueba y los paquetes
de prueba.

4.2 Ambiente de pruebas


Se identifican los requerimientos de hardware, software y de comunicación necesarios para crear y dar soporte
permanente al Ambiente de pruebas. Las actividades de instalación y configuración para el conjunto de los
componentes del Ambiente de pruebas, deberán ser planificadas y calendarizadas. Se requiere que este
ambiente sea seguro, estable y dedicado exclusivamente para las pruebas del sistema.
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

4.2.1 Preparación del ambiente de pruebas


Las pruebas unitarias y de regresión deberán ser ejecutadas dentro del Ambiente de desarrollo, las pruebas de
aceptación del usuario y del sistema se ejecutarán en este Ambiente de pruebas. Este ambiente deberá
representar una configuración idéntica al Ambiente de producción o al menos, una versión en menor escala.
Esto se requiere debido a que se debe replicar el rendimiento de la línea base y las medidas de mejoramiento
relacionadas.

4.2.2 Diseño del ambiente de pruebas


El siguiente diagrama muestra la arquitectura del Ambiente de pruebas requerido para realizar las pruebas. La
arquitectura del ambiente de pruebas debe ser, en la medida de lo posible, similar a la arquitectura definida
para el sistema en producción.

hardware

Cantidad Equipo Características

01 Servidor  Procesador: Quad-Core de 3 Ghz


 RAM: 32 GB
 Disco duro: 8 TB
 Puerto Ethernet: 02 puertos
Gigabit Ethernet

01 Servidor de respaldo  Procesador: Quad-Core de 3 Ghz


 RAM: 32 GB
 Disco duro: 8 TB
 Puerto Ethernet: 02 puertos
Gigabit Ethernet

01 Servidor Base de Datos  Procesador: Quad-Core de 3 Ghz


 RAM: 64 GB
 Disco duro: 16 TB
 Puerto Ethernet: 02 puertos
Gigabit Ethernet

01 Servidor Base de Datos, de  Procesador: Quad-Core de 3 Ghz


respaldo
 RAM: 64 GB
 Disco duro: 16 TB
 Puerto Ethernet: 02 puertos
Gigabit Ethernet
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

03 Estaciones de trabajo  Procesador: Intel Core I3


 RAM: 8 GB
 Disco duro: 1 TB
 Puerto Ethernet: 01 puerto Gigabit
Ethernet
 Conexión Wifi

01 Switch  Switch CISCO, administrable.


 12 puertos Gigabit

02 UPS  7,5 kVA – 200 kVA.

01 Instalación de red  Cable UTP (50 mts)


 07 PatchCord

01 Rack de comunicaciones  Espacio para dividir a elección


 3 bandejas desmontables
 Ventilador de 120x38 mm en tapa
superior, alimentado por 220v
 Paneles laterales desmontables
 Puerta frontal con ventana de
vidrio y cerradura
 Canaletas para orden de cables
 Ruedas con Freno de seguridad
 Ancho: 600 mm
 Profundidad: 800 mm
 Alto: 1,50 mts

4.2.3 Integración del ambiente de pruebas y configuración


Para esta actividad se requerirá la participación de profesionales de MasterBike en cuanto a instalación,
configuración y puesta en marcha del Ambiente de Pruebas. Principalmente se requiere del responsable de la
Red y Administración de Bases de Datos, de tal forma de obtener un ambiente lo más consistente y similar al
de producción, con las bases de datos creadas y el software configurado para asegurar que el sistema funciona
de acuerdo a diseño.
Las actividades generales a ser consideradas son:
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

Actividad Responsable Observaciones


Revisar el Servidor de la Gerente de La responsabilidad de todos estos ambientes es Eduardo
BD operaciones Castillo, gerente de operaciones
Configuración de las Gerente de La responsabilidad de todos estos ambientes es Eduardo
estaciones de trabajo operaciones Castillo, gerente de operaciones
Instalación de la Red Gerente de La responsabilidad de todos estos ambientes Eduardo
operaciones Castillo, gerente de operaciones
Respaldo de los Gerente de La responsabilidad de todos estos ambientes Eduardo
servidores operaciones Castillo, gerente de operaciones

4.2.4 Definición del banco de datos de prueba


Se deberán tomar las siguientes consideraciones al momento de generar el Banco de datos.
Se requiere conocer la documentación del sistema, de tal forma de obtener el máximo de información para la
creación de los datos.
La documentación que se requiere es:
 Documentación conceptual del sistema.
 Definición de Requerimientos.
 Especificación de software / hardware.
 Diagrama entidad - relación.
 Diagrama de casos de uso.
 Diagrama de estados.
 Diccionario de datos.

4.2.5 Generación de datos


La generación de los datos para las pruebas considera los siguientes aspectos, que se deben definir de acuerdo
con los requerimientos y posibilidades de obtención. Los aspectos que se describen a continuación buscan que
los datos sean los correctos y que cubran todos los riesgos y situaciones necesarias.

4.2.5.1 Muestra de producción


Para que la muestra de datos sea realmente representativa, se deberá elegir una fecha testigo adecuada y que
posibilite la mayor cobertura de datos. En este sentido se ha elegido como fecha testigo el 15/08/2020. Para la
obtención de datos por esta vía, se deberán definir las restricciones (por motivos de confidencialidad) y
generar algún utilitario para filtrar los datos de tal forma de obtener la mayor variabilidad de datos posible.
Además, se deben considerar los siguientes aspectos para asegurar que estos datos funcionen correctamente
en el Ambiente de Pruebas, si corresponde:
 Archivos Maestros al Inicio del Día
 Tablas de Parámetros
 Interfaces de Entrada
 Archivos de Movimientos del día o del periodo
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

Todos estos aspectos se deben considerar en los distintos ambientes donde los datos van a ser utilizados en las
transacciones o actualizaciones.

4.2.5.2 Datos complementarios


En este aspecto se debe comprobar si es necesario generar datos complementarios para cubrir todas las
posibles variaciones que se puedan dar. La generación de los datos complementarios dependerá de los datos
obtenidos de producción y de la información que está en la documentación solicitada.
Uno de los aspectos a considerar para generar datos complementarios son las fechas, para lo cual se deberá
considerar el envejecimiento de los datos a objeto de mantener la consistencia de las pruebas e independencia
de la fecha de proceso.

4.2.5.3 Envejecimiento de datos de prueba


Se debe considerar el envejecimiento de los datos de prueba, de tal forma que cumplan con la validez de las
pruebas. Los datos a envejecer serán tanto los obtenidos desde producción como los complementarios
generados para cubrir el total de las condiciones y variaciones.
Las siguientes consideraciones son eventuales y deberán considerarse sólo si es necesario. Tienen especial
relevancia ciertas fechas en que, para Masterbike, se realizan procesos claves, las fechas en cuestión con sus
implicancias se detallan a continuación:

Fecha Consideraciones Observaciones


26/06/2020 Se debe considerar el mes No se realizó ningún de
anterior para generar los observacion
informes
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

5 Actividades e Hitos del Plan de Pruebas


Tarea Responsable Esfuerzo Fecha Inicio Fecha Término
Plan de Pruebas Jefe proyecto
Identificar el Proyecto Jefe de Proyecto Alto 26-06-2020 26-06-2020
Definir Estrategia Jefe de Proyecto Alto 26-06-2020 26-06-2020

Estimar Actividades Jefe de Proyecto Alto 26-06-2020 26-06-2020

Identificar Recursos Jefe de Proyecto Alto 26-06-2020 26-06-2020

Documentar el “Plan de Jefe de Proyecto Medio 26-06-2020 26-06-2020


Pruebas”

Agendar de Actividades Jefe de Proyecto Medio 27-06-2020 27-06-2020

Revisar el “Plan de Pruebas” Jefe de Proyecto Alto 27-06-2020 27-06-2020

Diseño de las Pruebas Jefe proyecto, QA


Analizar Requerimientos Analista QA Alto 29-06-2020 29-06-2020
Especificar Procedimientos de Jefe de proyecto Alto 30-06-2020 30-06-2020
prueba

Especificar casos de prueba Jefe de Proyecto Alto 01-07-2020 01-07-2020


Analista Qa
Revisar Cobertura de los Jefe de Proyecto , Alto 01-07-2020 01-07-2020
requerimientos de prueba Analista Qa
Implementación de las Pruebas QA
Establecer Ambiente de Analista Qa Medio 02-07-2020 02-07-2020
Implementación
Desarrollar los Procedimientos Analista Qa Alto 02-07-2020 02-07-2020
de Prueba

Probar y depurar los Analista Qa Alto 03-07-2020 05-07-2020


procedimientos de prueba

Modificar los procedimientos de Analista Qa Alto 06-07-2020 06-07-2020


prueba
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

Tarea Responsable Esfuerzo Fecha Inicio Fecha Término

Ejecución de las pruebas QA


Ejecutar pruebas Analista Qa Alto 06-07-2020 06-07-2020

Comprobar resultados Analista Qa Medio 07-07-2020 07-07-2020


esperados

Investigar resultados Analista Qa Medio 07-07-2020 07-07-2020


inesperados
Jefe de Proyecto
Registrar defectos (log) Analista Qa Medio 08-07-2020 08-07-2020

Re-Ejecutar las pruebas Analista Qa Alto 08-07-2020 08-07-2020

Evaluación de las pruebas Jefe de proyecto


Revisar el Log de pruebas Jefe de proyecto, Alto 09-07-2020 09-07-2020
Analista Qa

Evaluar cobertura de los casos Analista Qa, Jefe Alto 09-07-2020 09-07-2020
de prueba de proyecto

Evaluar defectos Analista Qa, Jefe Medio 09-07-2020 09-07-2020


de proyecto

Reportar defectos Jefe de proyecto Medio 09-07-2020 09-07-2020

Los Esfuerzos se midieron en la forma Alto, Medio Y bajo, dependiendo del esfuerzo que se utilizó en cada
uno de las tareas del plan de pruebas
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

Anexos
5.1 A: Tareas del proyecto
La siguiente lista muestra las tareas relacionadas con el “Plan de pruebas”:
 “Plan de pruebas” (preliminar, al inicio del proyecto)
 Identificar requerimientos para el testing
 Identificar los riesgos, cuantificar impacto
 Desarrollar la estrategia de pruebas
 Identificar los recursos para las pruebas
 Generar “Plan de Pruebas” detallado
 Diseño general de las pruebas
 Análisis de carga
 Identificar y describir los casos de prueba
 Identificar y estructurar los procedimientos de prueba
 Revisar y accesar la cobertura de las pruebas
 Implementar las pruebas
 Grabar o programar los scripts de las pruebas, si aplica
 Identificar las funcionalidades a probar, específicos en el modelo de diseño e
implementación
 Establecer el conjunto de datos externos
 Ejecutar las pruebas
 Ejecutar los procedimientos de prueba
 Evaluar la ejecución de las pruebas
 Comprobar los resultados
 Investigar los resultados inesperados
 Registro de defectos, Informe de Resultados
 Evaluar las pruebas
 Evaluar la cobertura de los casos de prueba
 Evaluar la cobertura del código
 Analizar defectos
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

5.2 B: Pruebas de rendimiento (performance)


El testing de rendimiento es una prueba para comprobar los tiempos de respuestas, la tasa de transacciones y
otros tiempos requeridos de desempeño. Su es comprobar que los tiempos de respuestas requeridos son los
óptimos, y que el desempeño del sistema y la configuración del hardware son adecuados frente a una serie de
transacciones bajo ciertas condiciones de carga.
Para esto, se definen las transacciones de acuerdo a los casos de uso específicos que se espera que un actor
del sistema realice usando un conjunto de datos para agregar o modificar transacciones.

Comprobar la conducta de rendimiento para las transacciones seleccionadas


o funcionalidades bajo las siguientes condiciones:
Objetivo de la
prueba: - Una carga de trabajo normal.
- Una sobrecarga de trabajo.
Usar los procedimientos de pruebas desarrollados para el testing funcional.
Modificar los archivos de datos para aumentar las transacciones o los script
de robotización para incrementar el número de iteraciones de cada
Técnica a usar: transacción.
Los script deberán correr en una máquina (la mejor referencia es un solo
usuario y una única transacción) y repetirla con múltiples clientes (virtuales o
reales).
Una Transacción / Un Usuario: La finalización exitosa de los scripts de prueba
sin ninguna falla dentro del tiempo esperado (por transacción en forma
Criterio de validación: independiente).
Múltiples Transacciones / Múltiples Usuarios: La finalización exitosa de los
scripts de prueba sin ninguna falla dentro tiempo estimado.
La extensión del testing de rendimiento requiere tener en background la
carga de trabajo en el servidor.
Existen varios métodos que se pueden usar para realizar esto como por
ejemplo:
Gatillar transacciones directamente al servidor, normalmente en forma de
llamadas de SQL.
Crear una carga de usuarios virtuales para simular (normalmente varios
Consideraciones cientos) los clientes. Para esto se utilizan herramientas de emulación de
especiales: terminales remotas para lograr esta carga. Esta técnica también puede
usarse para someter a la red a un alto tráfico.
Usar múltiples clientes físicos, cada uno corriendo los Test scripts para
agregar una carga al sistema.
El testing de rendimiento debería realizarse en una máquina dedicada o en
un tiempo dedicado. Esto permite un control total y una exacta medición.
Las bases de datos utilizadas para realizar el testing de rendimiento deberán
ser del tamaño equivalente a las de producción o a escala similar.
Observaciones:
Versión: <1.1.0>
Plan de Pruebas Fecha: 2021/03/21
/conversion/tmp/scratch/515340570.docx

5.3 C: Pruebas de seguridad y de control de acceso


Se recomienda que el Administrador de la Red y del Sistema planifiquen algunas pruebas en este sentido.
Este testing se enfoca en dos áreas claves de la seguridad:
 Seguridad a nivel de la Aplicación, incluyendo acceso a los datos o funciones de negocio, y
 Seguridad a nivel del Sistema, incluyendo la autenticación (login) y/o acceso remoto al sistema.
 La seguridad a nivel de la aplicación, asegura que, sobre la base de la seguridad deseada, se restringen
a los usuarios a ciertas funciones o casos de uso específicos o se les limita el acceso a datos disponible
para ellos.
 La seguridad a nivel de sistema, asegura que sólo los usuarios definidos en el sistema son capaces de
acceder a la aplicación y sólo a través de entradas apropiadas.

Seguridad a Nivel de Aplicación: comprobar que un usuario puede acceder


sólo a las funcionalidades y datos para las cuales ese tipo de usuario tiene
Objetivo de la prueba: permiso.
Seguridad a Nivel de Sistema: comprobar que sólo esos usuarios con
acceso al sistema y aplicación tienen permitido el acceso.
Nivel de Aplicación: Identifique y liste cada tipo de usuario y las
funcionalidades y datos de cada tipo para las cuales tiene permiso.
Cree pruebas para cada tipo de usuario y verifique cada permiso creando
transacciones específicas para cada usuario.
Técnica a usar:
Modifique los tipos de usuarios y vuelva a ejecutar los casos de prueba
para los mismos usuarios. En cada caso verifique si las funcionalidades y los
datos están correctamente disponibles o denegados.
Acceso a Nivel de Sistema: vea las consideraciones especiales más abajo.
Para cada tipo de usuario conocido, las funcionalidades y los datos
Criterio de validación: correctos debieran estar disponibles y todas las transacciones ejecutadas
debieran ejecutarse de acuerdo a lo esperado.
El acceso al sistema debería ser comprobado con el administrador de la red
o del sistema.
Consideraciones especiales:
Este testing quizás pueda requerir de la participación del administrador de
la red o del sistema.
Observaciones:

También podría gustarte