Tester QA Manual

Módulo 1
Tipos
HTML5:y técnicas
Fundamentos Web
de pruebas
Tester QA Manual

Contenido
● Tipos de prueba.

● Pruebas funcionales.

● Niveles de prueba.

● Pruebas no funcionales.

● Pruebas estructurales y pruebas asociadas al cambio.

● Enfoque, tipos y técnicas de pruebas.

Tester QA Manual

Tipos de prueba
Cada requerimiento sobre el sistema de una Funcionales
empresa tiene cierta relevancia, criticidad,
urgencia y en función de ello, el Tester tendrá
que definir los tipos de prueba que aplicará. No funcionales
Tipos de
Esta elección depende de factores como el prueba
negocio en particular: seguramente al evaluar un Estructurales
sistema bancario se priorizarán ciertas pruebas y
sobre un videojuego, otros aspectos de la calidad.
Asociadas
Por ello será importante conocer los diferentes al cambio
tipos de prueba para discriminar cuál(es) elegir,
según el requerimiento del usuario.
Tester QA Manual

Pruebas funcionales

Esencialmente permiten evaluar “qué” hace el
sistema e incluye (según ISO-9126):
● Adecuación: Cuán adecuado es respecto a lo
solicitado por el usuario.
Verifican que el sistema, módulo o componente
realice lo que está establecido en los requeri-
mientos funcionales o casos de usos (UML).
Se pueden llevar a cabo en todos los niveles:

● Precisión / Exactitud: Cuán preciso es ● Componentes.

respecto a los cálculos.
● Integración.
● Cumplimiento de las funcionalidades.
● Sistemas.
● Interoperabilidad: Cuán capaz es de
● Aceptación.
interactuar con otros sistemas o plataformas.
Tester QA Manual

Pruebas no funcionales

Verifica los aspectos necesarios para el normal
funcionamiento del sistema, en cuanto a los
requerimientos técnicos o de IT. Las más típicas:
● Performance, Carga, Stress.
● Usabilidad.
Incluye la validación y verificación sobre “cómo”
se comporta el sistema.
Usualmente se deben ejecutar por medio del uso
de herramientas o diferentes elementos
tecnológicos.

● Mantenibilidad.

● Fiabilidad.

● Portabilidad.

● Preparación Operacional.

● Deployment.
Tester QA Manual

Pruebas estructurales

Verifican la arquitectura del sistema. Se enfocan

en cómo está hecho el sistema para, en función a
ello, probarlo.

Por ejemplo: Si un sistema basa su funcionalidad

en una arquitectura de servicios, es probable que
el Tester deba revisar el código fuente, servicios
web, base de datos y demás estructuras para
orientar sus pruebas a dar cobertura del sistema.
Tester QA Manual

Pruebas asociadas al cambio

Verifican el sistema luego de la resolución de

defectos. Se distinguen dos subtipos:

● Re-Test: Consiste en volver a probar algo que

falló (y fue corregido por el desarrollador) con
el objetivo de evaluar si ya funciona
correctamente.

● Regresión: Consiste en evaluar nuevamente

una funcionalidad para corroborar que siga
operativa, luego de la incorporación de un
cambio en el sistema.
Tester QA Manual

El dilema de la regresión
Es común que un cambio en un sistema producto
de un nuevo requerimiento, nueva funcionalidad,
o corrección, genere en el Tester la duda sobre
cuánta regresión será necesaria.

El Tester definirá cuántas pruebas adicionales

son necesarias para evaluar un cambio, en
función a:

● El impacto del cambio.

● La criticidad del sistema/funcionalidad.

● El tiempo que tiene para realizar las pruebas.

Tester QA Manual

Niveles de prueba
Las pruebas no son responsabilidad del
QA/Tester. Deben ocurrir desde el inicio del
desarrollo de los sistemas, e incluir a todos los
involucrados.
En las diapositivas que siguen, veremos en
detalle cada uno de los niveles de prueba.
En función al momento en el cual se llevan a
cabo, las pruebas tienen diferentes niveles.
Donde se busca siempre mejorar la calidad, por
medio de la evaluación continua de cada uno de
los productos de software que componen el
sistema.
Tester QA Manual

Incluye casos de uso* Pruebas de

SQA Team
Aceptación
Users
(Alfa / Beta)

Pruebas de Sistema SQA Team

Objetos:
Pruebas de Integración
clases, métodos. SQA Team
(Incrementar / Big Bang)

Pruebas de componentes Developers

* El Caso de Uso es uno de los tipos de diagramas utilizado por el Lenguaje Unificado de Modelado (UML).
Describe el comportamiento del sistema y muestra la reacción del sistema desde el punto de vista del usuario.
Tester QA Manual

Pruebas de componentes

Son las pruebas que se ejecutan sobre cada

uno de los componentes del sistema, desde un
método que puede hacer un cálculo, hasta una
validación de sobre un campo de un formulario.

Suelen ser ejecutadas por el desarrollador, por

medio de la implementación de scripts de prueba
y, en caso de identificarse desviaciones entre el
resultado esperado y obtenido, son resueltos
‘en caliente’.

Se suelen llevar a cabo dentro de las mismas

herramientas de desarrollo.
Tester QA Manual

Pruebas de integración

Son las que evalúan el funcionamiento de dos

o más componentes de un sistema. También se
utiliza para describir las pruebas para evaluar
dos capas del software. Por ejemplo, la ejecución
de pruebas de servicios web.

Cuando hay participación temprana, los Testers

suelen involucrarse y reportar formalmente
cualquier desviación en el comportamiento
esperado que se identifique. En su defecto las
ejecutan los desarrolladores.

Para ejecutar estas pruebas suelen utilizarse

herramientas.
Tester QA Manual

Pruebas de Sistema

Consiste en las pruebas que llevan a cabo los

Testers evaluando el sistema desde la mirada del
usuario final, es decir, desde la interfaz de
usuario.

Suele ser el nivel de pruebas más común y el que

más tiempo demanda. Cualquier desviación entre
el resultado esperado y obtenido, se reporta
formalmente a los desarrolladores.
Tester QA Manual

Pruebas de Aceptación

Son las pruebas que ejecutan los usuarios, con
el objetivo de comprobar que el sistema cumple
lo que fue solicitado. Cuentan con el soporte del
QA/Tester.
Éste es el único nivel de prueba donde no se
espera detectar alguna falla porque generaría
desconfianza en el usuario.
Mayormente se ejecutan bajo dos modalidades:
● Beta: Suele ser la primera versión del sistema
(no completa o no estable) y es validada por
un grupo reducido de usuarios en un ambiente
controlado.
● Alfa: Es la primera versión estable en el
ambiente de producción pero aún no validada
por los usuarios con lo cual continuará en
evaluación.
Tester QA Manual

Enfoques y tipos

Revisiones Caja blanca

Estático Dinámico

Inspecciones Caja negra

Basada en
experiencia
Tester QA Manual

Enfoque estático: tipos y técnicas

● Revisiones

● Inspecciones

Informe Casos
avance de uso
Documentos

Código Plan de
Procesos Fuente Pruebas

Casos de
Prueba
Producto
Tester QA Manual

Enfoque dinámico: técnicas de caja blanca

Cobertura de sentencias

Cobertura de decisión

Caja blanca

Cobertura de condición

Cobertura de camino
Tester QA Manual

Enfoque dinámico: técnicas de caja negra

Partición de equivalencias

Análisis de valores límite

Caja negra
Transición de estados

Tablas de decisión

Casos de Uso
Tester QA Manual

Partición de equivalencias Análisis de valor límite

Se aplica cuando el Tester debe evaluar campos
numéricos. Por ej.: para validar la edad de una
persona que debe ingresarse en un formulario.
Lo que propone la técnica es:
● Identificar los rangos válidos del campo
numérico.
Es una técnica que complementa la partición de
equivalencias.
Propone incluir casos de prueba adicionales, para
los valores límite de cada uno de los rangos
válidos e inválidos definidos.

● Identificar los rangos inválidos del campo

numérico.

Considerar un caso de prueba para un valor que

pertenezca a cada uno de los rangos
identificados.
Tester QA Manual
Transición de estados
Aplica para aquellas pruebas de sistemas que
involucren entidades/conceptos que puedan
tener comportamientos diferentes según el
caso, es decir, que puedan tener diferentes
estados.
Por ejemplo, al evaluar la funcionalidad en hacer
una llamada: La línea telefónica podría hacerla sin
problema cuando tiene saldo positivo, pero en caso
contrario, no será posible aún siendo la misma línea.
Lo que propone la técnica, es considerar por
funcionalidad datos que representen los
diferentes estados que puedan alterar el
comportamiento de la funcionalidad.
Tablas de decisión
Aplica para las pruebas de funcionalidades que
involucran varias reglas del negocio, que deben
cumplirse al mismo tiempo.
Por ej., un formulario donde deben cumplirse
diferentes validaciones sobre los campos.
Se propone incorporar casos de prueba:
● Un caso de prueba donde se cumplan todas
las reglas del negocio identificadas.
● Un caso de prueba adicional por cada regla
de negocio que se incumpla (una por vez)
para corroborar que está siendo validada.
Tester QA Manual

Casos de Uso

Establece como máxima que toda funcionalidad de un

sistema ha ser evaluado, porque es parte de lo que se ha
añadido o modificado. Como parte del requerimiento debe
ser validado y verificado, considerando al menos:

● Un caso de prueba positivo: Donde la funcionalidad

se complete. Por ejemplo: evaluar el registro de usuario,
ingresando datos válidos.

● Un caso de prueba negativo: Donde la funcionalidad

no se complete, por alguna validación o camino alterno
que lo impida. Por ejemplo: evaluar el registro de
usuario, sin ingresar los datos obligatorios.
Tester QA Manual

Enfoque dinámico: técnicas basadas en experiencia

Caja blanca
Dinámico
Caja negra

Pruebas exploratorias
Basada en experiencia
(Exploratory testing)

Predicción de errores
(Error guessing)
Tester QA Manual

Pruebas exploratorias

Se utiliza cuando no se cuenta con información

sobre el sistema o requerimiento a evaluar.

Consiste en tener un primer acercamiento con el

sistema, por medio de la navegación no guiada.
De esta forma se le podrá conocer con mayor
detalle y ayudará a identificar las posibles
pruebas que serán necesarias.

En su estructura más formal tiene tiempos

definidos que van entre 2-16 horas.
Tester QA Manual

Predicción de errores

Consiste en tomar de la experiencia de

proyectos o sprints anteriores, aquellas pruebas
que han fallado (en testing o en producción)
para incorporarlas como pruebas en futuros
procesos de prueba.

Cuando se presenta una falla, especialmente si

es recurrente, se logra identificar un ‘punto débil’
del sistema, con lo cual se recomienda incorporar
pruebas adicionales para evaluarla mejor.
Tester QA Manual

Revisión
● Repase los puntos vistos en la clase.

● Realice las preguntas necesarias al o la docente

antes de continuar.

● Realice los ejercicios de la práctica.

¡Sigamos
trabajando!