MTF - Módulo 3

Metodologías del Testing Funcional
LTI – Plan 2024 1

Contenido
AMBIENTES ......................................................................................................................... 3
Ambiente de Desarrollo .................................................................................................. 3
Ambiente de Testeo ........................................................................................................ 3
Ambiente de Producción ................................................................................................ 4
Ambiente Independiente de Pruebas ............................................................................. 4
TÉCNICAS, NIVELES Y TIPOS DE TESTEO....................................................................... 5
Técnicas de Testeo ......................................................................................................... 5
Caja Blanca .................................................................................................................. 5
Caja Negra .................................................................................................................... 5
Caja Gris ....................................................................................................................... 5
Niveles de Testeo ............................................................................................................ 5
Tipos de Testeo ............................................................................................................... 6
TIPOS DE PRUEBAS FUNCIONALES ................................................................................ 8
Pruebas de Componente / Unitarias / Unit Test ............................................................ 8
El entorno de prueba de los test unitarios ............................................................... 10
Frameworks de prueba para el unit testing ............................................................. 10
Prueba de Integración ................................................................................................... 11
Pruebas Unitarias vs. Pruebas de Integración......................................................... 12
Tipos de Pruebas de Integración .............................................................................. 13
Ventajas de las pruebas de integración ................................................................... 16
Prueba de Sistema ........................................................................................................ 17
¿Cuándo hay que probar el sistema? ...................................................................... 17
¿Quién participa en las pruebas del sistema?......................................................... 18
¿Qué se prueba en las pruebas de sistemas? ......................................................... 18
¿Cuáles son los tipos de pruebas de sistema de software? .................................. 19
Prueba de Aceptación ................................................................................................... 20
LTI – Plan 2024 2

AMBIENTES
En el contexto informático, un ambiente se refiere al hardware y software donde se ejecuta una

aplicación.
Dependiendo del proyecto, es la cantidad de ambientes por los cuales iremos propagando un
aplicativo desde Desarrollo hasta Producción.
Cada ambiente tiene su propia base de datos, los componentes de infraestructura adecuados y su
copia de todo lo necesario para que el aplicativo funcione correctamente.
Normalmente hablamos de tres ambientes: Desarrollo, Testeo y Producción. En algunas ocasiones, se

hace referencia también, a un ambiente de Pre-Producción.
Ambiente de Desarrollo
Podría ser la PC de cada desarrollador, allí tendría su propio ambiente con su propia base de datos,
dado que es el espacio para la creación/modificación del software. También podría contarse con un
servidor compartido, en el cual varios desarrolladores trabajan sobre el mismo proyecto.
En definitiva es el lugar dónde crean o modifican los fuentes del aplicativo, y realizan las pruebas
unitarias del mismo; como tal, debería ser similar al de testeo y producción.
Ambiente de Testeo
El ambiente de pruebas, es el lugar dónde ejecutaran las pruebas diseñadas y dónde debemos tener
instalado todo lo necesario para cumplir con esta tarea (aplicativo a probar, base de datos con la
estructura de producción, componentes de infraestructura símil producción).
En algunas empresas, se maneja un ambiente intermedio entre el ambiente de testeo y el ambiente

de producción, en el que se realizan las pruebas de performance. Es un ambiente idéntico (o muy
similar) a producción en cuanto a volumen de datos (por temas de seguridad, los datos de producción
deberían estar enmascarados en esta base; pero esto depende del negocio y la criticidad de los datos
del proyecto en sí) y a infraestructura; el objetivo allí, es medir el rendimiento del aplicativo (que
previamente fue verificado funcionalmente, y que tiene el OK de testeo funcional). A este ambiente
se le conoce como ambiente de Pre-Producción.
LTI – Plan 2024 3

Ambiente de Producción
Este es el lugar donde el aplicativo corre en la “vida misma”, donde acceden todos los usuarios finales
del mismo. El aplicativo debe estar en la versión que fue verificada y aprobada anteriormente por
testing, siendo la base de datos y la infraestructura utilizadas aquí, las más adecuadas para el aplicativo
en cuestión. Este ambiente debería ser administrado por un especialista de operaciones o producción,
y accedido solo por los especialistas de cada área.
Ambiente Independiente de Pruebas
Cómo dijimos antes, es el lugar donde se deberán ejecutar las pruebas y donde debemos tener
instalado todo lo necesario para cumplir con esta tarea (aplicativo a probar, base de datos con la
estructura de producción, ente otras cosas que se deberán tener instaladas).
El ambiente ideal para la ejecución de las pruebas, es aquel que es independiente del desarrollo del
software, y por supuesto, independiente de producción.
Es necesario que este ambiente sea independiente del ambiente de desarrollo y del ambiente de
producción por varios motivos, entre ellos:
 Tener bajo control la versión del aplicativo que se está probando:
o Si probáramos en el ambiente de desarrollo, el equipo de desarrollado podría cambiar la

versión que estamos probando sin avisar, y ahí perdemos el control de los defectos
reportados, no sabríamos cuándo publicaron nueva versión ni qué defectos estaban
corregidos.
o Si probáramos en el ambiente de producción, los defectos que nosotros detectamos (e

incluso otros defectos), también los está viendo el usuario final del aplicativo con todo lo
que esto conlleva.
 Manipulación de los datos utilizados: Los datos que usamos para las pruebas también podrían
ser manipulados por los desarrolladores, perdiendo nosotros el control de los mismos, y esto nos
puede llevar a resultados erróneos (por ejemplo, si habíamos preparado un dato para que el
resultado de la prueba sea un 15, y entre que preparamos el dato y ejecutamos la prueba,
desarrollo nos cambia dicho dato, el resultado obtenido puede ser diferente al que pretendíamos
que fuera y reportaríamos un defecto cuando en realidad era un problema con los datos con los
que ejecuté la prueba).
LTI – Plan 2024 4

TÉCNICAS, NIVELES Y TIPOS DE TESTEO1
Técnicas de Testeo
Una técnica es un procedimiento que tiene como objetivo obtener un determinado resultado. En este
contexto, existen varias técnicas de testeo complementarias.
Las tres técnicas de testeo conocidas al día de hoy, son: Caja Blanca, Caja Negra y Caja Gris.
Caja Blanca
Apunta a testeo unitario. Está basada en el código fuente del aplicativo, mirando cómo fue diseñado
y programado el mismo.
Caja Negra
Esta técnica aborda el comportamiento de los requerimientos especificados (ya sea en forma de casos
de uso o de historias de usuario). Está basada en las entradas y las salidas del aplicativo a probar; mira
el funcionamiento del sistema.
Caja Gris
Combina los testeos de Caja Negra y Caja Blanca. Usa diferentes fuentes de información y detecta
problemas de distinto tipo.
Niveles de Testeo
Para cada nivel de testeo, pueden ser identificados los siguientes aspectos:
 Sus objetivos genéricos,

 Los productos de trabajo utilizados,
 El objetivo del testeo (lo que se está probando),
 Incidentes,
1 Esta clasificación de técnicas, niveles y tipos, dentro de la disciplina de testing, está basada en el material propuesto por
ISTQB (INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD).
LTI – Plan 2024 5

 Pruebas diseñadas,
 Herramientas de soporte y ejecución,
 Responsabilidades específicas.
Son niveles de prueba, los siguientes:
 Testeo unitario: Testeo inicial de un código que pertenece a un módulo

 Testeo de integración: Verifica la correcta comunicación entre módulos
 Testeo de Sistema: Comprueba la ejecución apropiada de todos los componentes
 Testeo de Integración de Sistemas: Verifica la integración de todas las aplicaciones
 Testeo de Aceptación: ¿El sistema alcanza los requerimientos del usuario?
 Testeo de Operabilidad: ¿La aplicación podrá operar en el ambiente de producción?
Tipos de Testeo
Un conjunto de actividades de testeo son dirigidas a comprobar un aplicativo (o una parte de uno),
basadas en un motivo u objetivo específico.
Cada conjunto de actividades de testeo tiene un foco particular, que puede ser probar una
funcionalidad del aplicativo o una característica de calidad no funcional del mismo (por ejemplo, el
tiempo de respuesta del aplicativo al generar un reporte).
A este conjunto de actividades de testeo con un foco particular, le llamamos Tipo de Testeo.
En esta línea, se definen dos grandes tipos de testeo: Testing Funcional y Testing Estructural. A su vez,
dentro de cada uno de estos grandes tipos, se definen otros.
El objetivo del Testing Funcional, es verificar si el comportamiento del aplicativo a prueba coincide
con los requerimientos funcionales definidos para el mismo. En pocas palabras, su propósito es
asegurar que los requerimientos funcionales del usuario y las especificaciones realizadas durante el
análisis del aplicativo, son alcanzados.
Las Pruebas de Funcionalidad o Pruebas Modulares, las Pruebas de Regresión y las Pruebas de
Integración de Módulos son tipos de Testing Funcional.
Para profesionalizarse o especializarse en este tipo de pruebas, se requiere un perfil muy analítico-
crítico; también un poco de gusto por la tecnología para mantenerse actualizados en sus tendencias
(aún con un perfil analítico, somos informáticos .
LTI – Plan 2024 6

El propósito del Testeo Estructural, es asegurar que los requerimientos técnicos (o requerimientos no
funcionales) del sistema funcionan en forma correcta.
Se diseñan pruebas para verificar que el sistema está firme estructuralmente y puede ejecutar las
tareas propuestas (siempre con foco en los requerimientos técnicos o no funcionales).
Su objetivo es asegurar que la tecnología ha sido usada apropiadamente y que cuando las partes que
componen el sistema son integradas, se ejecutan como una unidad consistente.
Las pruebas no pretenden verificar la correcta funcionalidad del sistema, sino que el sistema está
técnicamente sólido. De hecho, es aconsejable que este tipo de pruebas se ejecute una vez que se
tiene el OK de las pruebas funcionales del aplicativo.
Para profesionalizarse o especializarse en este tipo de pruebas, se requiere un marcado perfil técnico,
gusto por la investigación, las herramientas y las tendencias tecnológicas.
Se destacan dentro de este tipo de testeo, las siguientes categorías (o sub-tipos):
 Testeo de Recuperación y Respaldo

 Testeo de Contingencia
 Testeo de Performance
 Testeo de Seguridad
 Testeo de Operabilidad
 Testeo de Performance
 Testeo de estrés.
También se consideran tipos de testeo los siguientes: Testing de Estructura o Arquitectura del
Software y Testing Relacionado a los Cambios.
El Testing de Estructura o Arquitectura del Software, está muy ligado a la técnica de testeo de Caja
Blanca, incluso se le podría ver como parte de esa técnica.
El objetivo de este tipo de testeo, es la verificación del diseño del aplicativo. Y puede utilizarse en
todos los niveles de prueba.
Por ejemplo, cuando verificamos que la forma de autenticación de un sistema no se ve afectada,

cuando se dan cambios en la forma de identificarse frente al sistema debido a que se cambia el
servidor sobre el cual se realiza la autenticación.
LTI – Plan 2024 7

Para profesionalizarse dentro de esta área, se requiere un perfil técnico muy marcado. Se trabaja codo
a codo con el arquitecto de aplicaciones.
El Testing Relacionado a los Cambios, está muy ligado al Testeo de regresión, tanto que podríamos
verlo como eso.
Su objetivo, es que, siempre se realicen pruebas una vez que un aplicativo ya probado sufra
modificaciones de algún tipo.
A diferencia del Testeo de Regresión que vamos a ver como subtipo del Testing Funcional, este tipo
de testeo aplica a pruebas no funcionales y de estructura, además de aplicar para las pruebas
funcionales.
Las pruebas de regresión son ejecutadas muchas veces, por lo que son candidatas a ser automatizadas
(en particular, las pruebas no funcionales y las de estructura).
TIPOS DE PRUEBAS FUNCIONALES
Existen varios tipos de pruebas funcionales que se utilizan para evaluar si un software cumple con los
requerimientos funcionales especificados y si se comporta como se espera desde la perspectiva del
usuario final.
Cada nivel / instancia del proceso de prueba se relaciona a etapa específica del ciclo de vida del
software y se enfoca en diferentes aspectos del software en desarrollo.
Niveles:
● Prueba de componente (unitaria)
● Prueba de integración
● Prueba de sistema
● Prueba de aceptación
Pruebas de Componente / Unitarias / Unit Test

Los test unitarios son una de las formas más eficaces para descubrir la mayor cantidad posible de
errores del código en las fases tempranas de desarrollo del software. Estos test permiten examinar el
correcto funcionamiento de cada uno de los elementos antes de que ocupen su lugar en el concepto
general de un programa.
LTI – Plan 2024 8

Por lo general, las pruebas unitarias tienen como objetivo la comprobación frecuente de diversos
componentes, es por esto que se realizan de forma automática. Así, con solo presionar un botón, los
respectivos programas realizan varias pruebas unitarias al azar. Es común que el programa de prueba
utilizado esté escrito en el mismo lenguaje del objeto de prueba.
El término unit test proviene del inglés y se refiere al método de comprobación de las “unidades” (en
inglés unit) más pequeñas del software. Los componentes más pequeños que pueden probarse y
cuyos resultados con más significativos son los módulos. Es recomendable comprobarlos en las
primeras fases de desarrollo, pues en la fase de prueba, el módulo aún se puede corregir de forma
relativamente rápida y poco costosa. En fases posteriores, estos procesos están asociados a mayores
gastos. Las pruebas unitarias se ocupan principalmente de las funcionalidades técnicas.
Por lo general, el desarrollador es quien ejecuta las pruebas y se encarga de corregir errores y asegurar
la correcta funcionalidad de los componentes.
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes
individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer.
Estas pruebas aisladas proporcionan cinco ventajas básicas:

● Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código
para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que
permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no
han introducido defectos.
● Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado
alto de seguridad de que el código está funcionando correctamente. De esta manera se
facilitan las pruebas de integración.
● Documenta el código: Las propias pruebas son documentación del código, puesto que ahí
se puede ver cómo utilizarlo.
● Separación de la interfaz y la implementación: Dado que la única interacción entre los

casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede
cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos maquetados
(mock object - maqueta) que habilitan de forma aislada (unitaria) el comportamiento de
objetos complejos.
● Los errores están más acotados y son más fáciles de localizar: Dado que tenemos pruebas
unitarias que pueden desenmascararlos.
LTI – Plan 2024 9

Para que una prueba unitaria tenga la calidad suficiente se deben cumplir los siguientes
requerimientos:
● Automatizable: No debería requerirse una intervención manual. Esto es especialmente
útil para integración continua.
● Completas: Deben cubrir la mayor cantidad de código.
● Rápidas: Deben poder ejecutarse en fracciones de segundo, caso contrario serán

obviadas.
● Repetibles o Reutilizables: No se deben crear pruebas que sólo puedan ser ejecutadas
una sola vez. También es útil para integración continua.
● Independientes: La ejecución de una prueba no debe afectar a la ejecución de otra.
● Profesionales: Las pruebas deben ser consideradas igual que el código, con la misma
profesionalidad, documentación, etc.
El entorno de prueba de los test unitarios
La prueba se realiza en el llamado entorno autónomo. El reto está entonces en la creación de dicho
entorno, algo que puede resultar complejo y requiere mucho tiempo en caso de querer implementarlo
manualmente. Debido a que los módulos se ejecutan de manera independiente, es necesario utilizar
el llamado arnés de pruebas (en inglés test harness). Este script de pruebas permite que el objeto del
test se convierta en un programa ejecutable. Para crear un entorno de prueba realista, se utilizan
sustitutos de código (stubs) que sirven como marcadores cuando el módulo requiere otros
componentes para interactuar.
Frameworks de prueba para el unit testing
El objetivo de los tests unitarios es detectar errores dentro de los componentes individuales. Si la idea
es garantizar la exactitud del código durante todo el proceso de desarrollo, es necesario llevar a cabo
pruebas unitarias constantemente. Es por esto que aquí, automatización es una palabra clave.
Existen frameworks de prueba de software especiales para la ejecución de unit tests. Casi todos los
lenguajes de programación cuentan con un software de pruebas unitarias apropiado. Este se encarga
de leer el código fuente y comprobar si hay errores. Las herramientas se encargan de fijar
automáticamente el entorno anteriormente mencionado. El desarrollador se concentra en definir los
casos de prueba.
LTI – Plan 2024 10

Prueba de Integración
Este tipo de pruebas evalúa la forma en que interactúan y operan varios módulos de aplicaciones de
software de forma cohesiva. El sistema se divide en componentes conocidos como módulos o
unidades. Cada módulo es responsable de una tarea específica. El verdadero desafío llega cuando
combinamos estos componentes para desarrollar todo el sistema de software.
En esta etapa, se comienza a examinar cuidadosamente las conexiones entre cada módulo para
descubrir cualquier problema potencial que resulte de una sola unidad. Cuando las pruebas han
finalizado, se realizan pruebas de punta a punta para evaluar la funcionalidad de la aplicación de
principio a fin.
Los módulos del software son combinados manualmente y se evalúan sus relaciones en las pruebas
manuales de componentes. Las pruebas manuales pueden ser costosas y vulnerables al error humano.
Puede resultar desafiante cubrir adecuadamente todas las posibilidades de integración en sistemas
complicados, por tanto, para abordar estos problemas se suele emplear la automatización.
La integración continua y las prácticas de entrega continua ayudan en la automatización. Los pipelines
CI/CD automatizan el desarrollo del código, de las pruebas y de la implantación. Las herramientas
CI/CD ejecutan pruebas de integración de forma automática para verificar que el nuevo código se
integra correctamente con el sistema existente. Simplifica la resolución de los problemas antes de que
se agraven, ya que permite hacer aportaciones inmediatas a los desarrolladores.
Al igual que otros procedimientos de pruebas, las pruebas de integración de sistemas implican una
serie de pasos para crear una aplicación sin errores. A continuación se describen algunos puntos
esenciales a tener en cuenta:
● Crear un plan de pruebas: El plan de pruebas incluye los objetivos, alcance y enfoque de la
fase de pruebas. Esto ayuda a los testers y partes interesadas a entender cómo se llevarán a
cabo las pruebas.
● Comenzar con módulos esenciales: Dar prioridad a los módulos más vitales al desarrollar los
casos de prueba. Es probable que estos componentes generen problemas si no son integrados
adecuadamente.
● Usar herramientas diversas: Existen numerosas herramientas para implementar y ejecutar

pruebas de integración. Seleccionen las herramientas que cumplan mejor sus requerimientos
y restricciones financieras.
● Realizar las pruebas en varios entornos: Esto garantizará que las pruebas sean sólidas y
capten cualquier error en múltiples entornos.
● Evaluar los resultados minuciosamente: Esta es una etapa crucial en el proceso de pruebas.
Puedes descubrir cualquier fallo que requiera ser reparado al evaluar cuidadosamente los
hallazgos.
LTI – Plan 2024 11

Pruebas Unitarias vs. Pruebas de Integración
Las pruebas unitarias y de integración tienen propósitos distintos y se llevan a cabo en varias fases del
ciclo de vida de desarrollo. La siguiente tabla compara las diferencias entre las pruebas unitarias y las
pruebas de integración:
Aspecto Pruebas Unitarias Pruebas de integración
Alcance Se concentran en unidades o módulos Evaluan la interacción de módulos

particulares. integrados.
Objetivo Comprobar que cada elemento Comprobar que todas las piezas
funciona de forma independiente. conectadas entre sí funcionan
correctamente.
Interoperabilidad Las dependencias externas se Se requiere la integración con módulos

mantienen separadas de las pruebas. del mundo real.
Velocidad Puesto que se concentra en unidades El tiempo de ejecución es un poco

pequeñas, la ejecución es más rápida. mayor debido a las pruebas de los
diversos módulos.
Cobertura Ofrece cobertura extensiva de código Garantiza que los módulos funcionen
al inspeccionar módulos de forma correctamente como elemento del
exhaustiva. sistema genera.
Flujo de Trabajo Normalmente, los desarrolladores Estas suelen llevarse a cabo durante la
de las Pruebas realizan pruebas unitarias antes que fase de integración del software.
las pruebas de integración.
LTI – Plan 2024 12

Tipos de Pruebas de Integración
Se pueden dividir en dos subtipos:

● Pruebas incrementales
● Pruebas no incrementales
Las pruebas incrementales consisten en probar módulos de software en pequeños incrementos. Las
pruebas de software comienzan con partes más pequeñas y avanzan progresivamente a través de
todo el sistema.
Cada prueba mejora el software al integrar los módulos adicionales. En comparación con probar el
sistema completo de forma simultánea, esto ofrece ventajas, incluyendo una retroalimentación
temprana, una resolución de problemas más directa y de menor complejidad. Las pruebas
incrementales ofrecen dos tipos:
● Integración Top-Down: Las pruebas top-down emplean un enfoque sistemático para probar
los módulos de software desde el nivel superior hacia abajo a través de la jerarquía del
sistema. Las pruebas comienzan con el módulo principal del software y continúan con los
submódulos de la aplicación.
Su objetivo principal es garantizar la funcionalidad entre los módulos de nivel superior y sus
submódulos. A medida que el procedimiento de prueba avanza por la jerarquía, se
comprueban las relaciones entre módulos para garantizar que los componentes del software
funcionan según lo previsto.
LTI – Plan 2024 13

Dado que los módulos de nivel superior se evalúan antes que los de nivel inferior, esta técnica
permite descubrir en una fase temprana los fallos de diseño de alto nivel. Ayuda a detectar
posibles problemas estructurales en las primeras fases de desarrollo.
Los “stubs” pueden emular módulos de nivel inferior, por lo que las pruebas pueden comenzar
incluso antes de que estén totalmente construidos. Esto ayuda a mejorar el procedimiento de
prueba y permite al equipo de desarrollo hacer aportaciones más rápidamente.
● Integración Bottom-Up: Cuando se realizan pruebas bottom-up, primero se prueban los

módulos de nivel inferior. Se pasa gradualmente a los módulos de nivel superior y así
sucesivamente, hasta que todas las facetas del software se han probado a fondo. Esta
estrategia se denomina razonamiento inductivo. Resulta beneficiosa cuando se incorporan al
producto final componentes ya existentes.
LTI – Plan 2024 14

Implica escribir código para varios módulos en lugar de centrarse en “stubs” u objetos
simulados. Por eso su tasa de éxito es mayor que la de otros enfoques.
Además, el tiempo de ejecución de las pruebas suele ser inferior al de otras metodologías
tradicionales. Esto simplifica a los testers la realización de las pruebas y la construcción del
proyecto para obtener los mejores resultados posibles.
Las pruebas no incrementales consisten en probar módulos de software. En este tipo, las pruebas
tienen lugar después de que todos los módulos hayan sido desarrollados y estén listos para su
integración. Se prueba todo el software a la vez.
Las pruebas no incrementales suelen conocerse como el enfoque de integración “big bang”.
● Enfoque Big-Bang: Implica compilar todos los módulos de software en una estructura y
evaluarla como una unidad. Los módulos individuales no se examinan por separado. Se
combinan y prueban en un único proceso.
Requiere una comunicación firme entre los equipos de desarrollo y de pruebas para identificar
y resolver adecuadamente cualquier problema detectado durante el procedimiento de
prueba. La estrategia big-bang puede ser más rápida y menos costosa que otros enfoques
alternativos, ya que los desarrolladores no necesitan pruebas incrementales.
Esta estrategia podría funcionar para sistemas de software con menos relaciones entre
componentes y menos complejas. Sin embargo, puede resultar difícil identificar el módulo
preciso cuando se descubren fallos durante las pruebas.
LTI – Plan 2024 15

Ventajas de las pruebas de integración
Al realizar las pruebas de integración, se examina cómo funciona el software completo como una
unidad, tal y como lo hará cuando la gente lo utilice. El enfoque basado en el contexto implica
examinar el entorno preciso en el que se utilizará el producto. Reconoce que el funcionamiento del
software depende de algo más que de sus componentes.
También depende de cómo interactúan estos componentes cuando se ven como un todo. Es algo
parecido a considerar cómo funciona un equipo en lugar de solo las habilidades de cada jugador.
● Validar el flujo de datos: Evalúa cómo se mueven los datos entre las distintas unidades y
servidores de bases de datos. Valida que los datos se transmiten con eficacia y sin
degradación. Esto reduce el riesgo de problemas relacionados con los datos en producción.
● Identificar dependencias externas: La mayoría de software utilizan recursos externos como

API o sistemas de terceros. Evalúa cómo interactúa el software con estas dependencias
mediante una simulación real. Esto ayuda a identificar cualquier problema de compatibilidad.
● Escenarios de prueba personalizados: Permite a los testers desarrollar escenarios de prueba

especializados que reflejen las propiedades únicas del software y las interfaces de usuario.
Esto permite una evaluación más precisa de las características críticas.
● Validación de la escalabilidad: Valida la escalabilidad utilizando una metodología basada en

el contexto. Se examina cómo las unidades interconectadas gestionan las crecientes cargas de
trabajo para garantizar que el sistema pueda soportar la expansión en el futuro.
LTI – Plan 2024 16

Prueba de Sistema
La prueba de sistemas es un tipo de prueba de software que realiza comprobaciones del sistema en
su conjunto. Comprueba si el sistema cumple sus requerimientos, sean cuales sean.
Consiste en integrar todos los módulos y componentes individuales del software que has desarrollado,
para comprobar si el sistema funciona conjuntamente como se esperaba.
Los testers realizan pruebas de sistemas para evaluar los requerimientos funcionales y no funcionales
del sistema una vez que se han integrado los módulos y componentes individuales.
Son una categoría de las pruebas de caja negra, lo que significa que sólo comprueban las
características externas de funcionamiento del software, en lugar de probar el diseño interno de la
aplicación.
Los encargados de las pruebas no necesitan conocer la programación ni la estructura del código del
software para evaluar por completo una compilación de software durante estas pruebas. En cambio,
los testers se limitan a evaluar el rendimiento del software desde la perspectiva de un usuario.
Son un paso esencial de las pruebas de software que permitirá a los equipos de pruebas verificar la
calidad de la creación antes de que se ponga a disposición de los usuarios finales.
¿Cuándo hay que probar el sistema?
Las pruebas del sistema se realizan después de las de integración y antes de las de aceptación. El
equipo de pruebas de software realiza pruebas periódicas del sistema para garantizar que funciona
como es debido en las fases clave del desarrollo.
Algunos ejemplos de ocasiones en las que se realizan pruebas de sistemas son:
● Durante el desarrollo de nuevas versiones de software.

● Durante el lanzamiento de la aplicación, cuando tienen lugar las pruebas alfa y beta.
● Una vez finalizadas las pruebas unitarias y de integración.
● Cuando los requerimientos de la construcción del sistema estén completos.
● Cuando se cumplen otras condiciones de prueba.
Al igual que otras formas de pruebas de software, se recomienda realizar pruebas del sistema con
regularidad para garantizar que el software funciona como debería.
La frecuencia con la que se pueden llevar a cabo las pruebas del sistema depende de los recursos de
su equipo y de los enfoques y herramientas que utilice para realizar las pruebas del software del
sistema.
LTI – Plan 2024 17

¿Quién participa en las pruebas del sistema?
Las pruebas del sistema las realizan los testers y los equipos de control de calidad, y no los
desarrolladores. Las pruebas de sistemas sólo tienen en cuenta los elementos externos del software
o, en otras palabras, la experiencia de los usuarios que intentan acceder a las funciones del software.
Esto significa que los testers que realizan pruebas de sistemas no necesitan conocimientos técnicos
de codificación informática, programación y otros aspectos del desarrollo de software que podrían
requerir la aportación de los desarrolladores.
La única excepción es el caso de las pruebas automatizadas del sistema, que podrían requerir la
participación de los desarrolladores en función de cómo se planteen.
¿Qué se prueba en las pruebas de sistemas?
La prueba de sistemas es un tipo de prueba de software que se utiliza para comprobar aspectos
funcionales y no funcionales del software.
Puede utilizarse para probar una enorme variedad de funcionalidades y características, muchas de las
cuales se tratan con más profundidad en el apartado de tipos de pruebas de sistemas.
A continuación se detallan algunos de los aspectos del software que verifican las pruebas del sistema.
● Funcionalidad: Los testers utilizan las pruebas del sistema para verificar si los distintos
aspectos del sistema completado funcionan como deberían. Las pruebas previas pueden
servir para evaluar la estructura y la lógica del código interno y cómo se integran entre sí los
distintos módulos, pero las pruebas del sistema son el primer paso que pone a prueba de este
modo la funcionalidad del software en su conjunto.
● Integración: Las pruebas de sistemas comprueban cómo funcionan juntos los distintos
componentes del software y si se integran sin problemas entre sí. Los testers también pueden
probar periféricos externos para evaluar cómo interactúan con el software y si funcionan
correctamente.
● Resultados esperados: Los testers utilizan el software como lo haría un usuario durante las
pruebas del sistema para verificar los resultados del software durante su uso habitual.
Comprueban si el resultado de cada característica funcional y no funcional del software es el
esperado. Si el software no se comporta como debería, la conclusión obvia es que requiere
más trabajo de desarrollo.
LTI – Plan 2024 18

● Fallos y errores: Las pruebas de sistemas se utilizan para evaluar la funcionalidad y fiabilidad
del software en múltiples plataformas y sistemas operativos. Los testers de sistemas verifican
que el software no tenga errores, problemas de rendimiento ni problemas de compatibilidad
en todas las plataformas en las que se espera que funcione.
¿Cuáles son los tipos de pruebas de sistema de software?
Existe un gran número de pruebas para evaluar el sistema de software, sin embargo, cada una de ellas
se aplican para medir aspectos específicos. Las siguientes son cinco de las más usadas en la industria.
1. Pruebas de rendimiento: ¿Qué ocurre cuando un sistema es sometido a una carga de trabajo más
allá de lo usual (como la saturación ejercida por los usuarios en una página web en periodos cortos de
tiempo)?
La respuesta a esta pregunta encuentra lugar mediante las pruebas de rendimiento, con las que se
registra el comportamiento del sistema al ser sometido a distintos niveles de estrés, ya sea bajo, medio
o alto.
Después de aplicar determinadas cargas se mide el tiempo de respuesta, con el objetivo de determinar
si el sistema responde dentro de los parámetros marcados. El resultado indica si el rendimiento del
producto de software es óptimo o si se recomienda realizar adecuaciones al producto.
2. Pruebas de regresión: Las aplicaciones están sujetas a constantes actualizaciones para mejorar la
experiencia de los usuarios. No obstante, esto implica cambios en el código fuente que puede
interferir en las funciones existentes.
Durante las pruebas de regresión se aplican algunos casos de prueba para comprobar que las nuevas
modificaciones no afecten en el resto del sistema.
En caso de no existir errores, el desarrollo del sistema puede continuar. Por el contrario, se debe
realizar una pausa en el desarrollo y corregir los fallos detectados.
3. Pruebas de seguridad: La seguridad es uno de los aspectos de mayor preocupación en los usuarios
al establecer contacto con una aplicación o plataforma en línea. Ya sea que intenten realizar una
compra o brindar sus datos personales para una banca digital, la información otorgada en la web
siempre se encuentra en vulnerabilidad.
Por ello, los desarrolladores deben garantizar que los datos de los usuarios se mantengan seguros,
mediante mecanismos de control de acceso evaluados durante las pruebas de seguridad.
4. Pruebas de sobrecarga: Las pruebas de sobrecarga se utilizan para medir la capacidad de respuesta
de un sistema ante cargas máximas. La compra simultánea de miles de usuarios en un sitio web o el
tráfico excesivo de un correo electrónico son algunos ejemplos usuales aplicados en este tipo de test.
5. Pruebas de usabilidad: La satisfacción del cliente es uno de los objetivos principales al crear un
producto informático, al ser la persona quien establecerá una relación directa con el sistema. Las
pruebas de usabilidad se encargan de que esto pueda garantizarse, al medir aspectos como la
eficiencia, precisión y facilidad de uso.
LTI – Plan 2024 19

Prueba de Aceptación
Las Pruebas de Aceptación del Usuario (UAT - User Acceptance Testing) es una fase crucial en el ciclo
de vida de desarrollo de software, donde los usuarios finales verifican que el software cumple con sus
requerimientos y expectativas. UAT es la etapa final de las pruebas antes de que el software se lance
al mercado o se implemente en el entorno de producción. Gracias a estas pruebas, el lanzamiento del
software contará con las garantías de calidad y funcionalidad necesarias.
Qué es el User Acceptance Testing (UAT)

Estas pruebas suponen un paso esencial en el desarrollo de software, por dos razones: porque son la
última prueba antes del lanzamiento; y, como tal, involucra directamente a los usuarios finales de
dicho software.
Las pruebas de aceptación de usuario son una forma de verificar si un producto o servicio cumple con
los requerimientos específicos de los clientes o usuarios finales. Cada software se construye en base
a requerimientos o necesidades específicas. Por ello, el propósito de una prueba UAT es garantizar
que se cumplan dichos requerimientos.
También es útil para el equipo de pruebas porque el usuario o cliente puede probar el software y
proporcionar comentarios para mejorarlo. Así se garantizará que el producto no solo sea de alta
calidad sino también relevante para los requerimientos del usuario.
Este tipo de prueba se realiza al final del desarrollo del proyecto, cuando se ha completado la
construcción y se está listo para su lanzamiento. El objetivo es asegurarse de que el producto funcione
de manera efectiva y cumpla con los requerimientos del usuario, lo que a su vez aumenta la confianza
en el producto antes de su lanzamiento al mercado.
Las pruebas de aceptación de usuario se realizan normalmente por los usuarios finales o clientes, ya
que ellos son los que conocen mejor sus requerimientos y necesidades. Sin embargo, también pueden
ser realizadas por un equipo de pruebas independiente o incluso por un equipo de aceptación de
usuario interno en la empresa.
Quién y cuándo debe hacer una prueba UAT

Como ya se ha dicho, las pruebas de aceptación o User Acceptance Testing están enfocadas a realizar
un último análisis y testeo del software antes de ser lanzado al mercado. Así, dos son los tipos de
perfiles que pueden desarrollar una prueba de aceptación de usuario:
● Equipo interno de desarrollo: puede realizar esta prueba de aceptación de usuario el propio
equipo de desarrollo, por medio de los profesionales expertos en las funcionalidades. Es una
prueba diferente a otras que se suceden durante el proceso de desarrollo, como la de sistema.
LTI – Plan 2024 20

● Cliente o usuarios finales: cuando se trata de un software de uso comercial, el cliente que lo
adquiere suele ser quien realiza la prueba UAT. También puede ser el proveedor de servicios
para ese desarrollo, o incluso los usuarios finales, en un entorno controlado de pruebas.
Se asegura de esta forma que el software cumpla con las especificaciones funcionales requeridas, pero
sobre todo, con los requerimientos de los usuarios finales en términos también de usabilidad. Así se
evitará lanzar productos de software incompletos o defectuosos.
Hay varios tipos de pruebas de aceptación de usuario, cada una de ellas con un enfoque diferente. Por
ejemplo, las pruebas funcionales se enfocan en verificar si el software cumple con los requerimientos
funcionales establecidos, mientras que las pruebas de rendimiento se enfocan en verificar la velocidad
y la eficiencia del software. Las pruebas de seguridad, por su parte, se enfocan en verificar la seguridad
del software y la protección de los datos.
Beneficios de realizar una prueba de aceptación de usuario

Desarrollar una prueba de aceptación de usuarios UAT proporciona varios beneficios y ventajas:
● Comprobar que el software cumple con su propósito: El propósito de cualquier producto de

software es que cumpla con unas necesidades específicas y cuente con funcionalidades que
resuelvan estas. Pero puede ocurrir que por una mala definición inicial o un proceso de
desarrollo que se desvía de los requerimientos iniciales, el producto final se aleje de lo
planteado inicialmente. Realizar pruebas UAT es una forma de verificarlo y tomar decisiones
sobre este. Las pruebas de UAT aseguran que se cumplan los requerimientos para los usuarios
finales y este resulte relevante para ellos.
● Garantizar una mayor calidad del producto: El UAT se centra en la prueba con los usuarios
reales, por lo que este punto de control resulta estratégico para comprobar si cumple el
propósito para el que fue diseñado. Desarrollar una prueba de aceptación de usuarios en una
fase Beta facilita que un grupo de usuarios pruebe el desarrollo y facilite comentarios para
poder detectar problemas sin esperar al lanzamiento final. Con un estudio UAT se ahorra
tiempo y dinero.
● Asegurar la satisfacción del usuario: El software se idea y diseña, para cumplir unas funciones
y enfocado a sus usuarios. Por lo tanto, qué mejor forma de asegurarlo que probando si este
cumple o no con sus expectativas. La prueba UAT ayudará a comprender los problemas que
surgen en el uso del mismo por parte de los usuarios y permitirá la detección de puntos
débiles, mejorar su experiencia de usuario y, por lo tanto, la satisfacción de estos usuarios.
LTI – Plan 2024 21

Actividades requeridas por estas pruebas

Si bien no existe un tipo de prueba universal, hay actividades/tareas de prueba comunes a todos.
● Planificación de la prueba:
○ Se realiza el Plan de Pruebas incluyendo:
■ Alcance, objetivos y riesgos de la prueba
■ Enfoque general de la prueba
■ Integrar/coordinar actividades de prueba en el SDLC
■ Quién y cómo se realizarán las pruebas
■ Calendario (cuándo). Fechas o momento en iteración
■ Métricas para monitorizar y controlar
■ Presupuesto
■ Nivel de detalle y estructura de de doc. de prueba
● Monitorización (seguimiento) y control de la prueba:

○ Actividades:
■ Seguimiento del progreso de las pruebas
■ Medición y reporte de resultados
■ Gestión de riesgos
■ Actualización del plan de prueba
■ Comunicación y colaboración
● Análisis de la prueba: Busca analizar la base de la prueba y definir los objetivos de la prueba
(qué probar)
○ Pasos:
■ Identificar la base de la prueba
■ Analizar la base de la prueba
■ Definir los objetivos de la prueba
● Diseño de la prueba: Responde a la pregunta de “cómo probar”

○ Transforma condiciones de prueba en:
■ Casos de prueba
■ Conjuntos de casos de prueba
■ Otros productos de prueba
LTI – Plan 2024 22

○ Actividades:
■ Diseñar / priorizar casos de prueba
● Uso de técnicas de pruebas
■ Identificar datos de prueba necesarios
● “Test Oracle”2
■ Diseñar el entorno de prueba
● Implementación de la prueba: Secuenciar casos de prueba en procedimientos de prueba

○ Actividades:
■ Desarrollar guiones de prueba (automatizados?)
■ Crear juegos de prueba
■ Armar un calendario de ejecución
■ Construir entorno de prueba
■ Preparar datos de prueba y cargarlos al entorno
● Ejecución de la prueba: Los juegos de prueba se ejecutan según el cronograma.

○ Actividades:
■ Versionar elementos de prueba
■ Ejecutar pruebas
■ Comparar resultados reales vs. esperados
■ Establecer causas probables de anomalías
■ Registrar resultados e informar defectos
■ Repetir pruebas
● Compleción de la prueba: Recopilar datos y consolidar la experiencia. En ágil se da al finalizar

una iteración.
○ Actividades:
■ Comprobar que informes de defectos están cerrados
■ Finalizar, archivar y almacenar todo
■ Traspaso de productos de prueba a mantenimiento
■ Analizar lecciones aprendidas
■ Mejorar proceso de prueba
2
En las pruebas de software, un oráculo nos ayuda a determinar si el resultado de una prueba es correcto o no.
LTI – Plan 2024 23

MTF - Módulo 3

Cargado por

Copyright:

Formatos disponibles

MTF - Módulo 3

Cargado por

Información del documento

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

MTF - Módulo 3

Cargado por

Copyright:

Formatos disponibles

Metodologías del Testing Funcional

LTI – Plan 2024 1

LTI – Plan 2024 2

En el contexto informático, un ambiente se refiere al hardware y software donde se ejecuta una

Normalmente hablamos de tres ambientes: Desarrollo, Testeo y Producción. En algunas ocasiones, se

En algunas empresas, se maneja un ambiente intermedio entre el ambiente de testeo y el ambiente

LTI – Plan 2024 3

Ambiente Independiente de Pruebas

 Tener bajo control la versión del aplicativo que se está probando:

o Si probáramos en el ambiente de desarrollo, el equipo de desarrollado podría cambiar la

o Si probáramos en el ambiente de producción, los defectos que nosotros detectamos (e

LTI – Plan 2024 4

TÉCNICAS, NIVELES Y TIPOS DE TESTEO1

 Sus objetivos genéricos,

LTI – Plan 2024 5

Son niveles de prueba, los siguientes:

 Testeo unitario: Testeo inicial de un código que pertenece a un módulo

LTI – Plan 2024 6

Se destacan dentro de este tipo de testeo, las siguientes categorías (o sub-tipos):

 Testeo de Recuperación y Respaldo

Por ejemplo, cuando verificamos que la forma de autenticación de un sistema no se ve afectada,

LTI – Plan 2024 7

TIPOS DE PRUEBAS FUNCIONALES

Pruebas de Componente / Unitarias / Unit Test

LTI – Plan 2024 8

Estas pruebas aisladas proporcionan cinco ventajas básicas:

● Separación de la interfaz y la implementación: Dado que la única interacción entre los

LTI – Plan 2024 9

● Completas: Deben cubrir la mayor cantidad de código.

● Rápidas: Deben poder ejecutarse en fracciones de segundo, caso contrario serán

● Independientes: La ejecución de una prueba no debe afectar a la ejecución de otra.

El entorno de prueba de los test unitarios

Frameworks de prueba para el unit testing

LTI – Plan 2024 10

● Usar herramientas diversas: Existen numerosas herramientas para implementar y ejecutar

LTI – Plan 2024 11

Pruebas Unitarias vs. Pruebas de Integración

Aspecto Pruebas Unitarias Pruebas de integración

Alcance Se concentran en unidades o módulos Evaluan la interacción de módulos

Interoperabilidad Las dependencias externas se Se requiere la integración con módulos

Velocidad Puesto que se concentra en unidades El tiempo de ejecución es un poco

LTI – Plan 2024 12

Tipos de Pruebas de Integración

Se pueden dividir en dos subtipos:

LTI – Plan 2024 13

● Integración Bottom-Up: Cuando se realizan pruebas bottom-up, primero se prueban los

LTI – Plan 2024 14

LTI – Plan 2024 15

Ventajas de las pruebas de integración

● Identificar dependencias externas: La mayoría de software utilizan recursos externos como

● Escenarios de prueba personalizados: Permite a los testers desarrollar escenarios de prueba

● Validación de la escalabilidad: Valida la escalabilidad utilizando una metodología basada en

LTI – Plan 2024 16

¿Cuándo hay que probar el sistema?

Algunos ejemplos de ocasiones en las que se realizan pruebas de sistemas son:

● Durante el desarrollo de nuevas versiones de software.

LTI – Plan 2024 17

¿Quién participa en las pruebas del sistema?

¿Qué se prueba en las pruebas de sistemas?

LTI – Plan 2024 18