Revisión Histórica

Versión Fecha de Descripción de los Modificador Aprobador Fecha de

revisión cambios aprobación

0.1 19/10/2020 Versión inicial

Revisión Histórica 2

Test Plan 4
Introducción 4
Descripción General 4
Entregables 4
Objetivos 4
Alcances 5
Definiciones y acrónimo 5
Features a ser testeados 5
Features que no serán testeados 6
Entorno de pruebas 7
Testing environment for Alpire Calvetty Abdias Alcides 7
Testing environment for Flores Jaldin Noelia Andrea 7
Testing environment for Uño Soto Daniel 7
Testing environment for Vasquez Lia Richard 8
Estrategias de pruebas 8
Tipos de pruebas 8
Criterios de aceptación y rechazo 9
Bugs 9
Criterio de suspensión 9
Criterio de reanudación 10
Flujo de trabajo para las pruebas 10
Roles y responsabilidades 11
Pruebas de entregables e hitos clave 12
Evaluación de riesgos 12
Enfoque de prueba 13
 Test Plan
1. Introducción
El presente documento fue creado para comunicar el enfoque de pruebas de todos los
miembros del equipo.

El plan de pruebas es un documento detallado que define la estrategia de pruebas, los

objetivos, el cronograma, los entregables, y los recursos necesarios para realizar las pruebas
de un producto de software. el plan de pruebas nos ayuda a determinar el esfuerzo necesario
para validar la calidad del sistema, el plan de pruebas sirve como un modelo para realizar
pruebas de software, como un proceso definido que es supervisado y controlado por un
administrador de pruebas.

¿Por qué es importante un plan de pruebas?

Realizar un plan de pruebas tiene muchos beneficios:
● Ayuda a la gente fuera del equipo de pruebas como ser desarrolladores, gente de
negocios, clientes, a entender a detalle las pruebas.
● El plan de pruebas rige como un libro de reglas el cual debe seguirse.
● Aspectos importantes como la estrategia de pruebas, alcance de pruebas, estimación
de pruebas, son documentados en el plan de pruebas. estos aspectos pueden ser
revisados por el equipo de gestión y puede también ser reutilizado para otros proyectos.

Descripción General
Este plan de pruebas es un documento que define la estrategia que se utilizará para verificar
que el producto se desarrolle de acuerdo a las especificaciones y requisitos.

Entregables
Este plan de pruebas es para una tienda virtual de herramientas, los entregables van de
acuerdo a los requerimientos prioritarios en todo el desarrollo.
-Mostrar productos.
-categorizar productos.

1.1. Objetivos
Mejorar las ventas de una tienda de herramientas mediante la implementación del sistema
“tienda virtual de herramientas”.

Este sistema mostrará de forma pública a todos sus clientes e interesados los diferentes
productos que tiene en la tienda de herramientas como ser la imagen del producto, el precio, y
un botón para ver detalles de un producto en específico, poder seleccionar los productos por
categorías, etc
Para este sistema se entregará “tienda de herramientas” se entregará con la funcionalidad de
poder visualizar los productos en la sección “home” y así poder clasificar los productos por
categorías todo esto en la sección de “catálogo”.
El sistema se desarrollará en 3 sprints de tres semanas con 8 desarrolladores y 4 personas a
cargo del control de calidad(QA).

1.2. Alcances
La fase inicial incluirá todos los requisitos con mayor prioridad en el producto backlog, estos y
otros requisitos que se incluyan deben ser probados. Un tester debe ser capaz de:
1. Poder ver los diferentes productos en la sección HOME
2. poder dirigirse al sección de catálogo.
3. Poder clasificar los diferentes productos por categorías.
4. Poder ver el carrito de compras.

Paralelamente al trabajo del equipo en el sistema, se definirá aspectos y necesidades de las

siguientes fases.

Se ejecutarán estos tipos de pruebas por la importancia de los requisitos.

1. Pruebas de funcionalidad.
2. Pruebas de interfaz de usuario.
3. Pruebas de regresión.
4. Pruebas de sanity

2. Definiciones y acrónimo
Para el desarrollo de este proyecto no se utilizará acrónimos

3. Features a ser testeados

Módulo Rol Features

Vista de productos. cliente ● visualizar el nombre

del producto con su
imagen, precio
correspondiente y su
botón “Detalles”.
● tamaño de las
imágenes
● visualizar el navbar
en la parte superior.

Catálogo de productos. cliente ● visualizar todos los

productos que
pertenezcan a la
categoría
seleccionada con su
 nombre, imagen y
precio específico.
● tamaño de las
imágenes
● Mostrar un mensaje
especificando que no
hay ningún producto
en la categoría
● verificar que el boton
de la categoria
seleccionada cambia
de color.
● vista del catálogo de
productos en tablets y
dispositivos móviles.
● visualizar el navbar
en la parte superior.

Detalle de un cliente ● visualizar imágenes

producto extra del producto.
● visualizar el botón de
agregar al carrito el
cual se habilita
cuando se seleccione
una cantidad
de productos a
comprar.
● se podrá añadir el
producto al carrito de
compras.

Carrito de compras cliente ● visualizar los

productos que se
agregaron a el carrito.
● visualizar un botón
“comprar”.

Registro de admin ● visualizar un

productos formulario para el
registro de productos.

Registro de admin ● visualizar el input

categorías para crear una nueva
categoría.
4. Features que no serán testeados

Módulo Features

Servidores del proyecto ● Conexión al servidor

Base de Datos del proyecto ● Conexión a la base de datos

Registrar la compra de un producto ● Visualiza la imagen del producto a

ser comprado.
● Visualizar el precio del producto.
● Visualizar la cantidad de productos
comprados.
● Visualizar el nombre,apellido,tipo de
pago,nit del comprador.
● En caso de envio por delivery se
pedirá su dirección.

Entrega de un pedido o compra ● Visualizar el nombre del producto

● Visualizar el precio del producto
● Visualizar el nombre del comprador

Asignación de rutas óptimas para la entrega ● Visualizar un mapa para ver las
posibles rutas.
● designar la ruta mas optima a una
movilidad.

Designar la movilidad correspondiente al ● Visualizar las movilidades

envío disponibles para realizar el envío.
● Visualizar un botón para designar
una movilidad

Registrar cliente al sistema ● Visualizar un formulario para el

registro de clientes.

Llenar el formulario de términos y

condiciones a momento de comprar un ● Visualizar un formulario para la
producto compra de productos
 5. Entorno de pruebas
El equipo QA está conformado por cuatro miembros quienes se encargaran de probar o
verificar los features en sus respectivas máquinas físicas individualmente.

5.1. Testing environment for Alpire Calvetty Abdias Alcides

● Entorno físico de prueba local

● Windows 10 64bits
● 4GB RAM
● Core i3
● 1 TB HDD
● Microsoft Edge versión 86.0.622.61

5.2. Testing environment for Flores Jaldin Noelia Andrea

● Entorno físico de prueba local

● Windows 10 Home 64bits
● 4GB RAM
● Core i3
● 1 TB HDD
● Opera versión 71.0.3770.271

5.3. Testing environment for Uño Soto Daniel

● Entorno físico de prueba local

● Windows 10 64bits
● 12GB RAM
● Core i7
● 1 TB HDD
● Edge chromium versioón 86.0.622.58

5.4. Testing environment for Vasquez Lia Richard

● Entorno físico de prueba local

● Windows 10 64bits
● 12GB RAM
● Core i3
● 500 GB SSD
● Navegador opera versión 71.0.3770.271
 ● Navegador Chrome versión Versión 86.0.4240.111 (Build oficial) (64 bits)

6. Estrategias de pruebas
● Las tareas de control de calidad deben ser parte de cada historia de usuario a verificar.
● Se deben crear casos de prueba en cada tarea de control de calidad.
● Todas las tareas de control de calidad deben iniciarse una vez que se tenga un software
testeable.
● Los errores encontrados en cada historia de usuario, deben estar vinculados a las
historias de usuario dentro del sprint.
● Los errores que se encuentren fuera de la tarea del sprint pueden ser puestos en el
backlog.
● Los errores encontrados deben tener un caso de prueba creado.
● Los errores encontrados se notificarán al equipo de desarrollo en el menor tiempo
posible.
● Los ids de los bug report serán los mismos ids que se pongan en los test cases con la
finalidad de tener un mejor orden de los mismos.

7. Tipos de pruebas

Como el proyecto está enfocado a solo 3 sprints se ha seleccionado pruebas que se adapten
en función al tiempo establecido.

7.1 Pruebas de funcionalidad.

La prueba funcional es un tipo de prueba de caja negra que se realiza para confirmar que la
funcionalidad de una aplicación o sistema se está comportando como se esperaba.

7.2 Pruebas de interfaz de usuario.

También conocidas como pruebas de GUI, las pruebas de IU es el proceso de probar

los elementos visuales de una aplicación para validar si cumplen con precisión el
rendimiento y la funcionalidad esperados. Al probar la GUI, los evaluadores pueden
validar que las funciones de la interfaz de usuario están libres de defectos.
7.3 Pruebas de sanity

Es una prueba de regresión acotada y se centra en una o unas pocas áreas de funcionalidad,
son acotadas y profundas.

● No se utilizan scripts.
● Se utiliza para determinar si una pequeña sección de la aplicación sigue funcionando
después de un cambio menor.
● Es una prueba superficial pero suficiente para probar si la aplicación está funcionando
adecuadamente. Es un subconjunto de pruebas de regresión.
● Verifica si se cumplen o no con los requisitos, comprobando todas las características de
amplitud primero.

7.4 Pruebas de Regresión

Es un tipo de prueba de software que pretende asegurarse de que los cambios (mejoras o
correcciones de defectos) en el software no lo han afectado negativamente.

7.5 Pruebas de aceptación

Un tipo de prueba realizada por el Cliente para certificar el sistema con respecto a los requisitos
acordados. Esta prueba se realiza en la fase final de las pruebas antes de mover la aplicación
de software al entorno de mercado o producción.

8. Criterios de aceptación y rechazo

● Los casos de prueba que tienen al menos 1 paso que se ha producido un error, se
marcarían como Errores
● Los casos de prueba deben tener el 100% de los pasos pasados para ser marcados
como Aprobados
8.1. Bugs
Los problemas marcados como Medio y Alto serán obligatorios para ser corregidos y probados
de forma nueva. Mientras que los problemas contemplados como bajos o menos serán
considerados para la mejora para futuras versiones o estarán a disposición en el backlog​.

8.2. Criterio de suspensión

Si el 40% de los casos de prueba que se van a probar se marcarán como erróneos. Todas las
pruebas se detendrán hasta que el desarrollo termine solucionar los problemas actuales
 8.3. Criterio de reanudación
Una vez entrado a un criterio de suspensión cuando el equipo de desarrollo arregle un rango de
5% de los bugs reportados, se retomará la ejecución de pruebas.
9. Flujo de trabajo para las pruebas
10. Roles y responsabilidades

Nombre Rol Responsabilidades

Roberto Andres Flores Mendez Developer Encargados de desarrollar el

software de acuerdo a sus
Stephany Caceres Rengel Developer historias de usuario.

Alejandro Rai Carreño Huaipara Developer

Victor Hugo Samir Valencia Developer

Arguellez

Osvaldo Erquicia Cespedes Developer

Josue Jimenez Nina Developer

Juan Luis Zarate Fernandez Developer

Abdias Alcides Alpire Calvetty Tester Responsables de que sea

entregado un software de
Noelia Andrea Flores Jaldin Tester calidad

Daniel Uño Soto Tester

Richard Vasquez Lia Tester

Juan Luis Zarate Fernandez Product Owner Tiene la responsabilidad de

definir los requerimientos del
equipo, definir las historias
de usuario y gestionar el
product backlog

Josue Jimenez Nina Scrum Master Tiene la responsabilidad de

liderar al equipo y hacer
cumplir los objetivos hasta el
último Sprint

Rosemary Torrico Bascope StakeHolder Es la parte interesada de el

proyecto a entregar
11. Pruebas de entregables e hitos clave

Fase del Proyecto Entregables Fecha de entrega

Sprint 1 -Mostrar un producto 06/11/2020

-Mostrar un catálogo de
productos

Sprint 2 -Registro de productos 27/11/2020

-Registro de categorías
-Autentificación del usuario
Admin

Sprint 3 -Ver detalles de un producto 18/12/2020

-Añadir un producto al carrito
de compra
-Ver carrito de compra

12. Evaluación de riesgos

Evaluación Impacto Mitigación

Los cambios en la Alto Pedir que cualquier cambio

funcionalidad pueden negar en las historias de usuario
las pruebas ya descritas y por parte de los
podemos perder casos de desarrolladores se notifique
prueba ya escritos al equipo de testers para un
mejor seguimiento del
proyecto

Poco tiempo para finalizar Medio Cree documentos de alto

toda la documentación de nivel sin mucha
casos de prueba y guías especificación, a menos que
el cliente lo requiera

Falta de informes y Alto Pedir al equipo de

entregables desarrolladores y tester que
entreguen un informe de su
avance cada que finalice un
sprint

Entregar el software para Alto Pedir al equipo de desarrollo

testear fuera de las fechas que sean más puntuales con
establecidas las fechas de entregas.

La inconsistencia entre los Medio Que el software entregado

mockups presentados por sea más fiel a los mockups
los desarrolladores y el entregados
software entregado

13. Enfoque de prueba

Para este proyecto se usará un enfoque ágil, en el que se trabajará con Sprints que tendrán
una duración de 3 semanas, donde los equipos de desarrolladores entregarán los
requerimientos y luego los testers probaran lo entregado.