PROCESO DE PRUEBAS DE

SOFTWARE

Integrantes:
Bracamonte Gabriela 24.618.141
Guillén José 25.146.767
Montesinos Estefanía 26.458.735
Peña Jesús 26.136.282
Ramos Zaidibeth 26.584.498
Sánchez Rhonald 26.593.945
Sistemas III
Prof.: Ana Mercedes Díaz
 CAJA BLANCA Las técnicas de caja blanca o estructurales, que se basan en un
minucioso examen de los detalles procedimentales del código a
Según Pressman (Ing. Software un enfoque evaluar, por lo que es necesario conocer la lógica del programa..
práctico), es una filosofía de diseño de casos
de prueba que usa la estructura de control
descrita como parte del diseño a nivel de
componentes para derivar casos de prueba. Al
usar los métodos de prueba de caja blanca,
puede derivar casos de prueba que:

1. Garanticen que todas las rutas

independientes dentro de un módulo se
revisaron al menos una vez.

2. Revisen todas las decisiones lógicas en sus

lados verdadero y falso.

3. Ejecuten todos los bucles en sus fronteras y

dentro de sus fronteras operativa.

4. Revisen estructuras de datos internas para

garantizar su validez.
CAJA BLANCA PRUEBAS
CAJA BLANCA

Este método se centra en cómo diseñar los casos

de prueba atendiendo al comportamiento interno
y la estructura del programa.
Se examina así la lógica interna del
programa sin considerar los aspectos de
rendimiento.
El objetivo de la técnica es diseñar casos de
prueba para que se ejecuten, al menos una
vez, todas las sentencias del programa, y/o
todas las condiciones tanto en su vertiente
verdadera como falsa.
CAJA BLANCA
 CAJA BLANCA
Las principales técnicas de diseño de pruebas de caja blanca son:

Pruebas de condición: Es un método de diseño de casos de prueba que revisa las

condiciones lógicas contenidas en un módulo de programa.

Pruebas de flujo de datos: Es un método que selecciona rutas de prueba de un

programa de acuerdo con las ubicaciones de las definiciones y con el uso de variables
en el programa.

Pruebas de bucles (Branch Testing): Como lo dice su titulo, es ligado a una bifurcación o
para bucles. es una técnica de prueba de caja blanca que se enfoca exclusivamente en la
validez de los constructos bucle. Pueden definirse cuatro clases diferentes de bucles
simples, concatenados, anidados y no estructurados .
 CAJA BLANCA
Prueba de camino básico
Esta técnica de prueba de caja blanca fue propuesta por
primera vez por Tom McCabe . El método de ruta básica
permite al diseñador de casos de prueba derivar una medida
de complejidad lógica de un diseño de procedimiento y usar
esta medida como guía para definir un conjunto básico de
rutas de ejecución.
Los casos de prueba derivados para revisar el conjunto
básico tienen garantía para ejecutar todo enunciado en el
programa, al menos una vez durante la prueba.
 Un Grafo de Flujo está formado por 3
componentes fundamentales que ayudan a
CAJA BLANCA su elaboración, comprensión y nos brinda
información para confirmar que el trabajo
se está haciendo adecuadamente.

NODOS REGIONES
ARISTAS
Representan cero, Áreas delimitadas
Líneas que unen
una o varias por aristas y
dos nodos.
sentencias. nodos.

NODO PREDICADO
Cuando en una condición aparecen uno o más
operadores lógicos (AND, OR, XOR,…) se crea un
nodo distinto por cada una de las condiciones
simples.
 CAJA BLANCA
CAMINO
Por ejemplo, un conjunto de caminos
Se puede definir como la ruta de
independientes para el gráfico de flujo que se
secuencias que se siguen dentro
ilustra en la figura es:
del código fuente de un programa
Camino 1: 1-11
Camino 2: 1-2-3-4-5-10-1-11
Camino 3: 1-2-3-6-8-9-10-1-11
CAMINO INDEPENDIENTE Camino 4: 1-2-3-6-7-9-10-1-11
es cualquiera que introduce al menos
un nuevo conjunto de enunciados de
procesamiento o una nueva condición
en el programa.

El conjunto de caminos independientes se obtiene

construyendo el Grafo de Flujo asociado y se calcula
su complejidad ciclomática.
Por último se diseñan los casos de prueba y se
ejecutan los mismos.
 CAJA BLANCA
Complejidad Ciclomatica
Es una medición de software que
proporciona una evaluación cuantitativa
de la complejidad lógica de un Tiene fundamentos en la
teoría de gráficos y
programa proporciona una
medición de software
extremadamente útil.

La complejidad ciclomática La complejidad ciclomática

El número de regiones del
gráfico de flujo corresponde
a la complejidad ciclomática.
V(G) para un gráfico de flujo
G se define como V(G) = E -
N + 2 donde E es el número
de aristas del gráfico de flujo
y N el número de nodos del
gráfico de flujo.
V(G) para un gráfico de flujo
G también se define como
V(G) = P + 1 donde P es el
número de nodos predicado
contenidos en el gráfico de
flujo G.
 CAJA BLANCA
En el gráfico de flujo de la figura, la complejidad
ciclomática puede calcularse usando cada uno de los
algoritmos recién indicados:

1. El gráfico de flujo tiene cuatro regiones.

2. V(G) = 11 aristas - 9 nodos + 2 = 4.
3. V(G) = 3 nodos predicado + 1 = 4.

Por tanto, la complejidad ciclomática del gráfico de

flujo en la figura es 4.

Esta técnica ofrece una gran ventaja con respecto a las otras técnicas, ya que el número mínimo requerido de
pruebas se sabe por adelantado y por tanto el proceso de prueba se puede planear y supervisar en mayor
detalle. Los pasos a seguir para aplicar esta técnica son:
1. Representar el programa en un grafo de flujo.
2. Calcular la complejidad ciclomática.
3. Determinar el conjunto básico de caminos independientes.
4. Derivar los casos de prueba que fuerzan la ejecución de cada camino.
 Ejemplo extraído del libro Ing.Software un Enfoque Practico
(7ma Edición) de R.Pressman.
CAJA BLANCA
 1. Determine la complejidad ciclomática del gráfico de flujo resultante.
La complejidad ciclomática V(G) se determina al aplicar los algoritmos
expuestos anteriormente (Para el procedimiento average, las condiciones

CAJA BLANCA compuestas son dos) y sumar 1.

V(G) = 6 regiones
V(G) = 17 aristas - 13 nodos + 2 = 6
V(G) = 5 nodos predicado + 1 = 6

2. Determine un conjunto básico de rutas linealmente independientes.

El valor de V(G) proporciona la cota superior sobre el número de rutas
linealmente independientes a través de la estructura de control del
programa. En el caso del procedimiento average, se espera especificar seis
rutas:
• ruta 1: 1-2-10-11-13
• ruta 2: 1-2-10-12-13
• ruta 3: 1-2-3-10-11-13
• ruta 4: 1-2-3-4-5-8-9-2-...
• ruta 5: 1-2-3-4-5-6-8-9-2-...
• ruta 6: 1-2-3-4-5-6-7-8-9-2-...

Prepare casos de prueba que fuercen la ejecución de cada ruta en el

conjunto básico.
Los datos deben elegirse de modo que las condiciones en los nodos
predicado se establezcan de manera adecuada conforme se prueba cada
ruta. Cada caso de prueba se ejecuta y compara con los resultados
esperados. Una vez completados todos los casos de prueba, el
examinador puede estar seguro de que todos los enunciados del
programa se ejecutaron al menos una vez.
CAJA BLANCA
HERRAMIENTAS AUTOMÁTICAS PARA TÉCNICAS DE CAJA BLANCA
CAJA BLANCA

EJERCICIO PROPUESTO
«Caja Blanca»
CAJA BLANCA
CAJA BLANCA
 El método de la caja negra es cualquier proceso o mecanismo cuya forma
de actuar no es comprendida, ni accesible al usuario.
CAJA NEGRA Ingen
iería d
e
Se denomina Caja Negra a enfoq l Sofware
ue prá un
aquel elemento que es ctico
estudiado desde el punto de
vista de las entradas que recibe
y las salidas o respuestas que
Selenium-
produce, sin tener en cuenta su Jmeter-Te
Aplicacion stlink
funcionamiento interno. es web pa
realizar ca ra
sos de pru
eba
A diferencia de los procesos de las
pruebas de caja blanca, que se Inputs (recursos), esto es de lo que
realizan tempranamente en el disponemos.
proceso de pruebas, la prueba de
La caja negra - este es el lugar donde
caja negra tiene a aplicarse durante ocurre lo más complicado o misterioso,
las últimas etapas de la prueba. Ya pero no tenemos ningún interés en
que no considera la estructura de averiguar cómo funciona.
control, la atención se enfoca en el
dominio de la información según Outputs (las metas que queremos), este es
establece Pressman en su libro. nuestro resultado.
CAJA NEGRA
Ejemplos típicos

La Pruebas de
comprobación integración de la
de valores límite base de datos

Pruebas de Pruebas de
situaciones de rendimiento del
excepción sistema
CAJA NEGRA
Errores típicos

Funciones
incorrectas o Errores de interfaz
ausentes

Errores de
Errores de
estructura de
rendimiento y
datos o en accesos
errores de
de base de datos
inicialización
externas
CAJA NEGRA Partición de
equivalencia.

Pruebas de
Análisis de
historias de
valores borde.
usuarios.

Técnicas de
prueba de
Técnicas caja negra Tablas de
combinatorias
decisión.
.

Pruebas de Transición Depar

ta
casos de uso. entre estados. inform mento de
Unive áti
rsidad ca de la
de Va
lladol
id
CAJA NEGRA PARTICIÓN DE
EQUIVALENCIAS
Se basa en la división
del campo de entrada
en un conjunto de clases
Dichas clases se
de datos denominadas
refieren a un conjunto
clases de equivalencia.
de datos de entrada
que definen estados
válidos y no válidos del
sistema. Estas clases se obtienen a
Clase Valida: partir de las condiciones
Genera un Valor Clase no Válida: de entrada descritas en
esperado Genera un valor los documentos
inesperado. pertinentes.
CAJA NEGRA
Las clases de equivalencia se pueden definir
de acuerdo con los siguientes criterios:

Si un parámetro de entrada
Si una entrada requiere un
debe estar comprendido en
valor que este en un conjunto,
un cierto rango, aparecen 3
aparecen 2 clases de
clases de equivalencia: por
equivalencia: en el conjunto o
debajo del rango, dentro del
fuera de él.
rango y por encima del rango.

Si una entrada requiere de un

Si una entrada es booleana, valor específico, aparecen 3
hay 2 clases de equivalencia: clases de equivalencia: por
true o false debajo del valor, dicho valor y
por encima del valor.
CAJA NEGRA
EJEMPLO DE PARTICIÓN DE EQUIVALENCIA
Descripción del caso
Se tiene un campo de texto que solo acepta caracteres
alfabéticos. La longitud del valor ingresado debe estar entre 6 y 10
caracteres.
Identificación de las clases de equivalencia
Se pueden establecer tres particiones:
• Longitudes entre 0 y 5 caracteres (partición inválida, código: Pi1)
• Longitudes entre 6 y 10 caracteres (partición válida, código: Pv)
• Longitudes mayores a 10 caracteres (partición inválida, código: Pi2).
Además, el ingreso de caracteres no alfabéticos (por ejemplo un número),
se considera también dato inválido, con su código: pi3.
CAJA NEGRA
Obtención de los casos de prueba

• Caso 1. Datos de entrada: cadena de 2 caracteres. Resultado (Salida): La

aplicación no permite el ingreso del dato y muestra un mensaje de error
con la debida explicación.
• Caso 2. Datos de entrada: cadena de 7 caracteres, incluyendo uno o más
caracteres no alfabéticos. Resultado (Salida): La aplicación no permite el
ingreso del dato y muestra un mensaje de error con la debida explicación.
• Caso 3. Datos de entrada: cadena de 7 caracteres, solo de caracteres
alfabéticos. Resultado (Salida): La aplicación permite el ingreso del dato
(mensaje de éxito).
• Caso 4. Datos de entrada: cadena de 15 caracteres. Resultado (Salida): La
aplicación no permite el ingreso del dato y muestra un mensaje de error
con la debida explicación.
CAJA
CAJA NEGRA
NEGRA
ANÁLISIS DE VALORES BORDE

Parte del principio que el comportamiento al borde de una partición de datos tiene
mayores probabilidades de presentar errores (Bugs). Esta técnica aplica tanto para
valores validos como no validos. Al incluirlas en el diseño de casos de prueba, se
define una prueba por cada valor borde.

La capacidad de identificar defectos de esta técnica es alta ya

que usualmente las condiciones de error se suelen presentar
en estos valores borde, muchas veces relacionado con el
manejo inadecuado en programación de restricciones de tipo
mayor o menor estricto.
CAJA NEGRA
EJEMPLO DE ANALISIS DE VALORES BORDE
Descripción del caso
Se tiene un campo de texto que solo acepta caracteres
alfabéticos. La longitud del valor ingresado debe estar entre 6 y 10
caracteres. CAJA NEGRA

Tomando en consideración la técnica anterior con sus casos,

podemos definir casos de prueba adicionales si tomamos los
valores borde, es decir, dado que la aplicación acepta entre 6 y 10
caracteres, los valores borde consistirían en ingresar cadenas de
caracteres con estas longitudes ya que, como se dijo
anteriormente, las condiciones de error se suelen presentar en
estos valores borde.
CAJA NEGRA

Los otros casos adicionales que se pueden presentar con esta técnica son:
• Caso 5. Datos de entrada: cadena de 6 caracteres, sólo caracteres alfabéticos.
Resultado (Salida): La aplicación permite el ingreso del dato (mensaje de
éxito).
• Caso 6. Datos de entrada: cadena de 10 caracteres, sólo caracteres
alfabéticos. Resultado (Salida): La aplicación permite el ingreso del dato
(mensaje de éxito).
• Caso 7. Datos de entrada: cadena de 6 caracteres, con caracteres no
alfabéticos. Resultado (Salida): La aplicación no permite el ingreso del dato y
muestra un mensaje de error con la debida explicación.
• Caso 8. Datos de entrada: cadena de 10 caracteres, con caracteres no
alfabéticos. Resultado (Salida): La aplicación no permite el ingreso del dato y
muestra un mensaje de error con su debida explicación.
CAJA NEGRA

• Caso 9. Datos de entrada: cadena de 5 caracteres, sólo caracteres

alfabéticos. Resultado (Salida): La aplicación no permite el ingreso
del dato y muestra un mensaje de error con la debida explicación.

• Caso 10. Datos de entrada: cadena de 11 caracteres, sólo

alfabéticos. Resultado (Salida): La aplicación no permite el ingreso
del dato y muestra un mensaje de error con su debida explicación.
CAJA NEGRA Según PMBOK (Versión 6, 2017). Las entradas y salidas del
proceso de caja negra son:

ENTRADAS
1. Documentos del proyecto:
• Registro de supuestos: posee restricciones que afectan al proyecto.
• Lista de hitos: muestra las fechas programadas de hitos específicos y se utiliza para
verificar si los hitos planificados se han cumplido. Los hitos son sinónimos de retos.
• Informes de calidad: incluye incidentes relacionados con la gestión de la calidad;
recomendaciones para mejoras en los procesos, proyectos y productos;
recomendaciones de acciones correctivas y el resumen de las conclusiones del proceso
llamado Controlar la Calidad.
• Informes de riesgos: proporciona información sobre los riesgos generales del proyecto,
así como información sobre riesgos individuales específicos.

2. Información de desempeño del trabajo:

Los datos de desempeño del trabajo se recopilan en la ejecución y se pasan a los
procesos de control. Para transformarse en información de desempeño, los datos se
comparan con los componentes del plan para la dirección del proyecto, los documentos del
proyecto y otras variables del proyecto.
CAJA NEGRA

SALIDAS
1. Informes de desempeño del trabajo:
Entre los ejemplos de informes de desempeño del trabajo se pueden citar los informes de estado y
los informes de avance. Los informes de desempeño del trabajo pueden contener gráficos e
información sobre el valor ganado, líneas de tendencia y pronósticos, gráficas de consumo de reservas,
histogramas de defectos, información sobre la ejecución de los contratos y resúmenes de riesgos.
Pueden presentarse como tableros, informes de calor (“heat reports”), cuadros de mandos tipo
semáforo u otras representaciones útiles.

2. Solicitudes de cambio:
Como consecuencia de la comparación entre los resultados planificados y los reales, pueden emitirse
solicitudes de cambio para ampliar, ajustar o reducir el alcance del proyecto, del producto o de los
requisitos de calidad y las líneas base del cronograma o de costos. Las solicitudes de cambio pueden
requerir la recopilación y documentación de nuevos requisitos. Los cambios pueden impactar el plan
para la dirección del proyecto, los documentos del proyecto o los entregables del producto. Las
solicitudes de cambio se procesan para su revisión y tratamiento por medio del proceso llamado
Realizar el Control Integrado de Cambios.
CAJA NEGRA SALIDAS

Pronósticos
de costos.

Pronósticos
Registro de
del
incidentes.
cronograma. Actualizaciones
en los
documentos del
proyecto

Registro de
Registro de
lecciones
riesgos
aprendidas.
DISEÑO DEL PLAN Consiste en identificar los casos de pruebas a ser
aplicados en el software.
DE PRUEBAS
FORMULARIO DE DISEÑO DE CASO DE PRUEBA DE SISTEMAS
Prueba Nro (Id):
Sistema:
Módulo del Sistema:
Fecha de la Prueba:
Estrategia de Prueba: Sistemas
Método de prueba: ( ) Seguridad ( ) Rendimiento
( ) Resistencia
( ) Recuperación ( ) Validación

Requerimientos del ambiente de

prueba:
Procedimientos especiales
requeridos:
Dependencias con otros casos de
prueba (listar):
Responsable de la Prueba:
Errores obtenidos
Responsable de la depuración:

Fecha estimada de entrega:

DISEÑO DEL PLAN
DE PRUEBAS
CASOS DE PRUEBA

Nro. Variables Valores de Respuesta esperada Resultado

entrada del sistema obtenido
1
2
3
4
…
…

N
r
Condiciones a ser aplicadas Respuesta esperada del Resultado obtenido
o al sistema sistema
.
1
2
3
DISEÑO DEL PLAN
DE PRUEBAS
FORMULARIO DE DISEÑO DE CASO DE PRUEBA DE CAJA NEGRA

Sistema: Prueba Nro (Id):

Módulo del Fecha de la

Sistema: Prueba

Formulario: Técnica de Caja negra

Prueba:
Nombre del Método de ( ) Partición
Campo o atributo: prueba: equivalente
( ) Valor de
frontera
Rango de valores Responsable de
del campo o la prueba:
atributo:
DISEÑO DEL PLAN
DE PRUEBAS
FORMULARIO DE DISEÑO DE CASO DE PRUEBA DE CAJA BLANCA
Sistema: Prueba Nro (Id):
Módulo: Fecha de Prueba:
Formulario Técnica de Caja Blanca
/Procedimiento: Prueba:
Método de Camino básico
prueba:
Errores Obtenidos
Responsable de Fecha estimada
la depuración: de entrega:

Nro de
Regiones Nodos Complejidad
Nodos Aristas caminos
cerradas Predicados ciclomática
básicos
PRUEBAS DEL Las pruebas de software representan el porcentaje más
grande de esfuerzo técnico en el proceso de software.
SISTEMA
Las pruebas de sistema implican integrar diferentes
componentes y, después, probar el sistema integrado que se
creó. Siempre hay que usar un enfoque incremental para la
integración y las pruebas (es decir, se debe incluir un
componente, probar el sistema, integrar otro componente,
probar de nuevo y así sucesivamente). Esto significa que, si
ocurren problemas, quizá se deban a interacciones con el
componente que se integró más recientemente.

Se debe comprobar que:

• Se cumplen los requisitos funcionales establecidos
• El funcionamiento y rendimiento de las interfaces hardware,
sofware y de usuario.
• La educación de la documentación de usuario
• Rendimiento y respuesta en condiciones limite y de sobre carga.
 ENTORNO AUTOMATIZADO DE PRUEBAS
PRUEBAS DEL
SISTEMA

EL DESARROLLO DIRIGIDO DE PRUBAS (TDD)

 Las pruebas de integración son una técnica
sistemática para construir la arquitectura
PRUEBAS DE del software mientras se llevan a cabo
pruebas para descubrir errores asociados
INTEGRACIÓN con la interfaz.

El objetivo es tomar los componentes probados de manera

individual y construir una estructura de programa que se
haya dictado por diseño

Integración descendente: Los módulos se integran al

moverse hacia abajo a través de la jerarquía de
control, comenzando con el módulo de control
principal. Los módulos subordinados al módulo de
control principal se incorporan en la estructura en una
forma de primero en profundidad o primero en
anchura.
Integración ascendente: Puesto que los componentes
se integran de abajo hacia arriba, la funcionalidad que
proporcionan los componentes subordinados en
determinado nivel siempre está disponible y se
elimina la necesidad de representantes .
PRUEBAS DE Integración
INTEGRACIÓN
descendiente
PRUEBAS DE Integración
INTEGRACIÓN
ascendiente
PRUEBAS DE
ACEPTACIÓN

Base para definir las pruebas de aceptación de

software
Según los estándares establecidos por el ISTQB, las pruebas de
aceptación de software son diseñadas a partir de:
 Requerimientos de usuario
 Requerimientos de sistema.
 Casos de uso
 Procesos de negocio.
 Reportes de análisis de riesgo.
PRUEBAS DE PLAN DE PRUEBAS
ACEPTACIÓN

• Título
• ¿El título coincide con el título del proyecto como se menciona en todas partes?

El título sigue las convenciones de nomenclatura del proyecto

• Historial de revisiones, tabla de contenidos

• ¿Se realizó un seguimiento adecuado de todas las modificaciones de versión para el plan?

Se han revisado correctamente todos los cambios de versión y se menciona

PRUEBAS DE
ACEPTACIÓN

• Referencias
• ¿Son las referencias existentes y válidas?

¿Coinciden con el alcance?

¿Están completas y consideradas para la identificación de las pruebas?

• Elementos de prueba, Características a probar, Características a no probar
• ¿Están numerados?

¿Cada característica / módulo / submódulo se incluye dentro del alcance?

¿El programa previsto puede cubrir todos los elementos de prueba identificados dentro de
PRUEBAS DE
ACEPTACIÓN

• Criterios de entrada, criterios de salida

• ¿Están numerados?

¿Todos y cada uno de los criterios mencionados en detalle?

• Detalles del entorno de prueba

• ¿Se mencionan todas las configuraciones requeridas?

¿Es la versión de cada configuración específica o la última en ser considerada?

¿Las máquinas virtuales? Existe el entorno (si no es así, mencione la fecha posible para su
disponibilidad)

¿Se menciona el método de intercambio de credenciales para el acceso particular al entorno?

PRUEBAS DE
ACEPTACIÓN

• Prueba de aceptación
• ¿ Están numeradas las pruebas? ¿Están numeradas las condiciones previas?

¿Se deben entender los pasos de la prueba?

• Recursos, roles y responsabilidades
• ¿Las responsabilidades de cada rol están numeradas?

¿Se pueden cumplir las responsabilidades?

¿El recurso identificado es capaz de manejar las responsabilidades mencionadas?

PRUEBAS DE
ACEPTACIÓN

• Herramientas
• ¿ Se mencionan todas las herramientas?

¿Se numeran todas las herramientas?

• Factores de decisión de negocios
• ¿Todos los factores mencionados son todos los factores numerados?
• Procedimiento de Aprobación
• ¿ Es válido el procedimiento?

¿Es aceptable el procedimiento? ¿Es claro para entender el procedimiento?

• Punto de contacto
• ¿El recurso identificado como punto de contacto disponible en la organización
durante la fase?

¿El recurso identificado es capaz de manejar la fase?

 Según los estándares establecidos por el ISTQB, las pruebas de aceptación
de software son diseñadas a partir de:
PRUEBAS DE
ACEPTACIÓN  Requerimientos de usuario
 Requerimientos de sistema.
 Casos de uso
 Procesos de negocio.
 Reportes de análisis de riesgo.
CASOS DE PRUEBA
Caso 1: Manejo de cuenta de usuario
Prueba 1: registro / registro / creación de cuenta, verifique si un usuario puede:
Crea la cuenta.
Activar la cuenta.
Active la cuenta solo una vez (en este caso, el enlace de activación se debe probar para
el 2º.Aunque este es un resultado negativo, es uno de los principales puntos de verificación
a considerar).
Prueba 2: Para acceder y ver la información de la cuenta, verifique si un usuario puede:
Inicia sesión en la cuenta.
Ver diferentes secciones en el Perfil (si la sección de Perfil está categorizada, entonces
todas y cada una de las categorías deberían ser visibles).
Verifique que los datos mostrados en el Perfil sean correctos según la entrada del usuario.
PRUEBAS DE
ACEPTACIÓN

Caso 2: Compra de producto

Prueba 1: Detalles del producto, verifique si un usuario puede:
Ver la página de detalles del producto.
Vea todas las subsecciones en la página de detalles del producto
(Descripción, Característica, Información de marca, etc.).
Seleccione la cantidad del producto, color, tamaño, etc., según esté
disponible en la página de detalles del producto.
Prueba 2: agregar al carrito, verificar si un usuario es:
Capaz de agregar el producto al carrito:
A través de la página de detalles del producto.
A través de la página de lista de productos.
Capaz de agregar la cantidad requerida al carrito (1 a límite máximo
establecido).
No se puede agregar el producto al carrito si no hay stock.