Informe de Calidad Del Primer Sprint - BUG HUNTER PDF

Informe de Calidad
del primer Sprint
Grupo QA: BugHunter

Grupo DEV: DevCat
Integrantes:
1. Cespedes Temo Fabiana Belen.

2. Chuquimia Arcangel Einar Jarol.
3. Oropeza Andia Kevin Fabrizio.
4. Valdez Mamani Simón Pedro.
5. Zerain Quinteros Genki Sebastian.

Materia: Gestión de Calidad de Software
Docente: Rosemary Torrico Bascope
Carrera: Ingeniería de Sistemas
Año: 2022
ÍNDICE
Test Plan
1. Introducción
1.1 Alcance
1.1.1 Dentro del alcance
1.1.2 Fuera del alcance
1.2 Objetivo de calidad
1.3 Funciones y responsabilidades
2. Metodología y tipos de prueba
2.1 Estrategias de pruebas
2.2 Tipos de prueba
2.3 Análisis y gestión de riesgos
2.4 Clasificación de errores
2.5 Criterios de suspensión y requisitos de reanudación
2.6 Completitud de la prueba
3. Necesidades de recursos y medio ambiente de las pruebas
3.1 Herramientas de prueba
3.2 Entorno de prueba
4. Calendarización
5. Entregables de prueba
5.1 Test cases a alto nivel
5.1.1 Test cases a detalle
5.2 Bug report del primer test run
5.2.1 Bug report del segundo test run
5.3 Reporte de progreso de test runs
5.4 Reunión de Retrospective

1. Introducción
El contenido de este documento “Test plan” hace parte integral de la metodología de

pruebas y la gestión de calidad y fue creado para dar a conocer el enfoque de las
pruebas a todos los miembros del equipo.
Este documento se encuentra fundamentado en guías, documentación y buenas
prácticas que se siguen al momento de llevar a cabo la ejecución de pruebas de
calidad en un proyecto de desarrollo de software que no solo permiten el
seguimiento y correcciones de errores a tiempo sino que además se encuentra
definido por etapas, facilitando el seguimiento y control de los procesos del proyecto
y proporciona información para garantizar la operatividad y funcionalidad de la
aplicación que está en desarrollo “Product Market”.
1.1 Alcance
Dentro este proyecto de desarrollo de software y gestión de calidad, se ha

considerado el Product Backlog completo el cual se muestra a continuación,
mencionando las historias de usuario que contienen los requerimientos funcionales
del software, además en el siguiente apartado se detalla todo lo que está dentro y
fuera del alcance:
Product BackLog
● Registro de cliente
● Iniciar sesión con cuenta de cliente
● Seleccionar categoría producto
● Seleccionar producto
● Buscar un producto en específico
● Visualizar los productos seleccionados en el carrito
● Agregar producto al carrito
● Eliminar productos del carrito
● Aumentar o disminuir productos del carrito
● Realizar compra
● Seleccionar modo de envío
● Seleccionar método de pago
● Añadir ubicación
● Ver mis pedidos
● Cancelar pedidos
● Mostrar Novedades de oferta
● Mostrar información detallada de los productos
● Iniciar sesión con cuenta de proveedor
● Registro de productos
● Filtrar informe por fecha
● Actualizar datos de perfil
● Ver Pedidos
● Mostrar detalle de pedido
● Actualizar productos
● Agregar logo
● Agregar ubicación
● Agregar horarios de atención
● Agregar imagen del producto
A continuación se mencionan aquellas historias de usuario que estarán dentro y

fuera del alcance de las pruebas de calidad.
1.1.1 Dentro del alcance
Primer Sprint
Para el primer sprint, se contemplan 3 historias de usuario.
Fase del proyecto Historias de usuario Fecha de entrega
-H19: Registra datos del producto

Sprint 1 -H23: Editar datos del negocio 19/octubre/2022
-H29: Ver lista de productos
Sprint 2 — —
Sprint 3 — —
1.1.2 Fuera del alcance
Estarán fuera del alcance de las pruebas, todas las historias de usuario que se
desarrollaran a partir del cuarto sprint.
Además de algunas features que se mencionan abajo:
Módulo Feature
Base de datos Componentes, tablas, lógica, consultas

y APIs de la base de datos.
Seguridad Seguridad de la app
Código Lógica y eficiencia del código.
1.2 Objetivo de calidad
Product Market es una aplicación web que tiene como objetivo realizar la oferta de
productos alimenticios de los distintos micromercados y negocios de venta en
Cochabamba, destacando los descuentos que los negocios tienen en sus productos
y proporcionando una opción distinta a la población ya que además puedes localizar
el negocio más cercano a tu ubicación y ver sus ofertas y promociones.
El objetivo de la fase 1 del proyecto es entregar el software “Product Market” con

funcionalidad para que los usuarios proveedores o dueños de negocio puedan
ingresar y registrar sus productos en el sistema, ver la lista de sus productos y editar
datos de los negocios registrados. Además como parte del objetivo es llevar a cabo
más de 100 test case en esta fase y realizar mínimamente 2 test runs para tener un
buen control de calidad al momento de desarrollar el software.
Se cuenta con un equipo de 12 ingenieros (7 desarrolladores y 5 QA).
1.3 Funciones y responsabilidades
Nombre Rol Responsabilidad
Apaza Choque Víctor Developer Encargados de

desarrollar el software de
Developer acuerdo a las historias de
Boza Ruiz Adriana Anahi usuario.
Rojas Huallco Luis Miguel Developer
Mamani Flores Vilma Developer
Pelaez Cruz Maria Andrea Developer
Perez Mamani Rodolfo Kevin Developer
Pelaez Cruz Gizela Yohana Scrum Responsable de liderar al

Master - equipo y hacer cumplir los
Developer objetivos de cada sprint.
Cespedes Temo Fabiana Belen. QA Tester Responsables de que se

entregue un software de
Chuquimia Arcangel Einar Jarol. QA Tester calidad.
Oropeza Andia Kevin Fabrizio. QA Tester
Valdez Mamani Simón Pedro. QA Tester
Zerain Quinteros Genki Sebastian. QA Tester
Rosemary Torrico Bascope StakeHolder La parte interesada del

- Product proyecto a entregar.
Owner
2. Metodología y tipos de prueba
El proyecto utiliza la metodología ágil (Scrum), con iteraciones de 3 semanas.

Durante cada iteración (sprint), los requisitos identificados para esa iteración se
entregarán al equipo QA, se escribirán los test cases y se hará el testeo de las
mismas, siguiendo los criterios de suspensión, reanudación y aceptación.
Seguidamente se hará entrega del bug report al equipo de desarrollo para que
puedan corregir los errores encontrados y al terminar las correcciones se pueda
realizar un segundo testeo.
2.1 Estrategias de pruebas
● Los test case deben escribirse de acuerdo a los criterios de aceptación de las
historias de usuario.
● Para un mejor análisis de la aplicación “Product Market”, cada QA debe
realizar por lo menos 20 test case o más.
● La primera corrida de los test cases debe iniciar después de que haya
concluido el tiempo de desarrollo.
● Los bugs encontrados deben ser propios de un test case y ser reportados
dentro del sprint.
● Si se llega a encontrar un bug fuera de los test case se lo llevará al backlog y
se creará un nuevo test case.
● Reportar los bugs lo más pronto posible, para dar tiempo al equipo de
desarrollo para corregirlos.
● La segunda corrida o posterior debe realizarse después de que se hayan
solucionado los bugs reportados en la primera corrida.
● Los ids de los bugs reportados serán los mismos id`s que se pongan en los
casos de prueba con la finalidad de tener un mejor orden.
2.2 Tipos de prueba
Las pruebas son muy importantes y necesarias para asegurar la calidad del
desarrollo de software. Si bien se cumplen con los requisitos, igualmente es
importante probar que el sistema no se modifica cuando se introducen datos
incorrectos o se realizan acciones inesperadas. Hay que comprobar si alguien
puede poner en riesgo los datos con facilidad o acceder a un recurso que no debe.
En una buena serie de pruebas, se debe intentar modificar la aplicación y ayudar a
conocer su límite. Por lo tanto se llevarán a cabo distintos tipos de pruebas que se
mencionan a continuación:
Pruebas de aceptación
Las pruebas de aceptación son pruebas formales ejecutadas para verificar si un

sistema satisface los requisitos del cliente. Requieren que toda la aplicación esté en
marcha y que se centre en replicar las conductas de los usuarios.
Pruebas de regresión
Es un tipo de prueba de software que tiene la intención de garantizar que los

cambios ya sea mejoras o reparación de errores en el software no lo hayan afectado
negativamente.
Pruebas Funcionales
Las pruebas funcionales se centran en los requisitos de una aplicación. Solo

verifican el resultado de una acción y no comprueban los estados intermedios del
sistema al realizar dicha acción.
Pruebas de humo
Las pruebas de humo son pruebas básicas que sirven para comprobar la
funcionalidad básica de la aplicación. Están concebidas para ejecutarse rápido, y su
objetivo es ofrecerte la seguridad de que las principales funciones del sistema
funcionen según lo previsto.
Pruebas positivas y negativas
Las pruebas positivas determinan que su aplicación funciona como se esperaba. Si

se encuentra un error durante la prueba positiva, la prueba falla. Las pruebas
negativas aseguran que la aplicación pueda ser capaz de manejar entradas no
válidas o comportamientos inesperados del usuario.
Pruebas de sanidad
Las pruebas positivas determinan que su aplicación funciona como se esperaba. Si

se encuentra un error durante la prueba positiva, la prueba falla. Las pruebas
negativas aseguran que la aplicación pueda ser capaz de manejar entradas no
válidas o comportamientos inesperados del usuario.
Pruebas integrales
Las pruebas integrales replican el comportamiento de un usuario con el software en

un entorno de aplicación completo. Además, verifican que diversos flujos de usuario
funcionen según lo previsto, y pueden ser tan sencillos como cargar una página web
o iniciar sesión.
2.3 Análisis y gestión de riesgos
Riesgos Impacto Mitigación
Retraso en una fecha de Alto Mantener una

entrega de parte de devs comunicación constante
con los dev’s a través de
los daily meetings y por el
grupo de whatsapp
Abandono de un Alto Mantener una

integrante del grupo comunicación constante
con el equipo y ayudar a
integrantes que tengan
dudas respecto a sus
historias o sobre las
herramientas de control
El no seguir lo Medio Pedir a los

establecido del software desarrolladores que sean
con relación a los lo más fiel en la interfaz
mockups presentados con los mockups que
fueron presentados en
trello
Muy poco tiempo para Medio Crear documentos de

completar la calidad sin muchas
documentación de Test especificaciones, a
cases y el manual de menos que las pida el
usuario. cliente
Muy pocos reportes y Alto Todo el trabajo se

entregables realizará en Qase de
parte de QA y también se
podrá ver el avance de
Dev’s en Trello y GitHub
Cambios de Alto Asistir a los daily

funcionalidades del meetings de los devs
sistema causando para escuchar sus
pérdidas de test cases avances/problemas que
escritos puedan dirigir a un
posible cambio, y guiarlos
por el camino establecido
Testers se familiaricen Medio Enfocarse en la

demasiado con la funcionalidad de lo
herramienta y desean alcanzable, ya que las
mejorar (aumentar mejoras pueden provocar
alcance de la app) retrasos en la entrega del
producto
2.4 Clasificación de errores
Bugs
Los bugs que se reporten con severidad o prioridad media o crítica deben ser
obligatoriamente arreglados para ser probados nuevamente Los bugs que se
reporten con severidad o prioridad baja pueden ser arreglados para futuras
versiones del sistema.
Defectos
Los defectos reportados son criterios de aceptación no cumplidos por lo tanto deben
ser resueltos.
2.5 Criterios de suspensión y requisitos de reanudación
A continuación se determinan los criterios de calidad aplicables para la aceptación y

rechazo a la aplicación “Product Market”.
Criterio de suspensión
Si el 25% de los casos de prueba son marcados como fallidos, toda prueba se
detendrá hasta que el equipo de desarrollo solucione los problemas reportados.
Criterio de reanudación
Una vez que se aplique el criterio de suspensión el equipo se espera la corrección

de un 80% para continuar con la ejecución de las pruebas.
Criterio de éxito
Una vez concluido el sprint, se espera un 75% de éxito en los Test cases
planteados.
2.6 Completitud de la prueba
Los casos de prueba deben tener el 100% de los pasos aprobados para que sean
marcados como aprobados.
3. Necesidades de recursos y medio ambiente de las pruebas
El equipo de QA está conformado por 5 miembros quienes se encargaran de probar

o verificar los test cases en sus respectivas máquinas físicas individualmente.
3.1 Herramientas de prueba
Dispositivos físicos: PC, Laptop.
Sistema Operativo: Windows.
Navegador web: Google Chrome.
3.2 Entorno de prueba

Ambiente de testing - Simon Pedro Valdez Mamani
● Laptop Toshiba Satellite P50t-B

● Windows 10 (64 bits).
● 12GB RAM.
● Intel Core i7.
● 1 TB disco duro.
Ambiente de testing - Kevin Fabrizio Oropeza Andia
● Laptop Hp
● Windows 10 pro(64 bits).
● 8GB RAM.
● AMD Ryzen 3.
Ambiente de testing - Genki Sebastian Zerain Quinteros
● Laptop Asus Dash f17

● 8GB RAM.
● Intel Core i5.
Ambiente de testing - Fabiana Belen Cespedes Temo
● Laptop Dell Inspiron 15 3000

● 16GB RAM
● Intel Core i5.
● 256GB SSD.
Ambiente de testing - Einar Jarol Chuquimia Arcangel
● Laptop HP 15-gw0xxx
● 8GB RAM.
● AMD Ryzen 5.
● 256GB SSD.
4. Calendarización
El desarrollo de la aplicación se realizará usando la metodología ágil Scrum, con

iteraciones o sprints con una duración de 3 semanas cada una. Dentro de cada
sprint se dispondrá 2 semanas para el desarrollo de software y 1 semana para
realizar las pruebas de calidad.
El primer sprint comienza el 3 de octubre de 2022 y termina el 21 de octubre de

2022.
5. Entregables de prueba
A continuación se detallan los informes que se consideran como entregables para el

seguimiento del desarrollo del software “Product Market”.
5.1 Test cases
Listado de Test Cases a alto nivel del primer Sprint
ID TEST CASE AUTOR
HU 4 Implementar lista de productos
TC-1 Verificar que el logo "Product Market" se SPVM

encuentra al lado izquierdo del head de la
página del proveedor.
TC-2 Verificar que el color de fondo del head sea SPVM

blanco.
TC-3 Verificar que el fondo del body sea una imagen SPVM
de productos de mercado como fondo.
TC-4 Verificar que se muestre el botón “Editar” en la SPVM

parte izquierda del body en la vista del
proveedor.
TC-5 Verificar que se muestre el botón “Registrar SPVM

productos” en la parte izquierda del body en la
vista del proveedor.
TC-6 Verificar que se muestre el botón “Ver productos” SPVM

en la parte izquierda del body en la vista del
proveedor.
TC-7 Verificar que el botón "Editar" dirija a la vista de SPVM

editar datos del negocio.
TC-8 Verificar que el botón "Registrar productos" dirija SPVM

a la vista vista de registrar datos del producto.
TC-9 Verificar que el botón "Ver productos" muestre la SPVM

lista de productos registrados.
TC-10 Verificar que se visualice que la lista de SPVM

productos se encuentre dentro de un recuadro.
TC-11 Verificar que el color del recuadro sea blanco. SPVM
TC-12 Verificar que se vea "Lista de Productos" como SPVM

título en la parte superior central de la tarjeta.
TC-13 Verificar que las columnas de la lista de SPVM

productos tengan los siguientes nombres:
Nombre, Precio normal, Precio descuento, stock.
TC-14 Verificar que las filas y columnas de la lista de SPVM

Productos están separadas como celdas en una
tabla.
TC-15 Verificar que el fondo de la tabla de color plomo. SPVM
TC-16 Verificar que cuando la tarjeta está vacía no se SPVM

pueda ingresar datos en la tarjeta.
TC-17 Verificar que cuando se muestre la lista de SPVM

productos no se pueda editar los datos
mostrados.
TC-18 Verificar que se puede deslizar en la tabla de la SPVM

lista de productos cuando la tabla sea más
grande que la tarjeta.
TC-19 Verificar que el pie de pagina sea de color SPVM

amarillo.
TC-20 Verificar que el espacio entre los botones sea SPVM

proporcionalmente equilibrado.
TC-21 Verificar que cuando no exista productos SPVM

registrados se muestre el mensaje “no existen
productos registrados” en el recuadro blanco.
HU 2 Registrar datos del producto
TC-22 verificar que el menu para registrar se KFOA

despliegue al presionar el botón “Registrar
producto”
TC-23 verificar que el menú desplegado contenga el KFOA

campo “Nombre del producto”

campo “Precio anterior”

campo “Precio actual”

campo “Fecha Vencimiento”

campo “Stock”

campo “Descripción”

campo “URL de la imagen”
TC-30 verificar que el campo “Nombre de productos” KFOA

sólo admite caracteres

admite min 3 caracteres

me muestre un mensaje de error cuando intente
registrar sin poner nada en dicho campo.
TC-33 verificar que el campo “Precio antes” sólo admite KFOA

datos numéricos
TC-34 verificar que el campo “Precio antes” que KFOA

muestre un error cuando introduzca caracteres.
TC-35 verificar que el campo “Precio antes” muestre un KFOA

mensaje de error cuando intente registrar sin
poner nada en el campo.
TC-36 verificar que el campo “Precio actual” sólo KFOA

admite datos numéricos positivos
TC-37 verificar que el campo “Precio actual” que KFOA

muestre un error cuando introduzca caracteres.
TC-38 verificar que el campo “Precio actual” muestre un KFOA

TC-39 verificar que el campo “Fecha Vencimiento” solo KFOA

admita fechas
TC-40 verificar que el campo “Fecha Vencimiento” KFOA

muestre un mensaje de error cuando introduzca
una fecha pasada a la fecha actual.

muestre un mensaje de error cuando introduzca
una fecha con 6 meses de diferencia a la fecha
actual.

muestre un mensaje de error cuando intente
registrar sin poner nada en el campo.
TC-43 Verificar que el campo “Stock” sólo admite datos EJCA

numéricos.
TC-44 Verificar que el valor ingresado en el campo EJCA

“Stock” sea modificable a un valor mayor o
menor sin utilizar el teclado.
TC-45 Verificar que el campo “Stock” muestre un EJCA

TC-46 Verificar que el campo “Descripción” admita todo EJCA

tipo de caracteres..
TC-47 Verificar que el campo “Descripción” admita min EJCA

3 caracteres.
TC-48 Verificar que el campo “Descripción” me muestre EJCA

un mensaje de error cuando intente registrar sin
poner nada en dicho campo.
TC-49 Verificar que en el campo “Descripción” se EJCA

muestre un texto informativo diciendo
“Descripción general del producto”
TC-50 Verificar que el campo “URL de la imagen” EJCA

admita todo tipo de caracteres.
TC-51 Verificar que el campo “URL de la imagen” EJCA

admita el formato de una URL.
TC-52 Verificar que el campo “URL de la imagen” me EJCA

muestre un mensaje de error cuando intente
registrar sin poner nada en dicho campo.
TC-53 Verificar que el logotipo se encuentre en la EJCA

esquina superior izquierda.
TC-54 Verificar que la cabecera de la pagina web sea EJCA

de color blanco.
TC-55 Verificar que el pie de la página web sea de color EJCA

amarillo.
TC-56 Verificar que la imagen en el body corresponda a EJCA

la del mockup.
TC-57 Verificar que el botón Registrar y Cancelar sea EJCA

del color #212529.
TC-58 Verificar que el formulario Información del EJCA
Producto se encuentre al lado derecho.
TC-59 Verificar que el tipo de letra del formulario y EJCA

botones sea Mukta.
TC-60 Verificar que las letras del formulario y botones EJCA

sean en formato capitalizado.
TC-61 Verificar que los botones “Editar”, “Registrar EJCA

producto” y “Ver producto” deban ser del mismo
tipo de letra, tamaño y estén acomodados
simétricamente.
TC-62 Verificar que los formularios estén acomodados EJCA

simétricamente de acuerdo al mockup
correspondiente.
HU 1 Editar datos del negocio
TC-63 Verificar que el campo “Nombre del negocio” es FBCT

obligatorio
TC-64 Verificar que el campo “Nombre del negocio” FBCT

acepte caracteres especiales y alfanuméricos
TC-65 Verificar que el campo “Teléfono” es obligatorio FBCT
TC-66 Verificar que el campo “Teléfono” no acepte FBCT

caracteres especiales o alfabeticos
TC-67 Verificar que el llenado de datos se guarde FBCT

correctamente
TC-68 Verificar que los botones “Cancelar” y “Guardar” FBCT

sean del mismo tamaño
TC-69 Verificar que el campo “Teléfono” acepte solo FBCT

numeros fijos o de celular de Bolivia
TC-70 Verificar que el Botón “Guardar” se encuentre FBCT

centrado en la parte inferior del body
TC-71 Verificar que el pie de la pagina sea de color FBCT

amarillo.
TC-72 Verificar que se muestre un mensaje de error si FBCT

el campo de “Dirección” es incorrecto

el campo “Teléfono” es incorrecto
TC-74 Verificar que el campo “Teléfono“ no acepta FBCT
números negativos
TC-75 Verificar que el campo “Nombre del negocio” no FBCT

acepte más de 30 caracteres
TC-76 Verificar que el campo “Teléfono” no acepte FBCT

numeros de mas de 8 dígitos
TC-77 Verificar que los campos se encuentren FBCT

centrados en medio de la página
TC-78 Verificar que se muestre un mensaje al guardar FBCT

los datos

algo ocurrió mal al guardar los datos
TC-80 Verificar que los botones puedan visualizarse FBCT

correctamente
TC-81 Verificar que el campo “Dirección” sea obligatorio FBCT
TC-82 Verificar que el campo “Dirección” no acepte FBCT

caracteres especiales
TC-83 Verificar que el campo “Horario de atención” sea FBCT

obligatorio
TC-84 Verificar que el campo “Horario de atención” FBCT

permita ingresar horario de apertura y de cierre
del negocio
TC-85 Verificar que el campo “Dirección” no acepte FBCT

más de 50 caracteres
TC-86 Verificar que no te permite guardar un dato FBCT

erróneo en el campo “Teléfono”
TC-87 Verificar que botón “Editar” muestre el apartado GSZQ

correspondiente
TC-88 Verificar que el botón “Cancelar” cancele el GSZQ

proceso de edición
TC-89 Verificar que el campo “Teléfono” no guarde GSZQ

números de menos de 8 dígitos
TC-90 Verificar que el botón “Guardar” no guarde si un GSZQ

campo se encuentra vacío
TC-91 Verificar que en la ventana exista el campo GSZQ

“Nombre del negocio”

“Dirección”

”Horario”

“Teléfono”
TC-95 Verificar el estilo de letra uniforme GSZQ
TC-96 Verificar tamaño uniforme de la letra GSZQ
TC-97 Verificar que el logo sea el correcto GSZQ
TC-98 Verificar uniformidad de botón “Editar” GSZQ
TC-99 Verificar uniformidad de botón “Registrar GSZQ

producto”
TC-100 Verificar uniformidad de boton “Ver producto” GSZQ
TC-101 Verificar que el botón “Guardar” no guarde si te GSZQ

sale un error en uno de los campos
TC-102 Verificar que el fondo de la página sea el GSZQ

respectivo
TC-103 Verificar que el formulario de “Editar datos del GSZQ

negocio” se encuentre en una ventana pequeña
de color blanco.
TC-104 Verificar correcta posición del botón “Editar” GSZQ
TC-105 Verificar correcta posición del botón “Registrar GSZQ

producto”
TC-106 Verificar correcta posición del botón “Ver GSZQ

producto”
SEGUNDO TEST RUN
ID TEST CASE AUTOR
HU 4 Implementar lista de productos
TC-107 Verificar que cuando se muestre la lista de SPVM

productos esta esté ordenada alfabéticamente.
TC-108 Verificar que en la lista de productos exista la SPMV

columna de fecha de promoción.
TC-109 Verificar que el precio descuento sea menor al EJCA
precio normal del producto.
TC-110 Verificar que los espacios en la tabla se EJCA

acomoden de acuerdo al nombre, precios o
stock del producto.
HU 2 Registrar datos del producto
TC-111 Verificar que el botón “Registrar producto” no se KFOA

cambie al presionar el botón
TC-112 Verificar que se muestre un mensaje de éxito al KFOA

registrar el producto.
TC-113 Verificar que el footer no se mueva. KFOA
TC-114 Verificar que el precio actual sea menor al precio KFOA

de antes.
TC-115 Verificar que los precios de los campos “Precio KFOA

antes” y “Precio ahora” no sean los mismos.
TC-116 Verificar que la página no se interrumpa al KFOA

presionar los botones de la página.
HU 1 Editar datos del negocio
TC-117 Verificar que el color del boton “Guardar” sea de FBCT

color negro(#212529)
TC-118 Verificar que el color del boton “Cancelar” sea de FBCT

color negro(#212529)
TC-119 Verificar que al ingresar al apartado “Editar” en FBCT

los campos se muestran datos preestablecidos
de un negocio
TC-120 Verificar que la base de datos actualice los datos FBCT

cambiados en el negocio.
TC-121 Verificar ortografía del botón :” Editar” GSZQ
TC-122 Verificar ortografía del botón :” Registrar GSZQ

producto”
TC-123 Verificar ortografía del botón :” Ver productos” GSZQ
TC-124 Verificar ortografía en el campo :”Editar datos del GSZQ

negocio ”
TC-125 Verificar resolución de imagen de fondo de GSZQ

página en HD
Test Cases en detalle
PRIMER TEST RUN
● IMPLEMENTAR LISTA DE PRODUCTOS
Simon Pedro Valdez Mamani

● REGISTRAR DATOS DEL PRODUCTO
● EDITAR DATOS DEL NEGOCIO
Fabiana Belen Cespedes Temo

Genki Sebastian Zerain Quinteros
SEGUNDO TEST RUN
● IMPLEMENTAR LISTA DE PRODUCTOS

● REGISTRAR DATOS DEL PRODUCTO
● EDITAR DATOS DEL NEGOCIO
Fabiana Belen Cespedes Temo

Genki Sebastian Zerain Quinteros
5.2 Bug report
5.2.1 Primer Test Run
ID TC-15
Título Las esquinas de la lista de productos no son de color

plomo.
Descripción Toda la lista de productos debe estar de color plomo, pero

las esquinas estan de color blanco.
Reportado por Simon Pedro Valdez Mamani
Severidad Menor
Prioridad Baja
Precondiciones Estar dentro de la página web de Product Market.
Pasos para 1 hacer clic en el botón ver lista de productos.

reproducir
2 verificar que se muestre la lista de productos en el
recuadro blanco.
Resultado Visualizar la lista de productos con fondo de color plomo.

esperado
Resultado actual Las esquinas dentro la tabla de la lista de producto no son

de color plomo.
Attachments
ID TC-18
Título No se puede ver toda la lista completa.

Descripción La lista de productos que se muestra solo muestra una
parte de la lista.
Severidad Media
Prioridad Baja

reproducir
recuadro blanco.
Resultado Visualizar la lista completa de productos.

esperado
Resultado actual Solo se puede visualizar los 12 primeros ítems de la lista

de productos.
Attachments
ID TC-21
Título No existe mensaje de lista vacía cuando no hay nada

registrado.
Descripción Se muestra una parte de la lista pero no indica en ninguna

parte que se muestra así porque la lista está vacía.
Severidad Mayor
Prioridad Alta

reproducir
recuadro blanco.
Resultado Si la lista de productos está vacía, ver el mensaje “no

esperado existen productos registrados”.
Resultado actual Solo se puede visualizar los títulos de las categorías de la

lista de productos.
Attachments
ID TC-108
Título La lista de productos no está ordenada de ninguna

manera.
Descripción La lista no tiene orden cuando se muestra, y debería

mostrarse de manera ordenada por orden alfabético.

Severidad Moderada
Prioridad Media

reproducir
recuadro blanco.
Resultado La lista de productos debe estar ordenada

esperado alfabéticamente.
Resultado actual La lista de productos se muestra de manera desordenada.
Attachments
ID TC-31
Título Al ingresar el nombre del producto con 2 letras me acepta

y lo guarda.
Descripción Cuando llenamos el campo “Nombre de producto” solo con
dos letras , el campo me lo valida y lo guarda en la base
de datos.
Reportado por Kevin Fabrizio Oropeza Andia
Severidad Moderada
Prioridad Media
Precondiciones - Estar dentro de la página web de Product Market.

- Hacer click en “Registrar producto”
Pasos para 1 hacer clic en el botón ver Registrate producto.

reproducir
2 llenar el campo “Nombre del producto” con as .
Resultado Mensaje de error que nos diga que está mal.

esperado
Resultado actual Registro exitoso.

Attachments
ID TC-40
Título Registra el producto con una fecha pasada en la fecha de

vencimiento
Descripción Cuando llenamos el campo “Fecha de vencimiento” solo

con una fecha pasada, el campo me lo valida y lo registra.
Severidad Alta
Prioridad Media


reproducir
2 llenar el campo “Fecha de vencimiento” con 19/10/2022 .
Resultado Mensaje de error que nos diga que está mal.

esperado

Attachments
ID TC-41
Título Registra el producto cuando se pone una fecha de 6

meses posterior a la actual.
Descripción Cuando llenamos el campo “Fecha de vencimiento” con

una fecha de diferencia de 6 meses, el campo me lo valida
y lo guarda en la base de datos.
Severidad Moderada
Prioridad Media


reproducir
2 llenar el campo “Nombre del producto” con as .
Resultado Mensaje de error que nos diga que esta mal.

esperado

Attachments
ID TC-43
Registra productos con un punto, una coma o un guión

Título en el campo “Stock”.
Descripción Al ingresar un punto, una coma o un guión coma en el

campo “Stock”, registra de manera normal.
Reportado por Einar Jarol Chuquimia Arcangel
Severidad Menor
Prioridad Baja

Pasos para 1. Hacer clic en el botón “Registrar producto”.
reproducir
2. Llenar el campo con caracteres especiales o
alfabéticos.
Resultado esperado Que no permite ingresar caracteres especiales o

alfabéticos.
Resultado actual Permite ingresar coma, punto o guión.
Attachments
ID TC-47
Registra productos con menos de 3 caracteres en el

Título campo “Descripción”.
Descripción Al ingresar menos de tres caracteres en el campo

“Descripción”, se registra de forma normal.
Severidad Media
Prioridad Baja

Pasos para 1. Hacer clic en el botón “Registrar producto”.
reproducir
2. Ingresar menos de 3 caracteres en el campo
“Descripción”.
Resultado esperado Que al registrar con menos de 3 caracteres en el campo

“Descripción” me salga un mensaje de error.
Resultado actual Al ingresar 1 carácter en el campo “Descripción” me

permite registrar
Attachments
ID TC-61
Los botones “Editar”, “Registrar producto” y “Ver

Título producto” no son del mismo tipo de letra, tamaño y no
están acomodados simétricamente.
Descripción Al presionar los botones “Editar”, “Registrar producto” y

“Ver producto”, varía el tamaño de estos y se
desacomoda.

Severidad Media
Prioridad Baja

- Hacer click en “Editar”
- Hacer click en “Ver producto”
Pasos para 1. Hacer clic en el botón “Editar”.

reproducir
2. Hacer clic en el botón “Registrar producto”.
3. Hacer clic en el botón “Ver producto”.
Resultado esperado Al cambiar de página en página, los botones

correspondientes sean del mismo tamaño, tengan el
mismo tipo de letra y estén acomodados de acuerdo al
mockup.
Resultado actual Al cambiar de página en página, cambia el tipo de letra y

el tamaño de los botones.
Attachments
ID TC-62
Los formularios no están acomodados simétricamente de

Título acuerdo a su mockup correspondiente.
Descripción Al presionar los botones “Editar”, “Registrar producto” y

“Ver producto”, los formularios no están de acuerdo a su
mockup correspondiente.
Severidad Media
Prioridad Media

- Hacer click en “Editar”
- Hacer click en “Ver producto”
Pasos para 1. Hacer clic en el botón “Editar”.

reproducir
2. Hacer clic en el botón “Registrar producto”.
3. Hacer clic en el botón “Ver producto”.
Resultado esperado Los formularios deben estar acomodados al lado

derecho y respetar la separación de los extremos.
Resultado actual La separación de los extremos del formulario están

distintos a la separación tomada en cuenta en los
mockups.
Attachments
ID TC-66
El campo “Teléfono” acepta caracteres especiales.

Título
Descripción Al llenar el campo “Telefono” se me permite ingresar

caracteres especiales como ser punto y coma, volviendo
este un número de tipo decimal.
Reportado por Fabiana Belen Cespedes Temo
Severidad Mayor
Prioridad Alta
Pasos para 1. Ingresar en el apartado de “Editar”

reproducir 2. Agregar un dato en el campo “Teléfono”
Resultado actual Se puede agregar un punto o coma en el campo, indicando

que los números decimales son posibles
Attachments
ID TC-68
Botón “Cancelar” más pequeño que el botón “Guardar”

Título
Descripción La vista de los botones “Cancelar” y “Guardar” son de

tamaño desproporcionado ya que uno es más grande que
el otro.
Severidad Moderada
Prioridad Baja

reproducir
Resultado actual Se puede ver una diferencia entre los tamaños del botón
“Guardar” con el botón “Cancelar”, ya que el botón
“Guardar” es más grande
Attachments
ID TC-69
El campo “Teléfono” sólo debe aceptar números fijos o de

Título celular de Bolivia.
Descripción Al ingresar números de otros países como ser el caso de

aquellos que inicien con 1 o 5 se me permite hacerlo y
guardarlo en la base de datos.
Severidad Media
Prioridad Alta

reproducir 2. Añadir un número en el campo de “Teléfono”
Resultado actual Se pueden ingresar números que inicien con 5 o 1.
Attachments
ID TC-70
El botón “Guardar” y el botón “Cancelar” se ven

Título parcialmente en la página.
Descripción El botón “Cancelar” y el botón “Guardar” se ven a medias

en la página de “Editar datos del negocio”, imposibilitando
que se sepa cual es cual ya que no puede leerse que hace
cada uno.
Severidad Moderada
Prioridad Baja

reproducir
Resultado actual No puede verse el botón “Guardar” ni el botón “Cancelar”
Attachments
ID TC-75
El campo “Nombre del negocio” acepta más de 30

Título caracteres.
Descripción Al ingresar alrededor de 40 o 50 caracteres se me permite

hacerlo, guardándolo en la base de datos.

Severidad Media
Prioridad Alta

reproducir 2. Agregar un dato en el campo “Nombre del negocio”
Resultado actual Se pueden poner nombres con más de 30 caracteres en el

campo y se guardan, sin dar ningún error.
Attachments
ID TC-78
No se muestra ningún mensaje de éxito al guardar los

Título datos de un negocio exitosamente.
Descripción Al terminar de editar los campos que necesitamos y querer
guardarlos la página solo se pone en blanco por dos
segundos, sin mostrarse un mensaje de si el cambio se
realizó exitosamente.
Severidad Mayor
Prioridad Alta

reproducir 2. Agregar los datos correspondientes en los campos.
3. Hacer click en el botón de “Guardar”
Resultado actual No muestra ningún mensaje de éxito al guardar los datos.
Attachments
ID TC-79
Mostrar un mensaje de error si algo salio mal al guardar
Título los datos.
Descripción Si se hace algo mal o si algo salió mal debe mostrar un

mensaje de error indicando que el proceso se vuelva a
repetir.
Severidad Mayor
Prioridad Alta

reproducir 2. Agregar los datos correspondientes en los campos.
3. Hacer click en el botón de “Guardar”
Resultado actual No muestra ningún mensaje de error.
Attachments
ID TC-80
Los botones “Guardar” y “Editar“ no se puede leer la

Título función que desempeña cada uno.
Descripción Al ingresar al apartado “Editar datos del negocio” no se

puede saber la funcionalidad de cada botón ya que no se
lee que hace cada uno.
Severidad Moderada
Prioridad Media

reproducir
Resultado actual No puede verse que hace cada botón.
Attachments
ID TC-82
Se pueden ingresar caracteres especiales en el campo
Título “Dirección”.
Descripción Se permite ingresar caracteres especiales en el campo

“Dirección” y registrarlos sin validarlos antes.
Severidad Moderada
Prioridad Media

reproducir 2. Agregar un dato en el campo “Dirección”
Resultado actual Se pueden agregar caracteres especiales.
Attachments
ID TC-84
Solo se permite ingresar un horario de atención.

Título
Descripción Al editar datos del negocio solo se permite ingresar un
dato en el horario del negocio, sin especificar a qué horario
se refiere.
Severidad Mayor
Prioridad Alta

reproducir 2. Agregar un dato en el campo “Horario de atención”
Resultado actual Solo te permite agregar un horario.
Attachments
ID TC-85
Se permite ingresar mas de 50 caracteres en el campo

Título “Dirección”.
Descripción Al ingresar mas de 50 caracteres como ser, 60 o 70 se te
permite hacerlo sin verificarlo y registrarlo posteriormente.
Severidad Moderada
Prioridad Alta

reproducir 2. Agregar un dato en el campo “Dirección”
Resultado actual El frontend si me permite agregar más de 50 caracteres,

pero la base de datos no lo permite, mandándome a una
página extra.
Attachments
ID TC-86
El mensaje de error en el campo “Teléfono” es genérico.

Título
Descripción Al ingresar un dato erróneo en el campo “Teléfono” se te

muestra un mensaje genérico que no es acorde al error
presentado en el campo.
Severidad Media
Prioridad Media

reproducir 2. Agregar un dato en el campo “Teléfono”
Resultado actual El mensaje que muestra es que el dato que ingresaste no

puede ser mayor que o menor que.
Attachments
5.2.2 Segundo Test Run
ID TC-108
Título En la tabla “Lista de Productos” no se muestra la columna

de fecha de promoción.
Descripción Al ingresar a la página mediante el botón “Ver productos”,

en la tabla “Lista de Productos” no se muestra la columna
de fecha de promoción.
Severidad Alta
Prioridad Media

- Hacer click en “Ver productos”
Pasos para 1 Hacer clic en el botón Ver productos.
reproducir
2 Revisar la tabla Lista de productos.
Resultado actual En la tabla no se muestra la columna de fecha de

promoción.
Attachments
ID TC-109
Título El precio de descuento es mayor al precio normal
Descripción Al ingresar a la página mediante el botón “Ver productos”,

en la tabla “Lista de productos” el precio de descuento es
mayor al precio normal.
Severidad Alta
Prioridad Media

- Hacer click en “Ver productos”
Pasos para 1 Hacer clic en el botón Ver productos.

reproducir
2 Revisar la tabla Lista de productos.
Resultado actual En la tabla el precio de descuento es mayor al precio

normal.
Attachments
ID TC-111
Título EL botón de Registrar producto cambia de nombre a

“Registrar producto” al presionar lo
Descripción Al ingresar a la página se muestra un botón “Registra

producto” y al presionarlo se cambia a “Registrar
Producto”.
Severidad Alta
Prioridad Media

Pasos para 1 hacer clic en el botón Registrar producto.

reproducir
Resultado actual Cambio de nombre del campo.
Attachments
ID TC-112
Título Al registrar exitosamente no se muestra un mensaje de

exito
Descripción Al momento de ingresar los datos requeridos para registrar

el producto y presionar “Registrar” este se guarda sin
notificar al cliente.
Severidad media
Prioridad Media


reproducir
2 llenar el campo Llenar todos los campos de forma
correcta.
3. Apretar “Ingresar”
Resultado actual hace el registro sin notificar
Attachments
ID TC-113
Título El footer no se encuentra al final de la pagina

Descripción Al ingresar a la pagina el footer no se encuentra en el pie
de la pagina.
Severidad media
Prioridad Media


reproducir
Resultado actual Se cruza el footer.

Attachments
ID TC-114
Título Registra el producto con un precio antes menor que al

precio actual
Descripción Al registrar el producto podemos llenar el precio de antes

con un precio menor al precio que tiene actualmente y lo
podemos registrar de esta manera
Severidad media
Prioridad Media


reproducir
2. Llenar con 4 precio antes
3. llenar con 6 el precio actual
Resultado actual Registro exitoso
Attachments
ID TC-115
Título Registra con los precios con el mismo monto
Descripción Al poner los precios iguales en los campos “Precio antes” y

“Precio ahora”, se registra de forma normal.
Severidad media
Prioridad Media


reproducir
2. poner 4 en precio antes y 4 en precio ahora
3. apretar ingresar
Resultado actual Se registra de forma exitosa.
Attachments
ID TC-116
Título No se puede acceder al sitio, despues de n veces clickear

los botones
Descripción Cuando hacemos click en cualquiera de los 3 botones, n
veces repetidas, nos sale una pagina inaccesible.
Severidad media
Prioridad Media

Pasos para 1 hacer clic en el botón Registrar producto durante n

reproducir veces.
Resultado actual Se muestra la pagina inaccesible.
Attachments
5.3 Reporte de progreso de los test run
5.3.1 Aspectos relevantes
La ejecución de este sprint fue en su mayoría satisfactoria, teniendo una buena

relación con los DEV y también dentro del grupo, practicando la tolerancia,
compañerismo y respeto. Si bien este sprint no fue perfecto, todos aprendimos
mucho de nuestros errores y tratamos de mejorarlos para tener en cuenta en futuros
sprints.
5.3.2. Criterios de salida
5.3.2.1 Primer test run
Porcentaje de cobertura
Del total de test cases que se escribieron para este primer sprint, en el primer test
run se tuvo una cobertura del 100 %, teníamos 106 tests cases, de los cuales 83 se
ejecutaron de forma exitosa.
Definimos un criterio de suspensión del 25 % para todos los test cases que no
fueron pasados, si la Tasa de fallos llega a ser mayor al 25% se detendrán las
pruebas hasta que los desarrolladores corrijan los bugs.
Test Cases exitosos = 83 Test cases Fallidos = 23

Tasa de éxito
La tasa de éxito se define como el número de test cases ejecutados exitosamente

sobre el número de total de test cases, es decir:
Tasa de éxito = (#de test cases exitosos)/(cantidad total de test cases)
Tasa de éxito=83/106
Tasa de éxito= 78,30%
5.3.2.2 Segundo test run
Porcentaje de cobertura
Del total de test cases que se escribieron para este primer sprint, en el segundo test
run se tuvo una cobertura del 100 %, esta vez teníamos 125 tests cases, de los
cuales 117 se ejecutaron de forma exitosa.
Definimos un criterio de suspensión del 25 % para todos los test cases que no
fueron pasados, si la Tasa de fallos llega a ser mayor al 25% se detendrán las
pruebas hasta que los desarrolladores corrijan los bugs.
Test Cases exitosos = 117 Test cases Fallidos = 8
Tasa de éxito
La tasa de éxito se define como el número de test cases ejecutados exitosamente

sobre el número de total de test cases, es decir:
Tasa de éxito = (#de test cases exitosos)/(cantidad total de test cases)
Tasa de éxito=117/125
Tasa de éxito= 93,80%
5.4 Reunión de Retrospective
A continuación se muestra la tabla del retrospective con las observaciones más

importantes hechas por ambos grupos de devs y qas del primer sprint, donde se
analizo las cosas que se hicieron bien, las cosas que se hicieron mal, las cosas por
mejorar, los compromisos por parte de ambos grupos y las cosas que buenas que
se deben mantener para los siguientes sprints.

Informe de Calidad Del Primer Sprint - BUG HUNTER PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe de Calidad Del Primer Sprint - BUG HUNTER PDF

Cargado por

Copyright:

Formatos disponibles

Informe de Calidad

del primer Sprint

Grupo QA: BugHunter

1. Cespedes Temo Fabiana Belen.

1.2 Objetivo de calidad

1.3 Funciones y responsabilidades

2. Metodología y tipos de prueba

2.1 Estrategias de pruebas

2.2 Tipos de prueba

2.3 Análisis y gestión de riesgos

2.4 Clasificación de errores

2.5 Criterios de suspensión y requisitos de reanudación

2.6 Completitud de la prueba

3. Necesidades de recursos y medio ambiente de las pruebas

3.1 Herramientas de prueba

3.2 Entorno de prueba

5.1 Test cases a alto nivel

5.1.1 Test cases a detalle

5.2 Bug report del primer test run

5.2.1 Bug report del segundo test run

5.3 Reporte de progreso de test runs

5.4 Reunión de Retrospective

El contenido de este documento “Test plan” hace parte integral de la metodología de

Dentro este proyecto de desarrollo de software y gestión de calidad, se ha

A continuación se mencionan aquellas historias de usuario que estarán dentro y

Fase del proyecto Historias de usuario Fecha de entrega

-H19: Registra datos del producto

1.1.2 Fuera del alcance

Además de algunas features que se mencionan abajo:

Base de datos Componentes, tablas, lógica, consultas

Seguridad Seguridad de la app

Código Lógica y eficiencia del código.

1.2 Objetivo de calidad

El objetivo de la fase 1 del proyecto es entregar el software “Product Market” con

Se cuenta con un equipo de 12 ingenieros (7 desarrolladores y 5 QA).

1.3 Funciones y responsabilidades

Nombre Rol Responsabilidad

Apaza Choque Víctor Developer Encargados de

Rojas Huallco Luis Miguel Developer

Mamani Flores Vilma Developer

Pelaez Cruz Maria Andrea Developer

Perez Mamani Rodolfo Kevin Developer

Pelaez Cruz Gizela Yohana Scrum Responsable de liderar al

Cespedes Temo Fabiana Belen. QA Tester Responsables de que se

Oropeza Andia Kevin Fabrizio. QA Tester

Valdez Mamani Simón Pedro. QA Tester

Zerain Quinteros Genki Sebastian. QA Tester

Rosemary Torrico Bascope StakeHolder La parte interesada del

El proyecto utiliza la metodología ágil (Scrum), con iteraciones de 3 semanas.

2.1 Estrategias de pruebas

2.2 Tipos de prueba

Las pruebas de aceptación son pruebas formales ejecutadas para verificar si un

Es un tipo de prueba de software que tiene la intención de garantizar que los

Las pruebas funcionales se centran en los requisitos de una aplicación. Solo

Pruebas positivas y negativas

Las pruebas positivas determinan que su aplicación funciona como se esperaba. Si

Las pruebas positivas determinan que su aplicación funciona como se esperaba. Si

Las pruebas integrales replican el comportamiento de un usuario con el software en

2.3 Análisis y gestión de riesgos

Riesgos Impacto Mitigación

Retraso en una fecha de Alto Mantener una

Abandono de un Alto Mantener una

El no seguir lo Medio Pedir a los