Testing Refresh

TÉRMINOS
________________________________________________________

Asegúrese de conocer las siguientes definiciones del glosario:

• bug, defecto, error, fallo, equivocación (mistake), calidad, riesgo,
software, pruebas y pruebas exhaustivas.
• código, debugging, requerimiento, desarrollo de software, revisión, bases
de pruebas, caso de pruebas, pruebas y objetivos de pruebas.
• Pruebas de confirmación, criterios de salida, incidente, pruebas de
regresión, condición de pruebas, cobertura de pruebas, data de pruebas,
ejecución de pruebas, log de pruebas, plan de pruebas, estrategia de
pruebas, reporte resumen de pruebas y testware.
¿POR QUÉ ES
NECESARIO PROBAR?
¿POR QUE ES NECESARIO PROBAR?
________________________________________________
¿QUÉ ES UN “BUG"?

• Error: Acción humana que produce un resultado incorrecto.

[Según IEEE 610]
• Defecto: Una manifestación de un error en el software.
• También conocido como bug.
• Si se ejecuta, un defecto puede causar un fallo.
• Fallo: Desviación del componente o del sistema respecto de
prestación, servicio o resultado esperado.

El fallo es un evento, el defecto es un estado del software,

causado por un error
¿POR QUÉ ES NECESARIO PROBAR?
¿POR QUÉ ES NECESARIO PROBAR?
_______________________________________________________________
PRUEBAS EXHAUSTIVAS

• ¿Cuándo es una prueba exhaustiva?

• Cuando todos los probadores están exhaustos
• Cuando todas las pruebas planificadas se han ejecutado
• Cuando se han realizados pruebas de todas las combinaciones
de entradas y precondiciones

• ¿Cuánto tiempo va a tomar una prueba exhaustiva?

• Tiempo infinito
• No mucho tiempo
• Cantidad de tiempo poco práctica
¿POR QUÉ ES NECESARIO PROBAR?
________________________________________________________________
¿CON CUÁNTAS PRUEBAS ES SUFICIENTE?

• Nunca es suficiente
• Cuando se hizo lo planificado
• Cuando el cliente/usuario es feliz
• Cuando se ha demostrado que el sistema funciona correctamente
• Cuando se tiene la certeza objetiva de que el sistema funciona
correctamente
• Depende de los riesgos del sistema
¿POR QUÉ ES NECESARIO PROBAR?
_______________________________________________________________

¿CUÁNTAS PRUEBAS REALIZAR?

• Depende del RIESGO.

• Riesgo de no identificar fallas importantes.
• Riesgo de incurrir en costos de fallas.
• Riesgo de liberar el software sin pruebas o con pruebas insuficientes.
• Riesgo de perder la credibilidad y la participación en el mercado.
• Riesgo de perder una ventana de mercado.
• Riesgo de un exceso de pruebas, pruebas ineficaces.
¿POR QUÉ ES NECESARIO PROBAR?
________________________________________________________
TAN POCO TIEMPO, TANTO POR PROBAR

• El tiempo asignado a las pruebas siempre será limitado

• Utilizar el RIESGO para determinar:
• ¿Qué vamos a probar primero?
• ¿Qué vamos a probar más?
• ¿Qué tan exhaustivamente vamos a probar cada elemento?
• ¿Qué NO vamos a probar (esta vez)?

• Usamos el RIESGO para

• Asignar el tiempo disponible para las pruebas, según la prioridad para
probar…
¿QUÉ ES PROBAR?
¿QUÉ ES PROBAR?

Proceso que está presente en todas las actividades del ciclo de vida del
software, tanto estáticas como dinámicas, concernientes
con la planificación
y evaluación
de productos de software y los productos de trabajo relacionados
para determinar que éstos satisfacen los requisitos especificados,
para demostrar que se ajustan al propósito
y para detectar defectos.
LOS SIETE PRINCIPIOS DE
LAS PRUEBAS
 LOS SIETE PRINCIPIOS DE LAS PRUEBAS

1. Las pruebas muestran la presencia de defectos, no su ausencia.

2. Las pruebas exhaustivas son imposibles.

3. Las pruebas tempranas ahorran tiempo y dinero.

4. Agrupación de defectos.

5. Cuidado con la paradoja del pesticida.

6. Las pruebas dependen del contexto.

7. La falacia de ausencia de errores.

PRINCIPIOS DE LAS PRUEBAS
____________________________________________________________________________
PRINCIPIO 1: LAS PRUEBAS DEMUESTUESTRAN LA PRESENCIA DE DEFECTOS

• Las pruebas muestran que los defectos están presentes, pero no pueden
comprobar su ausencia.
• Las pruebas reducen la probabilidad de la presencia de defectos no
descubiertos pero eso no demuestra su ausencia, incluso cuando no se
encontraron defectos durante las pruebas.
• La ausencia de fallos no demuestra que un producto de software es
correcto.
• El mismo proceso de pruebas puede contener errores.
• La condiciones de las pruebas pueden ser inapropiadas para detectar
errores.
PRINCIPIOS DE LAS PRUEBAS
_____________________________________________________________
PRINCIPIO 2: LAS PRUEBAS EXHAUSTIVAS SON IMPOSIBLES

• Probar todo (todas las combinaciones de entrada y precondiciones) no es factible,

excepto para casos triviales. En lugar de pruebas exhaustivas, se utilizan técnicas
basadas en riesgos y prioridades para orientar el esfuerzo de las pruebas.
• Pruebas exhaustivas
• Enfoque del proceso de pruebas en el cual el juego de pruebas abarca todas
las combinaciones de valores de entrada y precondiciones.
• «Test case explosion»
• El incremento exponencial del esfuerzo y costos para la aplicación de pruebas
exhaustivas.
• Pruebas por muestreo
• La prueba incluye solamente a un subconjunto (generado de forma
sistemática o aleatoria) de todos los posibles valores de entrada.
• En condiciones normales, se utilizan generalmente muestras para probar.
Probar todas las combinaciones posibles de entradas y precondiciones sólo
es económicamente viable en casos triviales.
PRINCIPIOS DE LAS PRUEBAS
_______________________________________________________________
PRINCIPIO 3: PROBAR LO MÁS TEMPRANAMENTE POSIBLE

• Las actividades de pruebas deben comenzar tan pronto como sea posible en el ciclo
de vida del desarrollo del software o sistema y deben ser orientados sobre objetivos
definidos.
• La corrección de un defecto es menos costosa en la medida en que su detección se
realice en fases tempranas del proceso software.
• Se obtiene una máxima rentabilidad cuando los errores son corregidos antes de la
implementación.
• Los conceptos y especificaciones pueden ser probados.
• Los defectos detectados en la fases iniciales son corregidos con menor esfuerzo y
costos.
• La preparación de una prueba también consume tiempo.
• El proceso de pruebas implica más que sólo la ejecución de pruebas.
• Las actividades de pruebas pueden ser preparadas antes de que el desarrollo se haya
completado.
• Las actividades de pruebas (incluidas las revisiones) deben ser ejecutadas en
paralelo a la fase de requerimientos y diseño software.
PRINCIPIOS DE LAS PRUEBAS
_______________________________________________________________
PRINCIPIO 3: PROBAR LO MÁS TEMPRANAMENTE POSIBLE
Requerimiento 1
Entrega de atributos
Requerimiento Diseño acorde con Desarrollo acorde El producto trabaja funcionales y no
correcto los requerimientos con el Diseño según lo esperado funcionales correctos

Requerimiento 2

Requerimiento Diseño acorde con Error en el El producto

los requerimientos Defecto corregible
correcto desarrollo contiene bugs

Requerimiento 3
El producto
Requerimiento Error en el Desarrollo Rediseñar para
contiene
acorde con
correcto Diseño defectos en corregir los defectos
el Diseño
el diseño

Requerimiento 4
Diseño acorde Desarrollo Entrega del Los defectos pueden
Error en el
requerimiento
con los acorde con el producto estar ocultos al
requerimientos Diseño equivocado
equipo de desarrollo
PRINCIPIO DE LAS PRUEBAS
_________________________________________________________________
PRINCIPIO 3: PROBAR LO MÁS TEMPRANAMENTE POSIBLE

PRUEBAS PRUEBAS PRUEBAS PRUEBAS

Requisitos A&D Desarrollo Pruebas

Despliegue
A mayor tiempo, mayor
costo
PRINCIPIOS DE LAS PRUEBAS
_______________________________________________________________
PRINCIPIO 4: AGRUPAMIENTO DE DEFECTOS

• Un número pequeño de módulos contienen la mayoría de los defectos

descubiertos durante la prueba, o muestran la mayoría de los fallos
operacionales.
• ¡Encuentre un defecto y encontrará más defectos "cerca"!
• Los defectos aparecen agrupados.
• Cuando se detecta un defecto es conveniente investigar el mismo módulo
en el que ha sido detectado.
• Los probadores (testers) deben ser flexibles.
• Habiendo sido detectado un defecto es conveniente volver a considerar el
rumbo de las pruebas siguientes.
• La identificación de un defecto puede ser investigada con un mayor grado
de detalle, por ejemplo, realizando pruebas adicionales o modificando
pruebas existentes.
PRINCIPIOS DE LAS PRUEBAS
_______________________________________________________________
PRINCIPIO 5: LA PARADOJA DEL PESTICIDA

• Si el mismo test se repite una y otra vez, eventualmente el mismo grupo de casos de
prueba ya no encontrará nuevos errores. Para vencer esta “paradoja del pesticida”,
los casos de prueba necesitan ser regularmente revisados y estudiados, y se
necesitan escribir nuevos casos de prueba para ejercitar diferentes partes del
software o sistema para encontrar mas defectos potenciales.
• Repetir pruebas en las mismas condiciones no es efectivo.
• Cada caso de prueba debe contar con una combinación única de parámetros de
entrada para un objeto de pruebas particular, de lo contrario no se podrá obtener
información adicional.
• Si se ejecutan las mismas pruebas de forma reiterada no se podrán encontrar nuevos
defectos.
• Las pruebas deben ser revisadas/modificadas regularmente para los distintos
módulos(código).
• Es necesario repetir una prueba tras una modificación del código (corrección de
defectos, nueva funcionalidad).
• La automatización de pruebas puede resultar conveniente si un conjunto de casos de
prueba se deben ejecutar frecuentemente.
PRINCIPIOS DE LAS PRUEBAS
_______________________________________________________________
PRINCIPIO 6: LA PRUEBA DEPENDE DEL CONTEXTO

• La prueba se realiza de manera diferente en diferentes contextos. Por ejemplo, el

software de seguridad crítico se prueba de forma diferente a la de un sitio de
comercio electrónico.

• Objetos de prueba diferentes son probados de forma diferente.

• El firmware del motor de un coche requiere pruebas diferentes respecto de aquellas
definidas para una aplicación de e-commerce.
• Entorno de pruebas vs. entorno de producción.
• Las pruebas tienen lugar en un entorno distinto del entorno de producción. El
entorno de pruebas debe ser similar entorno de producción.
• Siempre habrá diferencias entre el entorno de pruebas y el entorno de producción.
Estas diferencias introducen incertidumbre con respecto a las conclusiones que se
pudieran obtener luego de las pruebas.
PRINCIPIOS DE LAS PRUEBAS
_______________________________________________________________
PRINCIPIO 7: LA FALACIA DE LA AUSENCIA DE ERRORES

• Encontrar y reparar defectos no permite prevenir que el sistema construido no

satisfaga las necesidades y expectativas de los usuarios.

• Un proceso de pruebas adecuado detectará los fallos más importantes.

• En la mayoría de los casos el proceso de pruebas no encontrará todos los defectos
del sistema (ver Principio 2), pero los defectos más importantes deberían ser
detectados.
• Esto en sí no prueba la calidad del sistema software.
• La funcionalidad del software puede no satisfacer las necesidades y expectativas de
los usuarios.
• No se puede introducir la calidad a través de las pruebas, ella tiene que construirse
desde el principio.
PROCESO DE PRUEBAS
PROCESO DE PRUEBAS FUNDAMENTAL
_______________________________________________________________
PLANIFICACIÓN, MONITOREO Y CONTROL

Monitoreo y Control

Análisis y Diseño
Planificación

Implementación y
Ejecución

Evaluación de Criterios de
Salida y Reporting

Cierre
MODELOS DE
DESARROLLO DE
SOFTWARE

• Modelo Cascada
• Modelo V
• Modelo Iterativo
 MODELOS DE DESARROLLO DE SOFTWARE
______________________________________________________________________

MODELO CASCADA
El modelo de cascada fue uno de los primeros modelos que se
Necesidad,
Deseo, Política,
diseñó. Tiene una línea de tiempo natural, donde las tareas se
Ley ejecutan de manera secuencial
DEFICIENCIAS:
Requerimientos de - Los detectos se descubrían en etapas
Usuario muy avanzadas del proyecto (mayor
costo).
Requerimiento de
Sistemas
- Es un modelo muy lineal y en
consecuencia no puede soportar
Diseño Global muchas iteraciones (cambios o
variaciones en el ciclo de vida).
Diseño Detallado

Implementación

Prueba
MODELOS DE DESARROLLO DE SOFTWARE
______________________________________________________________________

MODELO V (V-MODEL)

• El modelo V se desarrolló para abordar algunos de los problemas

experimentados utilizando el método de cascada tradicional.
• El modelo V es un modelo que ilustra cómo las actividades de las pruebas
(verificación y validación) pueden ser integrados en cada fase del ciclo de
vida. Dentro de el modelo V, las pruebas de validación se lleva a cabo
especialmente durante los primeros etapas, por ejemplo revisar los
requisitos del usuario, y al final del ciclo de vida, por ejemplo, durante las
pruebas de aceptación del usuario.

Realizar las actividades de pruebas en paralelo con las actividades de

desarrollo del software. (trabajo en conjunto)

Realizar pruebas tan pronto como sea posible en el ciclo de vida.

MODELOS DE DESARROLLO DE SOFTWARE
______________________________________________________________________

MODELO V

• Los niveles de prueba utilizados son los siguientes:

• Pruebas de componentes: busca defectos y verifica el funcionamiento de los
componentes de software (por ejemplo, módulos, programas, objetos, clases, etc.).
Cada componente es probado por separado.
• Pruebas de integración de componentes: pruebas de interfaces e interacciones
entre los componentes construidos y probados en el nivel de pruebas de
componentes.
• Pruebas del sistema: que se trata del comportamiento de todo el sistema/producto
definido por el alcance de un proyecto. El objetivo principal de las pruebas del
sistema es la verificación de los requerimientos especificados.
• Pruebas de integración de sistemas: pruebas de interfaces e interacciones entre
diferentes sistemas.
• Pruebas de aceptación: las pruebas de validación con respecto a las necesidades del
usuario, requerimientos y procesos empresariales, para determinar si se procede o
no a aceptar el sistema.
 MODELOS DE DESARROLLO DE SOFTWARE
______________________________________________________________________

MODELO V: NIVELES DE PRUEBA

Requerimientos
Pruebas de Aceptación
de Negocio

Especificación Pruebas de Integración

Del Proyecto de Sistemas

Especificación
Pruebas de Sistemas
Del Sistema

Especificación de Pruebas de Integración

Diseño de Componentes

Código Pruebas de Componentes

 MODELOS DE DESARROLLO DE SOFTWARE
______________________________________________________________________

MODELO V: NIVELES DE PRUEBA FINAL

Prueba
Requerimientos
Pruebas de Aceptación
de Negocio

Prueba
Especificación Pruebas de Integración
Del Proyecto “No hay tiempo para de Sistemas
diseñar las pruebas
tempranamente” Prueba
Especificación
Pruebas de Sistemas
Del Sistema

Prueba
Pruebas de Integración de
Especificación de Diseño
Componentes
Prueba

Código Pruebas de Componentes

¿Diseño de
Pruebas?
 MODELOS DE DESARROLLO DE SOFTWARE
______________________________________________________________________

MODELO V: NIVELES DE PRUEBAS TEMPRANAS

Prueba
Requerimientos
Pruebas de Aceptación
de Negocio

Prueba
Especificación Pruebas de Integración
Del Proyecto de Sistemas
Prueba
Especificación
Pruebas de Sistemas
Del Sistema
Prueba
Pruebas de Integración de
Especificación de Diseño
Componentes
Prueba

Diseño de Código Pruebas de Componentes Ejecución de

Pruebas Pruebas
MODELOS DE DESARROLLO DE SOFTWARE
______________________________________________________________________

CICLO DE VIDA ITERATIVO

• En lugar de trabajar una gran línea de tiempo, se puede dividir un

proyecto en pequeñas ciclos de vida , de manera que se pueda
aplicar las revisión y pruebas a cada iteración de principio a fin,

Live Implementation
MODELOS DE DESARROLLO DE SOFTWARE
______________________________________________________________________

CICLO DE VIDA ITERATIVO

• Ejemplos de modelos de desarrollo iterativo o incremental son:

Prototipos, Desarrollo rápido de aplicaciones (RAD), Rational
Unified Process (RUP) y Desarrollo ágil.
• RAD: funciones/componentes son desarrollador en paralelo
como si se trataran de mini proyectos.
NIVELES DE PRUEBAS
NIVELES DE PRUEBA
______________________________________________________________________
PRUEBAS DE COMPONENTES
• Las pruebas de componentes también conocida como prueba unitaria,
módulo o de programa.
• Verifica el funcionamiento y busca defectos en los componentes de
software que pueden ser analizados individualmente. (Ejemplo: módulos,
programas, objetos y clases).
• Como se analizan individualmente, se utilizan “stubs” y “drivers” para
reemplazar el software faltante y simular la interfaces entre los
componentes del software.
• El driver reemplaza a un componente que llama a otro componente;
• mientras que el stub reemplaza a un componente que es llamado
por otro componente.

Componente A A Driver

Componente B Stub B
NIVELES DE PRUEBA
______________________________________________________________________
PRUEBAS DE COMPONENTES
• Generalmente ejecutados por los desarrolladores.
• Se utilizan herramientas del entorno de desarrollo (IDE’s, depuradores,
etc.) que permiten el acceso al código.
• Usualmente los errores se arreglan al momento (sin necesidad de
documentarlos).
• El conocimiento del código permite la aplicación de métodos de caja
blanca.
• Puede incluir pruebas de funcionalidad y no funcionales (por ejemplo:
pérdidas de memoria, rendimiento) así como las pruebas estructurales
(por ejemplo: cobertura de decisión, cobertura de sentencias).
• Utilizados en Extreme Programming (XP) para preparar y automatizar
casos de prueba antes de codificar. Esto se llama una prueba de primer
enfoque o desarrollo basado en pruebas.
NIVELES DE PRUEBA
______________________________________________________________________________

PRUEBAS DE INTEGRACIÓN
• Pruebas aplicadas a interfaces de distintos componentes o a las
interacciones ente distintas partes de un sistema.
• Se puede dividir en:
• Pruebas de integración de componentes
• Prueba las interacciones entre los componentes de un
sistema. Se realiza después de las pruebas de
componentes.
• Pruebas de integración de sistemas.
• Prueba las interacciones entre los sistemas. Generalmente
se realiza después de las pruebas de sistemas.
NIVELES DE PRUEBA
______________________________________________________________________
ENFOQUES UTILIZADOS EN LAS PRUEBAS DE INTEGRACIÓN
• Pruebas de integración “Big-Bang’
• Se realiza cuando todos los componentes o sistemas están
completamente probados.
• Se prueba el integrado como un todo.
• Ventaja: No se tienen que simular partes.
• Desventaja: Ocupa tiempo y dificultad para rastrear fallas.
• Pruebas de integración “Paso a Paso”
• Los componentes se integran uno por uno y en cada integración
se realizan las pruebas.
• Testeo incremental.
• Ventaja: Es fácil de rastrear las fallas
• Se deben simular partes, por lo que demanda más tiempo.
NIVELES DE PRUEBA
______________________________________________________________________________

PRUEBAS DE INTEGRACIÓN – ENFOQUE “PASO A PASO”

• Top-Down: Las pruebas se realizan desde el principio hasta el

final, siguiendo el flujo de control.
• Bottom-Up: Las pruebas se realizan desde el final del flujo de
control hasta el principio.
• Funcionales: Las pruebas se llevan a cabo en base a las
funcionalidades, según lo documentado en la especificación
funcional.
NIVELES DE PRUEBA
______________________________________________________________________
PRUEBAS DE SISTEMAS
• Se concentra en el comportamiento de todo el sistema.
• Se incluyen pruebas basadas en requerimientos, riesgos, casos de
uso, procesos de negocio, etc. Se realizan tanto pruebas funcionales
como no funcionales.
• Relacionado con el comportamiento de todo el sistema en su
totalidad, según haya sido definido en el alcance del proyecto.
• Se comprueba que el sistema construido cumpla con todas sus
especificaciones.
• Analiza requerimientos funcionales (pruebas de caja negra y caja
blanca) y también requerimientos no funcionales.
• Se realiza en un entorno de pruebas, para tener mayor control sobre
el proceso.
NIVELES DE PRUEBA
______________________________________________________________________________

PRUEBAS DE ACEPTACIÓN

• Se presenta el software al cliente para su Aceptación.

• Es el cliente quien debe decidir si el producto está listo.
• Generalmente se realizan en un entorno de pruebas, simulando ser
el entorno donde será implementado el software.
• No está enfocado en encontrar defectos.
• Pueden ocurrir en más de un nivel. Ejemplos:
• Las pruebas de aceptación de usabilidad de componentes se deben
realizar durante las pruebas de componentes.
• Las pruebas de aceptación para una nueva mejora de funcionalidad
se deben realizar antes de las pruebas de sistema.
NIVELES DE PRUEBA
______________________________________________________________________________

PRUEBAS DE ACEPTACIÓN

• Pruebas de Aceptación del Usuario

• Funcionalidad
• Pruebas de Aceptación Operacional
• Pruebas de backup, restore, recuperación de información,
seguridad, tareas de mantenimiento, etc.»
• Pruebas Aceptación de Contratos
• Se prueba el sistema contra un criterio de aceptación
previamente definido en un contrato.
NIVELES DE PRUEBA
______________________________________________________________________________

PRUEBAS DE ACEPTACIÓN

• Pruebas de Aceptación Regulatorias

• Respecto a regulaciones legales, gubernamentales, de seguridad, etc.
• Pruebas Alfa
• Pruebas internas.
• Se realiza en el entorno del desarrollador.
• Pruebas Beta
• También llamado «pruebas de campo».
• Usuarios externos usan el producto.
• Ambientes de trabajo reales.
• Los usuarios informan de los errores o incidentes encontrados mientras
usaban el producto
TIPOS DE PRUEBAS
TIPOS DE PRUEBAS
______________________________________________________________________________

• Los tipos de prueba de software se presentan como un medio para

definir claramente el objetivo de un cierto nivel para un programa o
proyecto.
• Un tipo de prueba se centra en un objetivo de prueba particular, que
podría ser la prueba de la función que realizará el componente o
sistema.
• El objetivo de la prueba podría ser probar:
• características de calidad no funcionales , tales como confiabilidad o
usabilidad;
• la estructura o arquitectura del componente o sistema;
• o relacionado con cambios, es decir, confirmando que los defectos han sido
reparados ( pruebas de confirmación o nuevas pruebas ) y buscando cambios
involuntarios ( pruebas de regresión ).
TIPOS DE PRUEBAS
______________________________________________________________________________

• Dependiendo de sus objetivos, las pruebas se organizarán de

manera diferente. Por lo tanto, hay cuatro tipos de prueba de
software:
1. Pruebas funcionales.
2. Pruebas no funcionales.
3. Pruebas Estructurales/Arquitectura de SW.
4. Pruebas relacionadas a los cambios:
• Pruebas de Confirmación: diagnóstico o re-testing
• Pruebas de Regresión
TIPOS DE PRUEBAS
______________________________________________________________________________

1. PRUEBAS FUNCIONALES
• En las pruebas funcionales, básicamente se realiza la prueba
de las funciones del componente o sistema.
• Se refiere a actividades que verifican una acción o función
específica del código. La prueba funcional tiende a responder
preguntas como “¿puede el usuario hacer esto” o “funciona
esta característica en particular?” Esto se describe
típicamente en una especificación de requisitos o en una
especificación funcional.
NIVELES DE PRUEBA
______________________________________________________________________________

1. PRUEBAS FUNCIONALES: PERSPECTIVAS

• Pruebas basadas en los requisitos
• En este tipo de pruebas, los requisitos se priorizan según los criterios
de riesgo y basado en esto se priorizan las pruebas. Esto asegurará
que las pruebas más importantes y más críticas se incluyan en el
esfuerzo de prueba.
• Pruebas basadas en procesos de negocios
• En este tipo de pruebas, se describen los escenarios involucrados en
el uso comercial diario del sistema. Utiliza el conocimiento de los
procesos de negocios. Por ejemplo, un sistema personal y de nómina
puede tener el proceso de negocio en la línea de: alguien se une a la
empresa, el empleado recibe un pago de manera regular y el
empleado finalmente abandona la empresa.
TIPOS DE PRUEBAS
______________________________________________________________________________

2. PRUEBAS NO FUNCIONALES
• En las pruebas no funcionales, se prueban las características
de calidad del componente o sistema.
• No funcional se refiere a aspectos del software que pueden
no estar relacionados con una función específica o acción del
usuario, como la escalabilidad o la seguridad.
• Hace referencia a pruebas técnicas y de rendimiento
TIPOS DE PRUEBAS
______________________________________________________________________________

3. PRUEBAS ESTRUCTURALES/ARQUITECTURA DE SW
• La prueba estructural es la prueba de la estructura del
sistema o componente.
• Las pruebas estructurales a menudo se conocen como "caja
blanca" o "caja de vidrio" o "prueba de caja transparente"
porque en las pruebas estructurales nos interesa lo que está
sucediendo“ dentro del sistema/aplicación".
TIPOS DE PRUEBAS
______________________________________________________________________________

4. PRUEBAS RELACIONADAS A LOS CAMBIOS

• Pruebas de confirmación (re-testing)
• Ejecutar de nuevo la prueba para confirmar que el defecto haya
sido reparado.

• Pruebas de regresión
• Las pruebas se realizan con la intención de comprobar que el
sistema no ha retrocedido (es decir, que no tienen más
defectos como consecuencia de algún cambio).