Introducción al

testing
Parte 2
Objetivos de la clase

● Conocer y comprender los distintos tipos, técnicas y niveles de pruebas

que existen.
● Analizar la importancia de la documentación.
● Entender la diferencia entre pruebas estáticas y dinámicas.
Pruebas Estáticas y
pruebas Dinámicas
Testing dinámico vs Testing estático
Técnicas de
pruebas
Pruebas
dinámicas
ENCONTRAR
Tipos de pruebas FALLAS

Niveles de pruebas

ENCONTRAR
Pruebas DEFECTOS
Definiciones
estáticas

Documentación
Definición de Prueba Dinámica

Las pruebas dinámicas son aquellas que se realizan

mientras el código está en ejecución. Tienen como objetivo
asegurar que el software se comporte de acuerdo a los
Pruebas Dinámicas requerimientos del negocio mediante la realización de
pruebas funcionales y no funcionales.
Estas pruebas se enfocan en la detección y confirmación
de la corrección de defectos en el software. Por lo general
se realizan en una etapa más tardía que las pruebas
estáticas, por lo cual, los defectos encontrados en estas
son más costosos. Ejemplo Pruebas de aceptación,
Pruebas de regresión, Pruebas de integración, etc.
Definición de Prueba Estática
La prueba estática se basa en evaluación manual de los productos
de trabajo (es decir, revisiones) o en la evaluación basada en
herramientas del código u otros productos de trabajo. Ambos tipos
de prueba estática evalúan el código u otro producto de trabajo que
se esté probando sin ejecutar, de forma efectiva, el código o el
Pruebas Estáticas producto de trabajo que se esté probando. El análisis estático es
importante para los sistemas informáticos de seguridad crítica (por
ejemplo, aeronáuticos, médicos o nucleares), pero el análisis
estático también se ha vuelto importante y común en otros
contextos. Por ejemplo, el análisis estático es una parte importante
en la prueba de seguridad. El análisis estático también se incorpora,
con frecuencia, a los sistemas de construcción y entrega
automatizados, por ejemplo, en el desarrollo Ágil, la entrega continua
y el despliegue continuo.
Nombrar algunos ejemplos de
pruebas estáticas.
Ejemplos de Pruebas Estáticas
En comparación con las pruebas dinámicas, los defectos típicos que son más fáciles y
económicos de detectar y corregir a través de la prueba estática incluyen:
● Defectos en los requisitos (por ejemplo, inconsistencias, ambigüedades, contradicciones,
omisiones, inexactitudes y redundancias).
● Defectos de diseño (por ejemplo, algoritmos o estructuras de base de datos ineficientes, alto
acoplamiento, baja cohesión).
● Defectos de codificación (por ejemplo, variables con valores no definidos, variables que
nunca se utilizan, código inalcanzable, código duplicado).
● Desviaciones con respecto a estándares (por ejemplo, falta de adhesión a los estándares de
codificación).
● Especificaciones de interfaz incorrectas (por ejemplo, unidades de medida diferentes
utilizadas por el sistema que realiza la llamada respecto del utilizado por el sistema
llamado).
● Vulnerabilidades de seguridad (por ejemplo, susceptibilidad a desbordamientos de la
memoria intermedia).
● Deficiencias o inexactitudes en la trazabilidad o cobertura de la base de prueba (por ejemplo,
la falta de pruebas para un criterio de aceptación)
Pruebas Estáticas + Pruebas Dinámicas
 Documentación en el testing
Es toda información que sirve como respaldo y es muy importante que exista en un Proyecto.
Existen muchos tipos de documentación, tales como:
➔ Historias de usuario
➔ Plan de pruebas
➔ Criterios de Aceptación
➔ Requerimientos funcionales y no funcionales
➔ Casos de pruebas
➔ Documentos de Relevamiento
➔ Código Fuente
➔ Conocimiento de Negocio
➔ Etc..
Veremos con más detalle los tipos de
documentación en las próximas clases
Importancia de la documentación

➔ El trabajo del tester es bastante invisible, ya que no se

puede palpar en sí mismo, para eso entra en juego la
documentación.
➔ Es un respaldo como profesionales para indicar que
cosas se probaron, en base a qué estándares, quien los
pidió, y cualquier otro tipo de afirmación escrita.
¿Qué sucede si falta
documentación?
La falta de documentación, es una realidad más común de la
que creemos, y es una responsabilidad solicitarla en caso de
que no exista.

Ciertos tipos de pruebas, llamadas pruebas exploratorias,

hacen uso nulo de documentaciones, pero son solo una
primera instancia de trabajo. El uso de la documentación es
algo sumamente prioritario.
Técnicas de pruebas
Definición
Las técnicas de pruebas ayudan a identificar las condiciones de prueba, los casos de prueba y los datos
de prueba.

Se clasifican en:
● Caja negra
● Caja blanca
● Basadas en la experiencia
 Técnica
Caja Negra
 Técnica de caja negra

Las técnicas de prueba de caja negra (también

llamadas técnicas conductuales o basadas en el
comportamiento) se basan en un análisis de la base
de prueba adecuada (por ejemplo, documentos de
requisitos formales, especificaciones, casos de uso,
historias de usuarios o procesos de negocio). Estas
técnicas son aplicables tanto a la prueba funcional
como a la no funcional. Las técnicas de prueba de
caja negra se concentran en las entradas y salidas
del objeto de prueba sin referencia a su estructura
interna.
Técnicas de prueba de caja negra

➔ Partición de equivalencia
➔ Análisis de valores frontera
➔ Prueba de tabla de decisión
➔ Prueba de transición de estado
➔ Prueba de caso de uso
Partición de equivalencia
✓ Consiste en clasificar las entradas de datos del sistema en grupos que representan un
comportamiento similar.
✓ Se pueden definir particiones tanto para datos válidos (aceptados por el sistema) como no
válidos (no aceptados por el sistema).
✓ Para lograr una cobertura del 100% con esta técnica, los casos de prueba deben cubrir todas las
particiones identificadas utilizando, como mínimo, un valor de cada partición.

Ejemplo
● Analizamos la edad de una persona
● Dividimos en dos grupos “mayores de edad” y “menores de edad”

Menores Mayores

1….17 18….n
Ejemplo

● Los números de orden de un sistema de control de stock puede variar entre 10.000 y 99.999,
ambos inclusive.
○ CLASE VÁLIDA: Clase 1 (10.000 / 99.999)
○ CLASE INVÁLIDA: Clase 2 (100)
○ CLASE INVÁLIDA: Clase 3 (250.000)
 Análisis de valores de frontera

✓ Es una extensión de la partición de equivalencia, pero sólo se puede utilizar

cuando la partición está ordenada, y consiste en datos numéricos o
secuenciales.

✓ Los valores mínimo y máximo de una partición son sus valores frontera.

✓ Esta técnica se utiliza generalmente para probar los requisitos que requieren un
rango de números, fechas y horas.
Ejemplo
● Un campo de un formulario solo acepta números del 1 al 5.

Partición de equivalencia Valores frontera

Inválida Válida Inválida Inválida Válida- Inválida

(demasiado (demasiado (demasiado (demasiado alta)
baja) alta) baja)-Válida

0 1,2,3,4,5 6,7,8,9 0y1 5y6

Ejemplo
● Un campo de un formulario solo acepta números del 1 al 5 inclusive.

Partición de equivalencia Valores frontera

Inválida Válida Inválida Inválida Válida- Inválida

(demasiado (demasiado (demasiado (demasiado alta)
baja) alta) baja)-Válida

0 1,2,3,4,5 6,7,8,9 0y1 5y6

Tabla de decisión

✓ Las técnicas de prueba combinatorias son útiles para probar la implementación

de requisitos de sistema, que especifican como diferentes combinaciones de
condiciones generan diferentes resultados.

✓ Al crear tablas de decisión, el probador identifica las condiciones y las acciones

resultantes del sistema. Éstas conforman las condiciones en la parte superior y
las acciones en la parte inferior.

✓ Es una buena técnica capturar/entender reglas de negocio que contienen

condiciones lógicas.
Ejemplo
Condición/Combinación Combinación 1 Combinación 2 Combinación 3 Combinación 4

¿Se ingresó el modelo del V V F F

vehículo?

¿Se ingresó el color del V F V F

vehículo?
Ejemplo
Condiciones

¿Se ingresó el modelo del Verdadero Verdadero Falso Falso

vehículo?

¿Se ingresó el color del vehículo? Verdadero Falso Verdadero Falso

Acciones/Salidas

¿Se procesa la característica 1? Verdadero Verdadero Falso Falso

¿Se procesa la característica 2? Verdadero Falso Verdadero Falso

¿Mensaje de error? Falso Verdadero Verdadero Verdadero

Otro ejemplo..
Otrooo ejemplo..
 Transición de estado

✓ Un diagrama de transición de estado muestra los posibles estados del software,

así como la forma en que el software entra, sale y realiza las transiciones entre
estados.

✓ Una transición se inicia con un evento. El evento resulta en una transición.

✓ El cambio de estado puede provocar que el software tome una acción.

Transición de estado
Transición de estado
 Prueba de caso de uso

✓ Las pruebas se pueden obtener a partir de casos de uso, que son una forma
específica de diseñar interacciones con elementos software, incorporando
requisitos para las funciones del software representadas por los casos de uso

✓ Los casos de uso están asociados con actores (usuarios humanos, hardware
externo u otros componentes o sistemas) y sujetos (el componente o sistema al
que se aplica el caso de uso).
 Técnica
Caja Blanca
 Técnica de caja blanca

La prueba de caja blanca se obtienen pruebas

basadas en la estructura interna del sistema o en su
implementación. La estructura interna puede incluir
código, arquitectura, flujos de trabajo y/o flujos de
datos dentro del sistema
Técnicas de prueba de caja blanca

➔ Prueba y cobertura de sentencia

➔ Prueba y cobertura de decisión
➔ El valor de la prueba de sentencia y
decisión
 Prueba y cobertura de sentencia
✓ La prueba de sentencia práctica las sentencias ejecutables en el código.
✓ La cobertura se mide como el número de sentencias ejecutadas por las pruebas
dividido por el número total de sentencias ejecutables en el objeto de prueba,
normalmente expresado como un porcentaje.
 Prueba y cobertura de decisión
✓ La prueba de decisión practica las decisiones en el código y prueba el código que se
ejecuta basado en los resultados de la decisión. Para ello, los casos de prueba siguen
los flujos de control que se producen desde un punto de decisión (por ejemplo, para una
declaración IF, uno para el resultado true y otro para el resultado false; para una
declaración CASE, se necesitarían casos de prueba para todos los resultados posibles,
incluido el resultado por defecto).
✓ La cobertura se mide como el número de resultados de decisión ejecutados por las
pruebas dividido por el número total de resultados de decisión en el objeto de prueba,
normalmente expresado como un porcentaje.
 Técnica
Basada en la
Experiencia
 Basadas en la experiencia

Al aplicar técnicas de prueba basadas en la experiencia, los

casos de prueba se obtienen a partir de la competencia e
intuición del probador y de su experiencia con aplicaciones y
tecnologías similares. Estas técnicas pueden ser útiles para
identificar pruebas que no fueron fácilmente identificadas por
otras técnicas más sistemáticas. Dependiendo del enfoque y la
experiencia del probador, estas técnicas pueden lograr grados
muy diferentes de cobertura y efectividad. La cobertura puede
ser difícil de evaluar y puede no ser medible con estas técnicas.
Técnicas de prueba basadas en la
experiencia
➔ Predicción de errores
➔ Prueba basada en listas de comprobación
➔ Prueba exploratoria
Predicción de errores

Es una técnica utilizada para anticipar la ocurrencia de equivocaciones, defectos y

fallos, basada en el conocimiento del tester, incluido:
● Cómo ha funcionado la aplicación en el pasado.
● Qué tipo de equivocaciones tienden a cometer los desarrolladores.
Pruebas basadas en listas de comprobación
● Estas listas de comprobación pueden elaborarse basándose en la experiencia, el
conocimiento de lo que es importante para el usuario o la comprensión de por qué y cómo
falla el software.
 Prueba exploratoria
● Se diseñan, ejecutan, registran y evalúan de forma dinámica pruebas informales
durante la ejecución de la prueba.
● Los resultados de la prueba se utilizan para aprender más sobre el componente o
sistema, y para crear pruebas para las áreas que pueden necesitar ser probadas con
mayor intensidad.
Tipos de pruebas
Concepto
Un tipo de prueba es un grupo de actividades de prueba destinadas a probar
características específicas de un sistema de software, o de una parte de un sistema,
basadas en objetivos de prueba específicos.
 Prueba funcional

● La prueba funcional de un sistema incluye pruebas que evalúan las funciones que
el sistema debe realizar.
● Los requisitos funcionales pueden estar descritos en productos de trabajo tales
como especificaciones de requisitos de negocio, épicas, historias de usuario,
casos de uso, o especificaciones funcionales.

Las funciones describen "qué" debe hacer el sistema

 Prueba no funcional

● Las pruebas no-funcionales evalúan otras características de sistemas, como por

ejemplo el UX/UI, conectividad o la seguridad.
● La prueba no-funcional prueba que tan bien se comporta un sistema.
● Hacen foco en los requerimientos no funcionales.

Describen "cómo" lo debe hacer el sistema

Requerimientos no funcionales

Son los requerimientos que especifican propiedades del sistema tales como:
● Performance testing
● Pruebas de carga
● Pruebas de stress
● Pruebas de usabilidad,
● Pruebas de mantenimiento
● Pruebas de fiabilidad
● Pruebas de portabilidad
Pruebas asociadas al cambio

Son pruebas que se utilizan para comprobar corrección de defectos o mejoras en un sistema
o nuevas funcionalidades, para poder asegurar que el sistema funciona como corresponde.

Se separan en dos grandes áreas:

● Pruebas de confirmación.
● Pruebas de regresión.
● Pruebas de confirmación ● Pruebas de regresión

Cuando nos entregan el sistema Se realizará una regresión sobre lo

corregido de algún defecto, se llevan que ya se probó. Esta prueba se
adelante estas pruebas para asegurar utiliza para corroborar que ninguna
que el error ya no se encuentra. Esto otra área del sistema haya sido
implica realizar los pasos que llevaron afectada por el cambio realizado en
adelante ese error, y continuar con los él. Esto es para ver que no haya
próximos pasos, si es que este defecto ningún defecto como daño
bloqueo alguno o probar si otras áreas secundario a causa de estos
del sistema, relacionadas con el cambios.
defecto, siguen funcionando de forma
correcta.
Niveles de pruebas
Definición
Los niveles de prueba son etapas o fases dentro del proceso de prueba de software que se
utilizan para verificar y validar la funcionalidad del software y asegurarse de que cumpla con
los requisitos y expectativas del usuario. Cada nivel de prueba es una instancia del proceso
de prueba y están relacionados con otras actividades dentro del ciclo de vida del desarrollo
de software.

Se centra en otros aspectos del software y se realiza utilizando diferentes técnicas y

herramientas de prueba. La combinación de estos niveles de prueba ayuda a certificar la
calidad del software.
 Pruebas
de Aceptación
Acceptance Tests A medida que nos vamos
hacia arriba en la pirámide:

➔ la cantidad de
Pruebas de Sistema
System Tests pruebas disminuye
➔ su enfoque se vuelve
Pruebas de Integración más abarcativo.
Integration Tests

Pruebas Unitarias
Unit Tests
Pruebas unitarias o de componentes

● Se centra en los componentes que se pueden probar por separado. Se realiza de

forma aislada del resto del sistema.
● Los objetos de prueba suelen ser directamente código como componentes, unidades,
módulos, clases, estructura de datos, módulos de bases de datos, etc.
● Se prueba cada componente tras su realización/construcción.
● Cada componente es probado de forma independiente -
● Los errores se suelen corregir tan pronto como se encuentran, sin constancia oficial
de los incidentes.
Pruebas de integración

● Se centra en las interacciones entre componentes o sistemas.

● Cuando se integran las partes que se probaron aisladamente, se prueba todo en
conjunto validando su funcionamiento como un todo.
● Test orientado a verificar que las partes de un sistema que funcionan bien
aisladamente, también lo hacen en conjunto.
● Cualquier estrategia de prueba de versión o de integración debe ser incremental, para
lo que existen dos esquemas principales:

• Integración de arriba hacia abajo (top-down)

• Integración de abajo hacia arriba (bottom-up)

Pruebas de sistemas

● Se centra en el comportamiento y las capacidades de todo un sistema o producto, a

menudo teniendo en cuenta las tareas extremo a extremo que el sistema puede
realizar y los comportamientos no funcionales que exhibe mientras realiza esas
tareas.
● Pruebas realizadas cuando el sistema funciona como un todo.
● Se prueban requerimientos funcionales y requerimientos no funcionales
● Trata de determinar si el sistema en su globalidad opera satisfactoriamente
Pruebas de aceptación

● Se centra normalmente en el comportamiento y las capacidades de todo un sistema o

producto.
● Se evalúa el grado de satisfacción general para su despliegue y uso por parte de los
usuarios.
● Es la prueba realizada por el usuario para determinar si la aplicación se ajusta a sus
necesidades.
● La meta en las pruebas de aceptación es el de establecer confianza en el sistema, las
partes del sistema o las características específicas y no funcionales del sistema.
● Encontrar defectos no es el foco principal en las pruebas de aceptación.
Resumiendo…
Niveles de Testing

★ Unitario
★ Integración
Técnicas de Testing ★ Sistema Tipos de pruebas
★ Aceptación
★ Caja negra ★ Funcionales
★ Caja blanca ★ No funcionales
★ Basadas en la experiencia ★ Caja blanca
¿Preguntas?
 Actividad
Aplicar y describir las técnicas de caja negra partición de equivalencias y análisis de
valores fronteras, para probar una aplicación que calcula según la fecha de nacimiento a
qué generación pertenece una persona. Las categorías son:

Tiempo estimado: 10 minutos

 Actividad
Enumerar qué técnicas, tipos de pruebas y niveles de prueba aplicarias para un proceso de
compra de una tienda virtual.

Tiempo estimado: 10 minutos

Muchas gracias!