Aspecto psicológico

del Testing
 El testing es el proceso de ejecución
de un programa con la intención de
encontrar errores.

Aspecto psicológico del testing

 Aspecto psicológico del testing
Los seres humanos tienden a ser sumamente orientados a
objetivos y el establecimiento de la meta adecuada tiene
un efecto psicológico importante. Si nuestro objetivo es
demostrar que un programa no tiene errores, entonces,
subconscientemente estaremos dirigidos a esa meta, es
decir, tendemos a seleccionar los datos de prueba que
tienen una baja probabilidad de causar que el programa
falle.
Por otro lado, si nuestro objetivo es demostrar que un
programa tiene errores, nuestros datos de prueba
tendrán una mayor probabilidad de encontrarlos.

Aspecto psicológico del testing

 Más allá del desarrollador o el tester, las
tareas de prueba pueden ser realizadas
por personas que desempeñan un rol de
prueba específico u otro rol —por
ejemplo, clientes—.

Aspecto psicológico del testing

 Prueba independiente
La forma en que se implementa la independencia de la
prueba varía dependiendo del modelo de ciclo de vida de
desarrollo de software.
Por ejemplo, en el desarrollo ágil, los probadores pueden
formar parte de un equipo de desarrollo. En algunas
organizaciones que utilizan métodos ágiles, estos
probadores también pueden ser considerados parte de
un equipo de prueba independiente más grande.
Además, en dichas organizaciones, los propietarios de
producto pueden realizar la prueba de aceptación para
validar las historias de usuario al final de cada iteración.

Aspecto psicológico del testing

 Beneficios potenciales de la
independencia de la prueba
Es probable que los probadores independientes
reconozcan diferentes tipos de fallos en
comparación con los desarrolladores debido a sus
diferentes contextos, perspectivas técnicas y sesgos.

Un probador independiente puede verificar,

cuestionar o refutar las suposiciones hechas por los
implicados durante la especificación e
implementación del sistema.

Aspecto psicológico del testing

 Desventajas de la independencia de la prueba
Los desarrolladores pueden perder el sentido de la
responsabilidad con respecto a la calidad.

Los probadores independientes pueden ser vistos

como un cuello de botella o ser culpados por los
retrasos en el lanzamiento o liberación.

Los probadores independientes pueden carecer de

información importante —por ejemplo, sobre el
objeto de prueba—.

Aspecto psicológico del testing

Aspecto psicológico del testing
Casos de
prueba
 ¿Qué es un caso de prueba?

Es un documento escrito que

proporciona información escrita
sobre qué y cómo probar.

Casos de prueba
 Aprendamos a redactarlo…

Casos de prueba
 Características de un buen caso de prueba
Deben ser simples
Se deben crear casos de prueba que sean lo más simples posibles
ya que otra persona que no sea el autor puede ejecutarlos. Utilizar
un lenguaje asertivo para facilitar la comprensión y que la
ejecución sea más rápida.
El título debe ser fuerte
Solo leyendo el título, cualquier probador debería comprender el
objetivo del caso de prueba.
Tener en cuenta al usuario final
El objetivo final es crear casos de prueba que cumplan con los
requisitos del cliente y que sean fáciles de usar.

Casos de prueba
 Características de un buen caso de prueba (continuación)
No asumir
No asumir la funcionalidad y las características de la aplicación
mientras se prepara el caso de prueba. Se debe ser fiel a los
documentos de especificación y ante cualquier duda, hay que
consultar.
Asegurar la mayor cobertura posible
Escribir casos de prueba para todos los requisitos especificados.
Autonomía
El caso de prueba debe generar los mismos resultados siempre,
sin importar quien lo pruebe.
Evitar la repetición de casos de prueba
Si se necesita un caso de prueba para ejecutar otro, indicar el
caso de prueba por su ID.
Casos de prueba
 ¿Qué debe contener un caso de prueba?

Identificador Nombre del caso de Descripción

Puede ser numérico o prueba (conciso)
Debe decir qué se va a
alfanumérico. La mayoría de Se debe utilizar una probar, el ambiente de
herramientas lo generan nomenclatura que esté pruebas y los datos
automáticamente. definida, pero, si no existe, necesarios para
lo recomendable es incluir ejecutarlo.
el nombre de módulo al
que corresponde el caso
de prueba.

Casos de prueba
 ¿Qué debe contener un caso de prueba? (continuación)

Precondición Pasos Resultados esperados

Asunción que debe Son las acciones que Es lo que le indica al

cumplirse antes de se deben realizar para probador cuál debería
ejecutar el caso de obtener los resultados. ser la experiencia luego
de ejecutar los pasos y
prueba.
determinar si el test
falló o no.

Casos de prueba
Casos de prueba
 Ciclo de vida
de las pruebas
de software
No existe un proceso de prueba
único y universal, pero existen
actividades de prueba comunes que
nos ayudan a organizarnos para
alcanzar los objetivos establecidos.
El proceso de prueba en contexto

Algunos factores de contexto que influyen en el proceso de prueba son:

● Modelo de ciclo de vida de desarrollo de software y metodologías de
proyecto en uso.
● Niveles y tipos de prueba considerados.
● Riesgos de producto y de proyecto.
● Dominio del negocio.
● Restricciones operativas, incluyendo, pero no limitadas a:
○ Plazos
○ Complejidad
Tareas principales
El ciclo de vida de las pruebas de software consiste en las siguientes
actividades principales —aunque no siempre están agrupadas de
esta manera en todos los proyectos de software—:

Planificación Implementación

Seguimiento y control Ejecución

Análisis Conclusión

Diseño
Planificación
En esta actividad se definen los objetivos y el enfoque de la prueba dentro de las
restricciones impuestas por el contexto.
Algunas subactividades realizadas son:
● Determinar el alcance, los objetivos y los riesgos.
● Definir el enfoque y estrategia general.
● Integrar y coordinar las actividades a realizar durante el ciclo de vida del
software.
● Definir las especificaciones de técnicas, tareas de prueba adecuadas, las
personas y otros recursos necesarios.
Planificación

● Establecer un calendario de pruebas para cumplir con un plazo límite.

● Generar el plan de prueba.

Documentos de salida:
● Plan de prueba —general y/o por nivel de prueba—.
Seguimiento y control
El objetivo de esta actividad es reunir información y proporcionar retroalimentación y
visibilidad sobre las actividades de prueba. Como parte del control, se pueden tomar
acciones correctivas, como cambiar la prioridad de las pruebas, el calendario y
reevaluar los criterios de entrada y salida.

Algunas subactividades realizadas son:

● Comprobar los resultados y los registros de la prueba en relación con los criterios
de cobertura especificados.
● Determinar si se necesitan más pruebas dependiendo del nivel de cobertura que
se debe alcanzar.

Documento de salida:
● Informe de avance de la prueba.
Análisis
Durante esta actividad se determina “qué probar”.

Algunas subactividades realizadas son:

● Analizar la base de prueba correspondiente al nivel de prueba considerado
—información de diseño e implementación, la implementación del componente o
sistema en sí, informes de análisis de riesgos, etc.—.
● Identificar defectos de distintos tipos en las bases de prueba —ambigüedades,
omisiones, inconsistencias, inexactitudes, etc.—.
Análisis

● Identificar los requisitos que se van a probar y definir las condiciones de

prueba para cada requisito.
● Capturar la trazabilidad entre la base de prueba y las condiciones de prueba.

Documento de salida:
● Contratos de prueba que contienen las condiciones de prueba.
Diseño
Durante esta actividad se determina “cómo probar”.
Algunas subactividades realizadas son:
● Diseñar y priorizar casos de prueba y conjuntos de casos de prueba de alto
nivel.
● Identificar los datos de prueba necesarios.
● Diseñar el entorno de prueba e identificar la infraestructura y las herramientas
necesarias.
● Capturar la trazabilidad entre la base de prueba, las condiciones de prueba, los
casos de prueba y los procedimientos de prueba.
Documento de salida:
● Casos de prueba de alto nivel diseñados y priorizados.
Implementación
Se completan los productos de prueba necesarios para la ejecución de la prueba,
incluyendo la secuenciación de los casos de prueba en procedimientos de prueba.

Algunas subactividades realizadas son:

● Desarrollar y priorizar procedimientos de prueba.

● Crear juegos de prueba (test suite) a partir de los procedimientos de prueba.
● Organizar los juegos de prueba dentro de un calendario de ejecución.
● Construir el entorno de prueba y verificar que se haya configurado correctamente todo
lo necesario.
Implementación

● Preparar los datos de prueba y asegurarse de que estén correctamente cargados.

● Verificar y actualizar la trazabilidad entre la base de prueba, las condiciones de
prueba, los casos de prueba, los procedimientos de prueba y los juegos de prueba.

Documento de salida:
● Procedimientos y datos de prueba.
● Calendario de ejecución.
● Test suite.
Ejecución
Durante esta actividad se realiza la ejecución de los casos de prueba.

Algunas subactividades realizadas son:

● Registrar los identificadores y las versiones de los elementos u objetos de prueba.

● Ejecutar y registrar el resultado de las pruebas de forma manual o utilizando
herramientas.
● Comparar los resultados reales con los resultados esperados.
● Informar sobre los defectos en función de los fallos observados.
Ejecución
● Repetir las actividades de prueba, ya sea como resultado de una acción tomada
para una anomalía o como parte de la prueba planificada —retest o prueba de
confirmación—.
● Verificar y actualizar la trazabilidad entre la base de prueba, las condiciones de
prueba, los casos de prueba, los procedimientos de prueba y los resultados de la
prueba.
Documento de salida:
● Reporte de defectos.
● Informe de ejecución de pruebas.
 Conclusión

Se recopilan la información de las actividades

completadas y los productos de prueba. Puede ocurrir
cuando un sistema de software es liberado, un
proyecto de prueba es completado —o cancelado—,
finaliza una iteración de un proyecto ágil, se completa
un nivel de prueba o se completa la liberación de un
mantenimiento.
Conclusión
Algunas subactividades realizadas son:
● Comprobar que todos los informes de defecto están cerrados.
● Finalizar, archivar y almacenar el entorno de prueba, los datos de prueba, la
infraestructura de prueba y otros productos de prueba para su posterior
reutilización.
● Traspaso de los productos de prueba a otros equipos que podrían beneficiarse
con su uso.
● Analizar las lecciones aprendidas de las actividades de prueba completadas.
● Utilizar la información recopilada para mejorar la madurez del proceso de prueba.
Documento de salida:
● Informe resumen de prueba.
● Lecciones aprendidas.
API Testing - Colecciones
y variables de entorno
con Postman
 1. Colecciones
Índice 2. Variables de entorno
3. Runner para correr colecciones

Colecciones y variables de entorno

 1 Colecciones

Colecciones y variables de entorno

 Pasos para crear una Colección

1 Primero, se debe hacer clic en el botón ‘’Crear nueva Colección’’ dentro de

la pestaña colecciones.

Colecciones y variables de entorno

 Las colecciones son un grupo de
peticiones guardadas que
pueden organizarse en carpetas.
Esto nos permite agrupar y
administrar nuestras peticiones
de manera más eficiente.

Colecciones con Postman / Variables de Entorno

 Pasos

2 El siguiente paso es completar

los datos de la nueva colección.
¿Cómo?
1. Ingresa el nombre de la
colección.
2. Ingresa una descripción
para la misma (opcional).
3. Haz clic en CREAR para
crear la nueva colección.

Colecciones y variables de entorno

 Pasos
Puedes agregar cualquier número de peticiones a una colección. Solo debes
3 arrastrar la petición a la carpeta de la colección.

Colecciones y variables de entorno

 2 Variables de entorno

Colecciones y variables de entorno

 Variables de entorno en Postman
Solemos utilizar la misma solicitud varias veces
con datos diferentes. Postman nos permite
parametrizar estos datos y guardarlos en forma
de archivo o en variables de entorno.

Una variable de entorno se guarda en el

entorno de trabajo. Estas se pueden crear de
manera estática o dinámica.
Podríamos tener diferentes entornos para Dev,
QA y Producción, con sus respectivas variables.

Colecciones y variables de entorno

 Pasos para crear una variable de entorno

1 Primero, se debe hacer clic en el botón del ojo para crear nuestras
variables de entorno.

Colecciones y variables de entorno

 Pasos

2 El siguiente paso es completar los datos del entorno y de las variables. ¿Cómo?

a. Ingresa el nombre del entorno (DEV, QA o Producción).

b. Ingresa las variables de ese entorno. Para ello hay que completar el nombre
de la variable y su valor.
c. Finalmente haz clic en el botón Guardar para efectuar los cambios.

Colecciones y variables de entorno

 Pasos

3 Por último, se crean mediante el uso de llaves dobles con el nombre

de la variable a utilizar.

Colecciones y variables de entorno

 Runner para
3 correr colecciones

Colecciones y variables de entorno

 El runner nos permite ejecutar un
conjunto de test de diferentes
colecciones al mismo tiempo,
otorgando un informe de resultados.

Colecciones con Postman / Variables de Entorno

 Pasos para ejecutar el runner

1 Primero, se debe hacer clic en el botón Runner.

Colecciones y variables de entorno

 Pasos

2 El siguiente paso es completar los

datos de la ejecución ¿Cómo?
1. Seleccionamos las colecciones y
peticiones en las que deseamos
ejecutar sus test.
2. Seleccionamos el entorno en cual
deseamos correr nuestros test. De
esta manera se utilizaran las variables
relacionadas con ese entorno.
3. Indicamos la cantidad de veces que
vamos a correr los test.

Colecciones y variables de entorno

 Pasos

2 4. Puedes configurar el tiempo de

demora entre prueba.
5. Puedes seleccionar un archivo
para guardar sus pruebas y
resultados.
6. Se pueden guardar las cookies
para utilizarlas en otros test.
7. Haz click en el botón Empezar
Ejecución.

Colecciones y variables de entorno

 Pasos

3 Por último, podemos ver el resultado de nuestras ejecuciones.

Colecciones y variables de entorno

Colecciones y variables de entorno
 Debug o
depuración
 1. ¿Qué es “debug”?
2. Breakpoints
Índice 3. Debug en Chrome
4. Debug en Visual Studio Code

Debug o depuración 2
 ¿Qué es
1 “debug”?

Debug o depuración 3
 Llamamos debuggear o depurar
al proceso de encontrar, analizar y
remover las causas de fallos en el
software.
Se realiza la ejecución paso a paso
de cada instrucción del programa
para analizar las variables y sus
valores.

Debug o depuración
 2 Breakpoints

Debug o depuración 5
 Un breakpoint es un punto de
interrupción en nuestro código para
detener la ejecución del programa en
líneas específicas y analizar la situación
del mismo, revisando por ejemplo el
estado de las variables o de la pila de
llamadas en ese momento.

Debug o depuración 6
 Debug
Se puede realizar el debug de una aplicación utilizando:

➔ Las herramientas del desarrollador desde la consola del navegador, ej: Chrome
Dev Tools, Firefox Dev Tools
➔ La opción Debug dentro del framework o IDE utilizado para el desarrollo, ej:
Visual Code, Visual Studio.

Debug o depuración 7
 3 Debug en Chrome

Debug o depuración 8
 Debug desde la consola de Chrome
Se puede depurar código JavaScript directamente desde la consola de Chrome, siguiendo los
pasos a continuación:
1 Acceder a la consola de Chrome:
● haciendo clic derecho y seleccionando “Inspeccionar” o “Ctrl + Mayús + I”
● presionando la tecla F12(en algunas pcs)
● haciendo clic el menú lateral derecho, ir a “Más herramientas” y seleccionar “Herramientas
para desarrolladores”

Debug o depuración 9
 Debug desde la consola de Chrome(cont.)

2 Ir a la pestaña “Sources”, que cuenta

con 3 partes:
1. Navegador de archivos
2. Editor de código
3. El depurador de Javascript

Debug o depuración 10
 Debug desde la consola de Chrome(cont.)

3 Marcar el breakpoint en la línea de

código correspondiente, haciendo
clic en el número de la misma

Debug o depuración 11
 Debug desde la consola de Chrome(cont.)

4 Comenzando con alguna función

se inicializa el modo debug, por
ejemplo un click en un botón,
luego se puede presionar F11
para recorrer linea por linea y F8
para recorrer de un breakpoint a
otro.

También, se pueden utilizar los

comandos de la propia interfaz
que se verán a continuación:

Debug o depuración 12
 Interfaz de debug
Cuando abrimos el menú de debug tanto en Chrome como en el Visual Studio
nos despliega lo siguiente:
Chrome
● Continue/Resume
● Step over
● Step into Visual Studio
● Step out
● Restart
● Stop
Veamos cada parte en más detalle...

Debug o depuración 13
 Controles
Icono Función

Continue: Continua con la ejecución del código hasta el siguiente breakpoint.

Step over: Ejecuta la siguiente línea de código. Si es una función, la ejecuta y

retorna el resultado.

Step into: Ejecuta la siguiente línea de código, pero si es una función “entra” a
ejecutarla línea por línea.

Step out: Devuelve el debugger a la línea donde se llamó a la función.

Restart: Reinicia el debugger.

Stop: Frena el debug.

Debug o depuración 14
 Ejemplo

Debug o depuración 15
 4 Debug en Visual Studio

Debug o depuración 16
 Debug en Visual Studio
1 Dentro de la aplicación, Ir a la funcionalidad que se requiere depurar, desde el
explorador de soluciones

Debug o depuración 17
 Debug en Visual Studio(cont.)
2 Colocar un breakpoint en la línea de código requerida.

Breakpoint
Al hacer clic a la izquierda del número de Contenido
línea, establecemos un breakpoint. El contenido de nuestro código.

Número de línea
Nos indica el número de línea en el que está el código.

Debug o depuración 18
 Debug en Visual Studio(cont.)
3 Iniciar el Debug, haciendo clic en F5 o ingresando en Ejecutar(Run) -> Start Debugging

Debug o depuración 19
 Debug en Visual Studio(cont.)
Si es la primera vez que se va a realizar debugging sobre la aplicación, se debe ingresar al
menú “Add configuration…” y agregar la configuración de Chrome para ejecutar la
aplicación. Esto crea el archivo launch.json en el cual se debe configurar en “file” la
dirección del archivo .html que inicia la aplicación:

Debug o depuración 20
 Debug en Visual Studio(cont.)
4 Debido a que se utiliza Chrome para realizar el debugging, es necesario realizar una
acción en la aplicación

Debug o depuración 21
 Control de variables

Como podemos ver, en el breakpoint nuestra variable vale “2” y eso está
reflejado en el menú de debug a la izquierda.

Debug o depuración 22
Título del ppt
 ¿Qué tipos de
prueba se pueden
hacer en cada
ambiente?
 1. Pruebas según el ambiente
2. DEV
Agenda 3. QA
4. UAT
5. STG

Tipos de prueba
 Pruebas según el
1 ambiente

Tipos de prueba
 Tipos de prueba
según ambiente DEV DEV
-Pruebas unitarias o de
5
PROD 1 componente
-Pruebas de integración
STG AMBIENTE
-Pruebas de mantenimiento DE PRUEBA QA
-Pruebas de seguridad 4 2 QA
-Pruebas funcionales
-Pruebas de rendimiento
STG 3
-Pruebas de casos de uso
-Pruebas de carga, estrés y -Pruebas de exactitud
escalabilidad -Pruebas de adecuación
-Pruebas de infraestructura
UAT -Pruebas de sistema
-Pruebas de gestión de la -Pruebas de regresión
-Pruebas de confirmación
memoria, compatibilidad e UAT - Pruebas de Humo
interoperabilidad -Pruebas de aceptación - Pruebas de Cordura
-Pruebas de migración de -Pruebas exploratorias
datos -Pruebas de usabilidad
-Pruebas de accesibilidad

Tipos de prueba
 En las siguientes pantallas no desarrollaremos el ambiente
PROD debido a que:

➔ En general, los probadores no tienen acceso a este ambiente.

➔ En el caso de tener acceso y realizar pruebas:
◆ No se deben realizar acciones que generen datos.
◆ Se corre el riesgo de ingresar datos basura.
◆ Se interfiere en los datos de seguimiento.

Tipos de prueba
 2 DEV

Tipos de prueba
 DEV
Pruebas unitarias o de componente: También se conocen
como pruebas de módulo. Se centra en los componentes que
se pueden probar por separado. Tiene como objetivo
encontrar defectos en el componente y verificar que los
comportamientos funcionales y no funcionales del
componente son los diseñados y especificados.

Pruebas de Integración: Se centra en las interacciones entre

componentes o sistemas. Los objetivos de la prueba de
integración incluyen encontrar defectos en las propias
interfaces o dentro de los componentes o sistemas y verificar
que los comportamientos funcionales y no funcionales de las
interfaces sean los diseñados y especificados.

Tipos de prueba
 3 QA

Tipos de prueba
 QA
Pruebas funcionales: 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 y especificaciones
funcionales. También pueden estar sin documentar.

Pruebas de casos de uso: Proporcionan pruebas

transaccionales, basadas en escenarios, que deberían emular
el uso del sistema.

Pruebas de exactitud: Comprenden el cumplimiento por

parte de la aplicación de los requisitos especificados o
implícitos y también puede abarcar la exactitud de cálculo.

Tipos de prueba
 QA
Pruebas de adecuación: Implican evaluar y validar la
eficiencia de un conjunto de funciones para la consecución de
las tareas especificadas previstas. Estas pruebas pueden
basarse en casos de uso.

Pruebas de sistema: 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.

Tipos de prueba
 QA
Pruebas de regresión: Implican la realización de pruebas
para detectar efectos secundarios no deseados, luego de
cambios hechos en una parte del código que puedan afectar
accidentalmente el comportamiento de otras partes del
código.

Pruebas de confirmación: Consiste en volver a ejecutar los

pasos para reproducir el fallo o los fallos causados por un
defecto en la nueva versión de software, una vez corregido el
defecto, para así confirmar que el defecto original se ha
solucionado satisfactoriamente o detectar efectos secundarios
no deseados.

Tipos de prueba
 QA
Pruebas de cordura: Es una prueba de regresión acotada que
se centra en una o unas pocas áreas de funcionalidad. Se
utiliza para determinar si una pequeña sección de la aplicación
sigue funcionando después de un cambio menor.

Pruebas de humo: Se lleva a cabo un smoke test para

asegurar si las funciones más importantes de un programa
están trabajando correctamente, pero sin molestarse con los
detalles más finos.

Tipos de prueba
 4 UAT

Tipos de prueba
 UAT
Pruebas de aceptación: Se centra normalmente en el
USER
comportamiento y las capacidades de todo un sistema o
producto. Además, pueden producir información para evaluar
ACCEPTANCE
el grado de preparación del sistema para su despliegue y uso
por parte del cliente (usuario final). UAT
TESTING
Pruebas exploratorias: Se diseñan, ejecutan, registran y
evalúan de forma dinámica pruebas informales (no
predefinidas) durante la ejecución de la prueba. Los resultados
de la prueba se utilizan con el objetivo de aprender más sobre
el componente o sistema y crear pruebas para las áreas que
pueden necesitar ser probadas con mayor intensidad.

Tipos de prueba
 UAT
Pruebas de usabilidad: Evalúan la facilidad con la que los
usuarios pueden utilizar o aprender a utilizar el sistema para
lograr un objetivo específico en un contexto dado.

Pruebas de accesibilidad: Incluyen y evalúan la accesibilidad

que presenta un software para aquellos con necesidades
particulares o restricciones para su uso. Esto incluye a aquellos
usuarios con discapacidades.

Tipos de prueba
 5 STG

Tipos de prueba
 STG
Pruebas de mantenimiento: Se centra en probar los cambios en el
sistema, así como en probar las piezas no modificadas que podrían
haberse visto afectadas por los cambios. El mantenimiento puede incluir
lanzamientos planificados y no planificados.
Pruebas de seguridad: Las pruebas de seguridad se podrían definir
como el conjunto de actividades que se llevan a cabo para encontrar
fallas y vulnerabilidades en el sistema, buscando disminuir el impacto de
ataques y pérdida de información importante.
Pruebas de rendimiento: Se implementan y se ejecutan para evaluar
las características relacionadas con el rendimiento del destino de la
prueba, como los perfiles de tiempo, el flujo de ejecución, los tiempos de
respuesta y la fiabilidad y los límites operativos. También se pueden
realizar en STG.

Tipos de prueba
 STG
Pruebas de carga, estrés y escalabilidad: Una prueba de carga
garantiza que un sistema pueda controlar un volumen de tráfico
esperado. Una prueba de estrés es en la que se somete al sistema a
condiciones de uso extremas para garantizar su robustez y
confiabilidad. Las pruebas de escalabilidad garantizan la escalabilidad
de un sistema, es decir, que pueda soportar el incremento de demanda
en la operación. También se pueden realizar en QA encontrando el
correspondiente escalar con respecto a un ambiente de PROD.
Pruebas de infraestructura: Incluyen todos los sistemas informáticos
internos, los dispositivos externos asociados, las redes de Internet, la
nube y las pruebas de virtualización.
Pruebas de gestión de la memoria: Evalúan el estado y la integridad
de la memoria del sistema para identificar problemas potenciales.

Tipos de prueba
 STG
Pruebas de compatibilidad: Incluyen las pruebas para comprobar
que el sistema es compatible con todos los navegadores de Internet y
todos los sistemas operativos del mercado.

Pruebas de interoperabilidad: Se refieren a aquellas donde se

realiza la evaluación de la correcta integración entre distintos
aplicativos, sistemas, servicios o procesos que conforman una
plataforma o solución tecnológica.

Pruebas de migración de datos: Incluyen las pruebas realizadas al

transferir datos entre tipos de dispositivos de almacenamiento,
formatos o sistemas de cómputo.

Tipos de prueba
Tipos de prueba
Gestión de defectos
 1. Proceso general
2. Escribir un informe
Índice de defectos

Gestión de defectos
 Proceso
1 general

Gestión de defectos
 Proceso de gestión de defectos
02 Registrar
Varía según el contexto del
Detectar
componente o sistema, nivel de
prueba y modelo de desarrollo
elegido.

01 03

Clasificación/
Resolución Investigación y
04 seguimiento

Gestión de defectos
 Objetivos

Brindar información sobre Proporcionar a los jefes de Dar ideas para la

cualquier evento adverso que prueba un medio para mejora de los procesos
haya ocurrido, para poder hacer un seguimiento de la de desarrollo y prueba.
identificar efectos específicos, calidad del producto de
aislar el problema con una
trabajo y del impacto en la
prueba de reproducción
prueba.
mínima y corregir los defectos
potenciales.

Gestión de defectos
 Escribir un informe
2 de defectos

Gestión de defectos
 ¿Cómo escribir un buen informe?
Si el defecto se reporta eficientemente, las
probabilidades de que sea solucionado
rápidamente es mayor. Entonces, la solución de
un defecto dependerá de la eficiencia con que se
reporte.

Gestión de defectos
 ¿Qué condiciones debemos tener en cuenta?

Los bugs deben tener Una falla debe ser reproducible

identificadores únicos. para reportarla.
Si bien muchas herramientas de bug Si el defecto no es reproducible, no es
tracking asignan automáticamente un un defecto. Para defectos que ocurren en
ID único a los bugs, muchas veces se forma aislada, podemos realizarnos una
reportan fallas por medio de e-mails, nota personal para investigar luego y
saltando la registración en la determinar qué condiciones deben ser
herramienta. dadas para que el mismo se produzca.

Gestión de defectos
 Reportar cada paso realizado
Ser específico.
para reproducirlo.
No se debe escribir suposiciones o
Toda la información que podamos
ideas sobre lo que está ocurriendo u
darle al desarrollador para que pueda
otra cosa que no sea la información reproducir la falla siempre será
relevante para poder reproducir el bienvenida, no debemos obviar
defecto. ningún paso que sea relevante para
llegar al error en cuestión.

Gestión de defectos
 ¿Cuáles son los problemas más comunes
con los informes de defectos?
● Redactar un defecto de manera excesivamente coloquial y ambigua.

● Dar solo una captura del defecto sin indicar qué se estaba haciendo cuando sucedió.

● No incluir en la descripción del defecto cuál era el resultado esperado para los pasos
realizados.

● No determinar un patrón con el cual el defecto ocurre antes de reportar el mismo

—es importante para ser directos en cuál es el problema—.

● No leer el defecto reportado siguiendo los pasos uno mismo para ver que la
descripción es clara.

● No incluir información que dada las características del defecto, la misma es de

relevancia.
Gestión de defectos
Gestión de defectos
API Testing -
Métodos GET
Y POST
 1. Método GET
Índice 2. Método POST

API Testing - Métodos GET y POST

 1 Método GET

API Testing - Métodos GET y POST

 Testing método GET

Vamos a aprender a aplicar pruebas a los

diferentes métodos HTTP.
Utilizaremos una solicitud GET para recuperar
información de una URL específica y analizar la
información obtenida a partir de los test.
En el ejemplo analizaremos la obtención de
usuarios desde un API externa.

API Testing - Métodos GET y POST

 Pasos

1 Primero, debemos crear una nueva solicitud en Postman.

Para realizarlo, se debe hacer clic en la pestaña ‘’New’’.

API Testing - Métodos GET y POST

 Pasos

2 El siguiente paso es crear la solicitud. ¿Cómo?

1. Configura su solicitud HTTP en GET.

2. Ingresa el enlace en la URL de la solicitud
(https://jsonplaceholder.typicode.com/users)
3. Haz clic en ENVIAR para mandar la solicitud al servidor que aloja la URL.

API Testing - Métodos GET y POST

 Pasos

3 Cuando aparezca el mensaje 200 OK significa que se la

solicitud se realizó correctamente.

API Testing - Métodos GET y POST

 Resultados
Podemos ver varios datos relacionados a la respuesta del servidor

1. Response: es la información
en plano devuelta por el
servidor. Con esto podemos
dar una revisión temprana
de los datos de la aplicación.
2. Tiempo y tamaño de la
respuesta: con estos datos
podemos ver si el sistema
está cumpliendo uno de los
requisitos no funcionales, tal
como el rendimiento.

API Testing - Métodos GET y POST

 Resultados

3. Código de respuesta:
cuando solicitas información al
servidor, este puede contestar
distintos códigos de estado que
te informan qué pasó con tu
solicitud.
El código 200 nos indica que la
solicitud se realizó con éxito.

API Testing - Métodos GET y POST

 Resultados
Un API nos devuelve
diferentes códigos de
respuesta que nos
informan qué pasó con la
petición. Estas respuestas
se agrupan en cuatro
clases.
En la imagen podemos
ver las diferentes clases y
su significado.

Códigos 200 Códigos 300 Códigos 400 Códigos 500

respuestas redirecciones error del error del
exitosas cliente servidor

API Testing - Métodos GET y POST

 Resultados

4. Cookies: nos permiten

ver la información
relacionada con la sesion.

API Testing - Métodos GET y POST

 Resultados

5. Headers: información
sobre la solicitud
procesada.

API Testing - Métodos GET y POST

 2 Método POST

API Testing - Métodos GET y POST

 Testing método POST

Cuando necesitamos agregar datos a nuestra

aplicación utilizamos el método POST para
enviar estos datos. A través de esta solicitud
enviamos los datos y el API nos devuelve una
respuesta que valida que la creación sea
exitosa. En el ejemplo veremos la creación de
un usuario y la respuesta del API.

API Testing - Métodos GET y POST

 Pasos
1 Al igual que con el método GET, se debe crear una nueva solicitud en
Postman. Entonces, debemos hacer clic en la pestaña ‘’New’’.

API Testing - Métodos GET y POST

 Pasos
2 El siguiente paso, es crear la solicitud. ¿Cómo?

1. Configurar su solicitud HTTP en POST.

2. Ingresar el enlace en la URL de la solicitud
(https://jsonplaceholder.typicode.com/users).

API Testing - Métodos GET y POST

 Pasos {
"id": 11,
"name": "Usuario SM",
"username": "stm",
"email": "[email protected]",
3. Los datos para una petición POST no "address": {

se los pasa por la url porque no "street": "X Roads",

"suite": "Apt. 007",
viajan seguros: se pasan por el "city": "Hyderabad",
BODY. Lo podemos enviar de "zipcode": "600007",
"geo": {
diferentes formas: { "lat": "10.0000",
} "lng": "80.0000"

Raw: se envía la información

}
● },
como una cadena tipo texto, a "phone": "1-2345-6-7890",

través de un archivo tipo JSON. "website": "digitalhouse.com",

"company": {
● x-www-form-unlencoded: se "name": "Testing I",
envían los datos como si fuera "catchPhrase": "A blog for Software Testers",

un formulario.
"bs": "real-time tutorials"
}
}

API Testing - Métodos GET y POST

 Pasos
4. En este ejemplo enviaremos
los datos en formato Raw.
Para ello haz clic en el cuerpo
de la solicitud y selecciona la
opción “raw” (a), luego “Json”
(b). Finalmente copia y pega
el ejemplo brindado en la
diapositiva anterior en el
body (c).

API Testing - Métodos GET y POST

 Pasos

5. Haz clic en ENVIAR para mandar la solicitud al servidor que aloja la URL.

API Testing - Métodos GET y POST

 Pasos
Si aparece el mensaje 201 CREATED, significa que se la solicitud
3 se realizó correctamente.

API Testing - Métodos GET y POST

 Resultados
Podemos ver varios datos relacionados a la respuesta del servidor

1. Response: es la información
en plano devuelta por el
servidor, la cual nos sirve para
validar si la creación fue
exitosa.
Generalmente este método
devuelve los datos del usuario
creado o un mensaje de
creación exitosa.

API Testing - Métodos GET y POST

 Resultados
Podemos ver varios datos relacionados a la respuesta del servidor

2. Tiempo y tamaño de la
respuesta: con estos datos
podemos ver si el sistema está
cumpliendo uno de los
requisitos no funcionales, tal
como el rendimiento.

API Testing - Métodos GET y POST

 Resultados
Podemos ver varios datos relacionados a la respuesta del servidor

3. Código de respuesta: cuando

solicitas información al
servidor, este puede contestar
distintos códigos de estado
que te informan qué pasó con
tu solicitud. El código de
respuesta 201 nos indica que
la creación fue exitosa.

API Testing - Métodos GET y POST

API Testing - Métodos GET y POST
Introducción a
Unit testing /
Prueba de
componentes
 1. Generalidades
Índice 2. Frameworks

Unit Testing
 1 Generalidades

Unit Testing
 El objetivo principal es aislar cada
unidad del sistema para identificar,
analizar y corregir los defectos.

Unit Testing
 Generalidades
La prueba de componente, a menudo, se realiza de forma aislada del resto del
sistema, dependiendo del modelo de ciclo de vida de desarrollo de software y del
sistema, lo que puede requerir objetos simulados, virtualización de servicios,
arneses, stubs y controladores.
Este tipo de pruebas puede cubrir:

1. La funcionalidad: por ejemplo, la exactitud de los cálculos.

2. Las características n
3. o funcionales: por ejemplo, la búsqueda de fugas de memoria Las
propiedades estructurales: por ejemplo, pruebas de decisión.

Unit Testing
 Proceso
En general, cuando no se sigue un enfoque
<Your Code>
TDD, el proceso es el siguiente: Modify & Fix
1. Se crea el código del software.
2. Se definen los resultados esperados. Expected Result

3. Se ejecuta el test.
a) Si el test pasa, se confirma el Automate
Test
resultado esperado. & Simplicity
b) Si el test falla, se modifica el
código para solucionar el defecto
Success/ Confirmation Failure
encontrado

Lo ideal es automatizar los test para poder simplificar el proceso de prueba.

Unit Testing
 Ventajas
Estas son algunas de las ventajas de realizar pruebas de componente o unit test
dentro de un proyecto:

Reduce el costo de las Mejora el diseño y código

pruebas, ya que los del software debido a que
defectos se capturan en permite una mejor
una fase temprana. refactorización del mismo.

Unit Testing
 Ventajas

Reduce los defectos en las En modelos de desarrollo incrementales e

funciones recientemente iterativos donde los cambios de código son
desarrolladas o reduce los continuos, la prueba de regresión de
errores al cambiar la componente automatizada juega un
funcionalidad existente. papel clave en la construcción de la
confianza en que los cambios no han
dañado a los componentes existentes.

Unit Testing
 Las pruebas unitarias inapropiadas harán que los
defectos se propaguen hacia pruebas de nivel
superior y esto conducirá a un alto costo de
reparación de defectos durante las pruebas del
sistema, las pruebas de integración e incluso las
pruebas de aceptación de usuario. Si se realizan las
pruebas unitarias adecuadas en el desarrollo inicial,
al final se ahorra esfuerzo, tiempo y dinero.

Unit Testing
 2 Frameworks

Unit Testing
 Frameworks
Las pruebas unitarias pueden ser de dos tipos:

Manuales Automatizadas
Se puede emplear un Se necesita de un framework
documento instructivo automatizado para escribir los
paso a paso. scripts de prueba.

Unit Testing
 ¿Qué se necesita para automatizar los unit test?
TEST RUNNER ASSERTION LIBRARY

Es una herramienta Es una herramienta que se

que ejecuta los test y utiliza para validar la lógica de
muestra los resultados prueba, las condiciones y
en forma de reporte. resultados esperados.

Por eJemplo: Mocha Por ejemplo: Chai

(https://mochajs.org/) (https://www.chaijs.com/guide/)

JEST es un framework que incluye tanto el test runner como la assertion library

Unit Testing
 Frameworks más utilizados
Junit: herramienta de prueba de uso gratuito que se utiliza para el lenguaje
de programación Java. Proporciona afirmaciones para identificar el método
de prueba. Esta herramienta prueba los datos primero y luego los inserta
en el fragmento de código.

NUnit: es un marco de trabajo de pruebas unitarias ampliamente utilizado

para todos los lenguajes .net. Es una herramienta de código abierto y
admite pruebas basadas en datos que pueden ejecutarse en paralelo.

JMockit: es una herramienta de prueba unitaria de código abierto. Es una

herramienta de cobertura de código con métricas de sentencia y decisión.
Permite hacer mocks de API con sintaxis de grabación y verificación. Esta
herramienta ofrece cobertura de sentencia, cobertura de decisión y
cobertura de datos.

Unit Testing
 Frameworks más utilizados
EMMA : es un conjunto de herramientas de código abierto para
analizar y reportar código escrito en lenguaje Java. Emma admite
tipos de cobertura como método, sentencia, bloque básico. Está
basado en Java, por lo que no tiene dependencias de bibliotecas
externas y puede acceder al código fuente.

PHPUnit: es una herramienta de prueba unitaria para

programadores PHP. Toma pequeñas porciones de código que se
denominan unidades y prueba cada una de ellas por separado. La
herramienta también permite a los desarrolladores usar métodos
de confirmación predefinidos para afirmar que un sistema se
comporta de cierta manera.

Unit Testing
 Framework para JavaScript
Para JavaScript vamos utilizar el framework JEST. Si queremos configurarlo,
debemos instalar:

1. NodeJS (https://nodejs.org/)
2. Un IDE (el recomendado es Visual Studio Code -
https://code.visualstudio.com/)
3. JEST (https://jestjs.io/)

Unit Testing
Unit Testing
Introducción
a Selenium
 1. ¿Qué es Selenium?
Índice 2. Selenium IDE

COLECCIONES Y VARIABLES DE ENTORNO

 1 ¿Qué es Selenium?

Introducción a Selenium
 ¿Qué es Selenium?

Fue desarrollado por Jason Huggins en 2004. Es un framework destinado a la automatización

web que consiste en desarrollar scripts que, mediante algún lenguaje de codificación
determinado, permite ejecutar un flujo de navegación fijo. De este modo, garantiza que el
comportamiento de dicho flujo se conserve a lo largo de la vida de la página web.

Introducción a Selenium
 ¿Qué es Selenium?
Selenium es una herramienta de código abierto para la automatización de pruebas de
navegadores web. Proporciona la posibilidad de grabar y/o reproducir, editar y depurar casos
de pruebas que permitirán ejecutarlas repetidamente cuando sea necesario. Selenium ofrece
tres productos con distintos propósitos:

Introducción a Selenium
 Selenium IDE

Selenium IDE (Integrated Development Environment -

Entorno de Desarrollo Integrado): este componente
es una herramienta de automatización que nos
permite grabar, editar y depurar pruebas, sin la
necesidad del uso de un lenguaje de programación.
También se lo conoce como Selenium Recorder.

Introducción a Selenium
 Selenium WebDriver
Es una herramienta que permite automatizar pruebas UI
(User Interface) o interfaz de usuario de aplicaciones web.
Algunos de los lenguajes que soportan Selenium
WebDriver Java, C#, Python, Ruby, PHP, JavaScript.
Es útil para poder simular la manera en que los usuarios
reales interactúan con alguna aplicación web. Para ello,
Selenium WebDriver provee una serie de métodos para
accionar y validar cualquier elemento dentro de una
interfaz gráfica.

Introducción a Selenium
 Selenium Grid
Permite diseñar pruebas automatizadas para aplicaciones web
en diversas plataformas. Asimismo, posibilita la ejecución de
pruebas en diversos servidores en paralelo. Es por esto por lo
que reduce el tiempo de ejecución y el costo, debido a la
ejecución de las pruebas en varios navegadores y en diversos
sistemas operativos. Selenium Grid cuenta con dos
componentes: Selenium Hub y Remote Control.

Introducción a Selenium
 2 Selenium IDE

Introducción a Selenium
 Selenium IDE
Se trata de un entorno de pruebas de software para aplicaciones basadas en la web
que permite realizar tareas de Record&Play de flujos de pruebas.
Los flujos grabados quedan contenidos en un script que se puede editar y
parametrizar para adaptarse a los diferentes casos, y lo que es más importante, su
ejecución se puede repetir tantas veces como se quiera.

Su principal objetivo es automatizar pruebas funcionales repetitivas para luego facilitar

el trabajo del tester, como también pruebas de regresión.

Permite referenciar objetos del DOM en base al ID, CSS, nombre o a través de XPath.

Asimismo, las acciones pueden ser ejecutadas paso a paso.

Introducción a Selenium
 Selenium IDE - Instalación
1 Descargar Selenium IDE para Chrome:
https://www.selenium.dev/selenium-ide

Introducción a Selenium
 Selenium IDE - Instalación
2 Presionar la opción “Añadir a Chrome”.

Introducción a Selenium
 Selenium IDE - Instalación
3 Ejecutar Selenium IDE desde el panel de la aplicación:

Introducción a Selenium
 Selenium IDE - Ejemplo Record & Play

En esta oportunidad vamos a crear/grabar el caso de

prueba de login de Facebook. Para ello debemos
realizar los siguientes pasos:

1. Presionar del navegador, la opción.

2. Seleccionar la opción “Record a new test
in a new project”.

Introducción a Selenium
 Selenium IDE - Ejemplo Record & Play
3. Ingresar nombre del proyecto.

Introducción a Selenium
 Selenium IDE - Ejemplo Record & Play
4. Ingresar URL de la página web y
presionar la opción “Start Recording”
para iniciar la grabación de la prueba:

Introducción a Selenium
 Selenium IDE - Ejemplo Record & Play
5. Se abrirá el navegador con la página web indicada. Para nuestro ejemplo,
posicionarse en el campo “Correo electrónico” e ingresar un mail. Luego, en
el campo contraseña, ingresar una, y por último, hacer clic en “Iniciar sesión”.
Por último, presionar la opción STOP de Selenium IDE e ingresar el nombre
del caso de prueba.

Introducción a Selenium
 Selenium IDE - Ejemplo Record & Play
A continuación se adjunta video con los pasos realizados para grabar el caso
de prueba de login de Facebook.

https://drive.google.com/file/d/1EKCu7rPBx7HSf5T_mo_p3V62en_8npT0/view?
usp=sharing

Introducción a Selenium
 Selenium IDE - Ejemplo Record & Play

En esta grilla se visualizan:

● Comandos: son las acciones realizadas en la grabación.

● Target: son los localizadores de elementos web en la página web. Hay diferentes formas de
ubicar elementos: ID, ClassName, Name, TagName, LinkText, PartialLinkText, Xpath, CSS
Selector, DOM.
● Value: este campo es un valor simple, almacenado en ese elemento web y obtenido durante
la grabación. También se puede establecer un nuevo valor para pruebas siguientes.

Introducción a Selenium
 Selenium IDE - Ejemplo Record & Play
Hay distintas formas de localizar los elementos en la web. Puede ser por id o name entre
otros. En el ejemplo del login vemos que se localizan por el id:

Introducción a Selenium
 Selenium IDE - Ejemplo Record & Play
Podemos observar que se localizó el botón de inicio de sesión con id. Al reproducir este
caso de prueba, una vez que llega a ejecutarlo entra en un lapso sin dar respuesta. Por lo
tanto, se asume que se localizó de manera incorrecta el elemento, en este caso, el botón de
inicio de sesión.

Este caso de componentes de páginas web que tienen un id dinámico se presenta con
frecuencia. Para resolver esta inconsistencia se debe buscar otro forma de ubicar el
componente.

Introducción a Selenium
 Selenium IDE - Ejemplo Record & Play
Se debe inspeccionar el elemento y validar, si es posible, la localización por otro
parámetro. En este caso, se puede localizar por name. Entonces, en Selenium se
debe modificar el target a name:

WEB

Selenium

Introducción a Selenium
Introducción a Selenium
 Matchers más
usados con Jest
 Matchers en Jest
Jest usa los matchers para probar los diferentes valores que puede tener el código.
Vamos a partir de un ejemplo de una porción de código desarrollada que permite
realizar las operaciones matemáticas básicas y aplicarle diferentes matchers:

export const sumar = (a, b) => a + b;

export const restar = (a, b) => a - b;
export const multiplicar = (a, b) => a * b;
export const dividir = (a, b) => a / b;

Matchers - Jest
 .toBe
Usado para comparar valores primitivos (enteros, flotantes, etc.).

describe('Operaciones matemáticas', () => {

test('Realizamos la suma', () => {

expect(sumar(1,1)).toBe(2);

});

test('Realizamos la resta', () => {

expect(restar(1,1)).toBe(0);

});

});

Matchers - Jest
 .toEqual
Usado para comparar objetos y todas sus propiedades:
describe('Common matchers', () => {

const datos = {

nombre: 'Persona 1',

edad: 10

const datos2 = {

nombre: 'Persona 1',

edad: 10

test('Comprobamos que los objetos son iguales', () => {

expect(datos).toEqual(datos2); });
});

Matchers - Jest
 .toBeLessThan
El valor es menor que:
test('Resultado menor que...', () => {

expect(restar(5,3)).toBeLessThan(3);

});

.toBeLessThanOrEqual
El valor es menor o igual que:
test('Resultado menor o igual que...', () => {

expect(restar(5,3)).toBeLessThanOrEqual(2);

});

Matchers - Jest
 .toBeGreaterThan

El valor es mayor que:

test('Resultado mayor que...', () => {

expect(sumar(5,5)).toBeGreaterThan(9);

});

.toBeGreaterThanOrEqual
El valor es mayor o igual que:

test('Resultado mayor o igual que...', () => {

expect(multiplicar(2,5)).toBeGreaterThanOrEqual(10);

});

Matchers - Jest
 Más ejemplos
A nuestro código de ejemplo le vamos a agregar otras operaciones de lógica, las
cuales nos permitirán comparar valores booleanos, indefinidos y nulos.

export const sumar = (a, b) => a + b;

export const restar = (a, b) => a - b;
export const multiplicar = (a, b) => a * b;
export const dividir = (a, b) => a / b;
export const isNull = null;
export const isFalse = false;
export const isTrue = true;
export const isUndefined = undefined;

Matchers - Jest
 .toBeTruthy
El valor es verdadero:

test('Resultado True', () => {

expect(isTrue).toBeTruthy();

});

.toBeFalsy
El valor es falso:

test('Resultado False', () => {

expect(isFalse).toBeFalsy();

});

Matchers - Jest
 .toBeUndefined
El valor es undefined:

test('Resultado Undefined...', () => {

expect(isUndefined).toBeUndefined();

});

.toBeNull
El valor es null:
test('Resultado Null...', () => {

expect(isNull).toBeNull();

});

Matchers - Jest
 Arrays y strings
Para continuar, también veremos algunos matchers que se utilizan para trabajar con
arrays y strings. Para eso a nuestro código le agregamos las siguientes líneas:
const provincias = ['Álava','Girona','Huelva','Jaén','La Rioja','Madrid','Navarra'];

const dias = ['Lunes','Martes','Miercoles','Jueves','Viernes','Sabado','Domingo'];

const expReg = {

responseOK: 'Response OK',

responseFAIL: 'Response FAIL',

email: '[email protected]',

telefono: '919784852'

export const arrProvincias = () => provincias;

export const arrDias = () => dias;

export const objExpReg = () => expReg;

Matchers - Jest
 .toContain
Contiene el elemento dentro del array:
test('Madrid existe en el array', () => {

expect(arrProvincias()).toContain(‘Madrid’);

});

.toHaveLength (array)
El array tiene la longitud:

test('El array días tiene 7 elementos', () => {

expect(arrDias()).toHaveLength(7);

});

Matchers - Jest
 .toHaveLength (string)
También podemos usar este matcher para ver la longitud de un string:
const exp = objExpReg();

test('Comprobamos longitud del string', () => {

expect(exp.responseFAIL).toHaveLength(13);
});

.toMatch
Comprueba que un texto coincida con una expresión regular:
const exp = objExpReg();

test('Comprobamos formato del email', () => {

expect(exp.email).toMatch(/^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.([a-zA-Z]{2,4})+$/);
})

Matchers - Jest
 ¡Sigamos aprendiendo!
Si queremos conocer más detalles o
conocer toda la lista de matchers que
se puede usar con Jest, podemos verlo
en la documentación oficial:

https://jestjs.io/docs/expect.

Matchers - Jest
Matchers - Jest
Partes de un informe de defectos
Atributo Descripción Ejemplo

Abreviatura de identificador, un código

ID único e irrepetible que puede ser 001 - Test01
número o letras.

El título debe ser corto y específico, que Login - Ingresa

se entienda en este lo que queremos con campos
reportar. Cuando el desarrollador o el en blanco
Título equipo vean el título pueden interpretar
rápidamente qué es, dónde está y cuán
importante es ese defecto.

Describir un poco más sobre el error, En la pantalla login

es decir, desarrollar lo que dejamos si dejo vacío los
afuera en el título lo podríamos campos nombre
Descripción explicar acá. y password y apretó
ingresar, me lleva a la
página principal.

Fecha del La fecha que detectó el defecto para

informe del saber posteriormente el tiempo en 23/04/21
defecto que se resolvió.

El nombre del tester que descubrió el Pepito Román

Autor defecto, por si el desarrollador tiene una
duda, sabe a quién consultar.

Identificación Nombre de la aplicación o componente Carrito compras

del elemento que estamos probando.
de prueba
 Atributo Descripción Ejemplo

1) Ingresar a la
Los pasos a seguir para llegar al defecto
aplicación.
encontrado.
2) Dejar en blanco el
Pasos a campo nombre.
reproducir 3) Dejar en blanco el
campo password.
4) Hacer click en el
botón “Ingresar”.

Es lo que esperamos que suceda o No debe ingresar

Resultado muestre la aplicación muchas veces a la aplicación sin
esperado según los requerimientos de la misma. un usuario y una
contraseña válidos.

Es lo que sucedió realmente o lo Ingresa a la

Resultado que nos mostró la aplicación. Puede aplicación sin
obtenido o coincidir o no con el resultado usuario y sin
actual esperado, si no coincide, hemos contraseña.
detectado un error o bug.

Cuán grave es el defecto que hemos Crítico

Severidad encontrado, puede ser: bloqueado,
crítico, alto, medio, bajo o trivial.

Con esto decimos qué tan rápido se Alta

Prioridad debe solucionar el defecto, puede ser:
alta, media, baja

Los estados pueden ser: nuevo, diferido, Nuevo

duplicado, rechazado, asignado, en
Estado del
progreso, corregido, en espera de
defecto
verificación, en verificación, verificado,
reabierto y cerrado.
 Atributo Descripción Ejemplo

Link al caso de prueba con el cual https://repositorio.-

Referencias encontramos el error. com.ar/TC-001-User-
Login

Se puede adjuntar una captura de

pantalla del error, esto nos permite
Imagen demostrar que el error sucedió y al
desarrollador lo ayuda a ubicar el error.
Pruebas estáticas
y dinámicas
 1. Pruebas estáticas
Índice 2. Pruebas dinámicas
3. Conclusión

Pruebas estáticas y dinámicas

 Las pruebas estáticas y dinámicas
tienen el objetivo de proporcionar una
evaluación de calidad de los
productos de trabajo e identificar
defectos en forma temprana.

Pruebas estáticas y dinámicas

 1 Pruebas estáticas

Pruebas estáticas y dinámicas

 Conceptos básicos de la prueba estática
La prueba estática se basa en la 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 (es decir, análisis estático). Este
tipo de pruebas no requieren la ejecución del software que se está
probando.

Pruebas estáticas y dinámicas

 Conceptos básicos de la prueba estática
Se utilizan este tipo de pruebas para examinar cualquier producto de
trabajo, como por ejemplo:
● Especificaciones, requisitos de negocio, funcionales y de seguridad.
● Épicas, historias de usuarios y criterios de aceptación.
● Especificaciones de arquitectura y diseño.
● Código.
● Productos de prueba: planes, casos, procedimientos y guiones de
prueba.
● Manuales de usuario.
● Contratos, planes de proyecto, calendarios y presupuestos.

Pruebas estáticas y dinámicas

 Ventajas de las pruebas estáticas tempranas
Cuando se aplica al principio del ciclo de vida del
desarrollo del software, la prueba estática permite la
detección temprana de defectos. Esto genera una
reducción de costos y tiempo de desarrollo y prueba.

Por el contrario, si el defecto se encuentra luego de las

pruebas dinámicas, solucionarlo va a requerir el cambio
de código, realizar una prueba de confirmación y luego
incluir el mismo en pruebas de regresión, además de
los cambios de toda la documentación asociada.

Pruebas estáticas y dinámicas

 Defectos encontrados con pruebas estáticas
Algunos de los defectos encontrados con pruebas
estáticas que son más fáciles y económicos de detectar
y corregir son:
● Defectos en los requisitos (inconsistencias,
ambigüedades, etc.).
● Defectos de diseño (estructura de base de datos
ineficiente, alto acoplamiento, etc.).
● Defectos de codificación (variables con valores no
definidos, código inalcanzable o duplicado, etc.).
● Desviaciones con respecto a estándares (falta de
uso de estándares de codificación).

Pruebas estáticas y dinámicas

 Defectos encontrados con pruebas estáticas
● Especificaciones de interfaz incorrectas
(unidades de medida diferente, etc.).
● Vulnerabilidades de seguridad (susceptibilidad a
desbordamiento de la memoria intermedia).
● Diferencias o inexactitudes en la trazabilidad o
cobertura de la base de prueba (falta de pruebas
para un criterio de aceptación).
● Defectos de mantenibilidad (mala reutilización de
componentes, modularización inadecuada, etc.).

Pruebas estáticas y dinámicas

 2 Pruebas Dinámicas

Pruebas estáticas y dinámicas

 Conceptos básicos de la prueba dinámica
Las pruebas dinámicas requieren la
ejecución del software, componente o
sistema.

Se complementan con las pruebas estáticas

debido a que encuentra diferentes tipos de
defectos. Para la generación de casos de
prueba se utilizan diferentes técnicas de caja
negra, caja blanca o basadas en la
experiencia de usuario.

Pruebas estáticas y dinámicas

 Conceptos básicos de la prueba dinámica

Las fallas más comunes

encontradas con este tipo de
pruebas son:
● Fallas de funcionalidad.
● Fallas de interacción
entre módulos.
Durante las pruebas dinámicas se ejecuta el
software utilizando un conjunto de valores ● Fallas de rendimiento y
de entrada y su resultado se analiza y seguridad.
compara con el resultado esperado.

Pruebas estáticas y dinámicas

 3 Conclusión

Pruebas estáticas y dinámicas

 Conclusión
Prueba estática Prueba dinámica
Se basa en la evaluación manual Requieren la ejecución del software,
mediante revisiones y análisis estático. componente o sistema.

Detecta los defectos en productos de Detecta los defectos y fallas cuando se

trabajo. ejecuta el software.

Se centra en mejorar la consistencia y la Se centra en los comportamientos

calidad de los productos de trabajo. visibles desde el exterior.

El costo de solucionar un defecto es El costo de solucionar un defecto es

menor. mayor.

Pruebas estáticas y dinámicas

Pruebas estáticas y dinámicas
Testing I

API Testing- Creación de pruebas (JS)

Pasos

1. Comencemos con algunos conceptos a tener en cuenta:

● Para codificar los test con Postman debemos de conocer un poco el API que
nos ofrecen. Cada uno de los test es ejecutado con el objeto pm y en
concreto con el método .test(). Así, para cada uno, tendremos la siguiente
estructura:

● Para poder acceder al contenido de la respuesta de las invocaciones

tenemos el objeto pm.response y su método .json() que nos permitirán
acceder a los elementos de la respuesta en JSON.

1
● Otro método importante es el que nos permite realizar una comprobación
de contenido, este es pm.expect.

2. Teniendo en cuenta los conceptos ya definidos, veremos dos de las pruebas

más utilizadas en el Testing de APIs. Postman nos brinda una serie de
fragmentos por defecto que nos guía a la hora de construir nuestras
pruebas:

● Para comenzar, vamos a la solicitud GET que creamos anteriormente y

seleccionamos la pestaña Pruebas (1) . En esta sección escribiremos nuestro
set de pruebas relacionados con esa API. En la subsección de fragmentos,
haremos clic en "Código de estado: el código es 200" (2) para generar una de
las pruebas por defecto. La secuencia de comandos se completará
automáticamente (3).

● Al hacer clic en ENVIAR se mostrará el resultado del test.

2
● Con esta prueba estamos validando que el código de respuesta de la API sea
200. Si esto es correcto el test devolverá PASS: eso significa que el servicio
está respondiendo según lo esperado.

● Si el servicio falla nos mostrará el estado FAIL, y el código de error

relacionado con este estado.

En esta prueba estamos reutilizando fragmentos de código que nos brinda

Postman para validar si la petición se realizó correctamente. Podemos editar
esta consulta a nuestro gusto utilizando código javascript.

3
3. Agreguemos otra de las pruebas más usadas. En esta compararemos el
resultado esperado con el resultado real.

● Para ello, en la subsección de fragmentos, haremos clic en "Cuerpo de

respuesta: Verificación del valor del JSON" (1). La secuencia de comandos se
completará automáticamente (2).

● Podemos cambiar el nombre de la prueba por defecto por el que más nos
guste. En este caso lo reemplazamos por “Verificar si Leanne Graham tiene el
ID de usuario 1”, dado que este es el primero usuario de la lista devuelta por
el API. También debemos actualizar el cuerpo de la función reemplazando
jsonData.value con jsonData[0].name; así obtendremos el primer elemento
de la lista.

4
● Al hacer clic en ENVIAR se mostrará el resultado.

● Se observa que nuestro test nos devolvió un estado “PASS”. De esta manera
validamos que el contenido de la response es el esperado. Así, podremos ir
validando diferentes datos y viendo si nuestra petición nos devuelve los
datos deseados.

5
● Por último, se observa que al momento de enviar la petición se ejecutan
todos los test relacionados a esta. De esta manera, podemos crear un set de
test vinculados a cada petición y verificar rápidamente su estado.

6
Repaso de
JavaScript
 1. Variables
2. Tipos de datos
3. Operadores
Índice 4. Funciones
5. Condicionales
6. Ciclos

2
1 Variables

3
Las variables son espacios de
memoria en la computadora donde
podemos almacenar distintos tipos de
datos.
Tipos de variables
En JavaScript existen estos tipos de variables:
● let
● const
Para declarar una variable escribimos el tipo y el nombre que le queremos dar a la
variable:

let contador;
{}
const url;

Veamos cada parte con más detalle.

5
Declaración de una variable
let nombreSignificativo;

let Nombre
La palabra reservada let - Solo puede estar formado por letras, números y los
le indica a JavaScript que símbolos $ (pesos) y _ (guion bajo).
vamos a declarar una - No pueden empezar con un número.
variable de tipo let. - No deberían contener ñ o caracteres con acentos.

Es una buena práctica que los nombres de las variables usen el formato
Camel case, como variableEjemplo en vez de variableejemplo
o variable_ejemplo. Recordá que JavaScript es un lenguaje que hace
diferencia entre MAYÚSCULAS y minúsculas.

6
Asignación de un valor

let miApodo = 'Hackerman';

Nombre Asignación Valor

El nombre que nos Le indica a JavaScript Lo que vamos a
va a servir para que queremos guardar en nuestra
identificar nuestra guardar el valor de la variable. En este
variable cuando derecha en la variable caso, un texto.
necesitemos de la izquierda.
usarla.

7
Asignación de un valor

La primera vez que declaramos una variable es necesaria la palabra reservada let.

{} let miApodo = 'Hackerman';

Una vez que la variable ya fue declarada, le asignamos valores sin let.

{} miApodo = 'El Barto';

8
Declaración con const
Las variables const se declaran con la palabra reservada const.

{} const email = "[email protected]";

Las variables declaradas con const funcionan igual que las variables let, estarán
disponibles solo en el bloque de código en el que se hayan declarado.

Al contrario de let, una vez que les asignemos un valor, no podremos cambiarlo.

email = "[email protected]";
{} // Error de asignación, no se puede cambiar
// el valor de un const
9
Declaración con let o const
Como dijimos antes, tanto let como const son accesibles dentro del bloque donde son
declaradas.
Por esta razón solo podemos declararlas una vez. Si volvemos a declararlas, JavaScript
nos devolverá un error.

let contador = 0;
let contador = 1;
// Error de re-declaración de la variable
{}
const email = "[email protected]";
const email = "[email protected]";
// Error de re-declaración de la variable
10
Declaración con var
Existe otra forma de declarar variables que ya no se utiliza y no lo veremos en la
materia, pero que puede ser que la encuentres en códigos que tengan algunos años.

Estas variables se declaran de una manera similar, con la diferencia que utilizamos la
palabra reservada var.

{} var contador = 1;

La principal diferencia entre var y let es que var será accesible de manera global por
todo nuestro código y no estará limitado el acceso a solo el bloque de código donde fue
declarado como es el caso de let.
Por convención y buenas prácticas es recomendado el uso de let.
Los bloques de código son normalmente determinados por las llaves { }.

11
“
Las palabras reservadas como var, let y
const solo pueden utilizarse para el
propósito que fueron creadas.
No pueden ser utilizadas como:
nombre de variables, funciones,
métodos o identificadores de objetos.

12
2 Tipos de datos

13
“
Los tipos de datos le permiten a
JavaScript conocer las características
y funcionalidades que estarán
disponibles para ese dato.

” 14
Numéricos (number) Como JavaScript está
escrito en inglés,
let edad = 35; // número entero usaremos un punto
para separar los
let precio = 150.65; // decimales decimales.
{}
let malaDivision = "35" / 2; // NaN - Not a Number, no es
un número aunque es un valor de “tipo” number
Cadenas de caracteres (string)
let nombre = 'Mamá Luchetti'; // comillas simples
{} let ocupacion = "Master of the sopas"; // comillas
dobles tienen el mismo resultado

Lógicos o booleanos (boolean)

let laCharlaEstaReCopada = true;

{}
let hayAsadoAlFinal = false;|

16
Undefined (valor sin definir)
Indica la ausencia de valor.
Las variables tienen un valor indefinido hasta que les asignamos uno.

let saludo; // undefined, no tiene valor

{}
saludo = "¡Hola!"; // Ahora si tiene un valor

Null (valor nulo)

Lo asignamos nosotros para indicar un valor vacío o desconocido.

{} let temperatura = null; // No llegó un dato, algo falló

17
Array

Los arrays nos permiten generar una colección de datos ordenados.

Cada dato de un array ocupa una posición numerada conocida como índice. La
primera posición de un array es siempre 0.

{} let pelisFavoritas = ['Star Wars', 'Kill Bill', 'Alien'];

0 1 2
Para acceder a un elemento puntual de un array, nombramos al array y, dentro de
los corchetes, escribimos el índice al cual queremos acceder.

pelisFavoritas[2];
{}
// accedemos a la película Alien, el índice 2 del array

18
Objeto literal

Un objeto es una estructura de datos que puede contener propiedades y

métodos.
Para crearlo usamos llave de apertura y de cierre {}.
let auto = {
{} patente : 'AC 134 DD',
};

PROPIEDAD DOS PUNTOS VALOR

Definimos el nombre de Separa el nombre de la Puede ser cualquier tipo
la propiedad del objeto. propiedad de su valor. de dato que conocemos.
Métodos de un objeto
Una propiedad puede almacenar cualquier tipo de dato. Si una propiedad
almacena una función, diremos que es un método del objeto. Con una
estructura similar a la de las funciones expresadas, vemos que se crean
mediante el nombre del método, seguido de una función anónima.

let tenista = {
nombre: 'Roger',
edad: 38,
activo: true,
{}
saludar: function() {
return '¡Hola! Me llamo Roger';
}
};
Ejecución de un método de un objeto
Para ejecutar un método de un objeto usamos la notación objeto.metodo().
La palabra reservada this hace referencia al objeto en sí donde estamos parados. Es
decir, el objeto en sí donde escribimos la palabra.
Con la notación this.propiedad accedemos al valor de cada propiedad interna de ese
objeto.
let tenista = {
nombre: 'Roger',
apellido: 'Federer',
saludar: function() {
{}
return '¡Hola! Me llamo ' + this.nombre;
}
};
console.log(tenista.saludar()); // ¡Hola! Me llamo Roger
NaN (Not-A-Number)
Indica que el valor pasado no es un número.

let nombre = "Esteban"

{} console.log("Esteban"-1)

22
3 Operadores

23
“
Los operadores nos permiten
manipular el valor de las variables,
realizar operaciones y comparar sus
valores.

” 24
De asignación
Asignan el valor de la derecha en la variable de la izquierda.

{} let edad = 35; // Asigna el número 35 a edad

Aritméticos
Nos permiten hacer operaciones matemáticas, devuelven el resultado de la
operación. Siempre devolverán el resultado numérico.

10 + 15 // Suma → 25
10 - 15 // Resta → -5
{}
10 * 15 // Multiplicación → 150
15 / 10 // División → 1.5

25
Aritméticos (continuación)
Nos permiten hacer operaciones matemáticas, devuelven el resultado de la
operación.

15++ // Incremento, es igual a 15 + 1 → 16

{}
15-- // Decremento, es igual a 15 - 1 → 14

15 % 5 // Módulo, el resto de dividir 15 entre 5 → 0

{}
15 % 2 // Módulo, el resto de dividir 15 entre 2 → 1

El operador de módulo % nos devuelve el resto de una división.

15 5 15 2

0 3 1 7
26
De concatenación
Sirven para unir cadenas de texto. Devuelven otra cadena de texto.

let nombre = 'Teodoro';

{} let apellido = 'García';
let nombreCompleto = 'Me llamo ' + nombre + ' ' + apellido;

Template literals
Existe otra forma de armar strings a partir de variables, y es con los template literals
utilizando backtick en lugar de comillas y las variables entre llaves a continuación del
símbolo $. En este ejemplo lo escribiríamos así: `Me llamo ${nombre} ${apellido}`

Si mezclamos otros tipos de datos, estos se convierten a cadenas de texto.

let fila = 'M';
{} let asiento = 7;
let ubicacion = fila + asiento; // 'M7' como string

27
De comparación simple
Comparan dos valores, devuelven verdadero o falso.

10 == 15 // Igualdad → false
{}
10 != 15 // Desigualdad → true

De comparación estricta
Comparan el valor y el tipo de dato también.

10 === "10" // Igualdad estricta → false

{}
10 !== 15 // Desigualdad estricta → true

En el primer caso, el valor es 10 en ambos ejemplos, pero los tipos de datos son
number y string. Como estamos comparando que ambos —valor y tipo de dato—
sean iguales, el resultado es false.

28
De comparación (continuación)
Comparan dos valores, devuelven verdadero o falso.

15 > 15 // Mayor que → false

15 >= 15 // Mayor o igual que → true
{}
10 < 15 // Menor que → true
10 <= 15 // Menor o igual que → true

Siempre debemos escribir el símbolo mayor (>) o menor (<) antes que el
igual (>= o <=). Si lo hacemos al revés (=> o =<), JavaScript lee primero el
operador de asignación = y luego no sabe qué hacer con el mayor (>) o el
menor (<).

29
Lógicos
Permiten combinar valores booleanos, el resultado también devuelve un booleano.
Existen tres operadores y (and), o (or), negación (not).

AND (&&) → todos los valores deben evaluar como true para que el resultado sea
true.

{} (10 > 15) && (10 != 20) // false

FALSE TRUE FALSE

{} (12 % 4 == 0) && (12 != 24) // true

TRUE TRUE TRUE

30
OR ( || ) → al menos un valor debe evaluar como true para que el resultado sea
true.

{} (10 > 15) || (10 != 20) // true

FALSE TRUE TRUE

{} (12 % 5 == 0) && (12 != 12) // false

FALSE FALSE FALSE

NOT ( ! ) → niega la condición. Si era true, será false y viceversa.

!false // true
{}
!(20 > 15) // false

31
4 Funciones

32
Una función es un bloque de código que nos
permite agrupar una funcionalidad para
usarla todas las veces que necesitemos.
Normalmente, realiza una tarea específica y
retorna un valor como resultado.
Estructura básica
function sumar (a, b) {
{} return a + b;
}

● Palabra reservada: Usamos la palabra function para indicarle a JavaScript que vamos a escribir una
función.
● Nombre de la función: Definimos un nombre para referirnos a nuestra función al momento de querer
invocarla.
● Parámetros: Escribimos los paréntesis y, dentro de ellos, los parámetros de la función. Si hay más de
uno, los separamos usando comas ,. Si la función no lleva parámetros, igual debemos escribir los
paréntesis sin nada adentro ().
● Cuerpo: Entre las llaves de apertura y de cierre escribimos la lógica de nuestra función, es decir, el
código que queremos que se ejecute cada vez que la invoquemos.
● El retorno: Es muy común, a la hora de escribir una función, que queramos devolver al exterior el
resultado del proceso que estamos ejecutando. Para eso utilizamos la palabra reservada return seguida
de lo que queramos retornar.
Funciones declaradas
Son aquellas que se declaran usando la estructura básica. Pueden recibir un
nombre, escrito a continuación de la palabra reservada function, a través del
cual podremos invocarla.
Las funciones con nombre son funciones nombradas.

function saludar(nombre) {
{} return 'Hola' + nombre;
}
Funciones expresadas
Son aquellas que se asignan como valor de una variable. En este caso, la función
en sí no tiene nombre, es una función anónima.
Para invocarla podremos usar el nombre de la variable que declaremos.

let triplicar = function (numero) {

{} return numero * 3;
}
Scope local
En el momento en que declaramos una variable dentro de una función, esta pasa
a tener alcance local. Es decir, esa variable vive únicamente dentro de esa
función.
Si quisiéramos hacer uso de la variable por fuera de la función, no vamos a poder,
dado que fuera del scope donde fue declarada, esa variable no existe.

function saludar() {
// todo el código que escribamos dentro
{} // de nuestra función, tiene scope local
}
// No podremos acceder desde afuera a ese scope
Scope global
En el momento en que declaramos una variable fuera de cualquier función, la
misma pasa a tener alcance global.
Es decir, podemos hacer uso de ella desde cualquier lugar del código en el que
nos encontremos, inclusive dentro de una función, y acceder a su valor.

// todo el código que escribamos fuera

// de las funciones es global
function miFuncion() {
{}
// Desde adentro de las funciones
// Tenemos acceso a las variables globales
}
Arrow Function - Estructura básica
Pensemos en una función simple que podríamos programar de la manera
habitual: una suma de dos números.

{} function sumar (a, b) { return a + b }

Ahora veamos la versión reducida de esa misma función, al transformarla en una

función arrow.

{} let sumar = (a, b) => a + b;

Nombre de una función arrow
Las funciones arrow son siempre anónimas. Es decir, que no tienen nombre
como las funciones normales.

{} (a, b) => a + b;

Si queremos nombrarlas, es necesario escribirlas como una función expresada. Es

decir, asignarla como valor de una variable.

{} let sumar = (a, b) => a + b;

De ahora en más podremos llamar a nuestra función por su nuevo nombre.

Parámetros de una función arrow
Usamos paréntesis para indicar los parámetros. Si nuestra función no recibe
parámetros, debemos escribirlos igual.

{} let sumar = (a, b) => a + b;

Una particularidad de este tipo de funciones es que si recibe un único parámetro,

podemos prescindir de los paréntesis.

{} let doble = a => a * 2;

La flecha de una función arrow
La usamos para indicarle a JavaScript que vamos a escribir una función
—reemplaza a la palabra reservada function—.

{} let sumar = (a, b) => a + b;

Lo que está a la izquierda de la fecha será la entrada de la función —los

parámetros— y lo que está a la derecha, la lógica —y el posible retorno—.
Cuerpo de una función arrow

Como ya vimos, si la función tiene una sola línea de código, y esta misma es la que
hay que retornar, no hacen falta las llaves ni la palabra reservada return.

{} let sumar = (a, b) => a + b;

De lo contrario, vamos a necesitar utilizar ambas. Eso normalmente pasa cuando

tenemos más de una línea de código en nuestra función.
let esMultiplo = (a, b) => {
let resto = a % b; // Obtenemos el resto de la div.
{}
return resto == 0; // Si el resto es 0, es múltiplo
};
5 Condicionales

44
Nos permiten evaluar condiciones
y realizar diferentes acciones según el
resultado de esas evaluaciones.

45
Condicional simple
Versión más básica del if. Establece una condición y un bloque de código a
ejecutar en caso de que sea verdadera.

if (condición) {
{} // código a ejecutar si la condición es verdadera
}

46
 Condicional con bloque else
Igual al ejemplo anterior, pero agrega un bloque de código a ejecutar en caso de
que la condición sea falsa.
Es importante tener en cuenta que el bloque else es opcional.

if (condición) {
// código a ejecutar si la condición es verdadera
{} } else {
// código a ejecutar si la condición es falsa
}

Los condicionales 47
Condicional con bloque else if
Igual que el ejemplo anterior, pero agrega un if adicional. Es decir, otra condición
que puede evaluarse en caso de que la primera sea falsa.
Podemos agregar todos los bloques else if que queramos, solo uno podrá ser
verdadero. De lo contrario, entrará en acción el bloque else, si existe.

if (condición) {
// código a ejecutar si la condición es verdadera
} else if (otra condición) {
{} // código a ejecutar si la otra condición es verdadera
} else {
// código a ejecutar si todas las condiciones son falsas
}
48
6 Ciclos

49
Los ciclos nos permiten repetir
instrucciones de manera sencilla.
Podemos hacerlo una determinada
cantidad de veces o mientras se cumpla
una condición.
 Ciclo FOR
Consta de tres partes que definimos dentro de los paréntesis. En conjunto,
nos permiten determinar de qué manera se van a realizar las repeticiones y
definir las instrucciones que queremos que se lleven a cabo en cada una de
ellas.
for (inicio; condición ; modificador) {
{} //código que se ejecutará en cada repetición
}

● Inicio: antes de arrancar el ciclo, se establece el valor inicial de nuestro contador.

● Condición: antes de ejecutar el código en cada vuelta, se pregunta si la condición resulta verdadera o
falsa. Si es verdadera, continúa con nuestras instrucciones. Si es falsa, detiene el ciclo.
● Modificador —incremento o decremento—: luego de ejecutar nuestras instrucciones, se modifica
nuestro contador de la manera que hayamos especificado. En este caso se le suma 1, pero podemos
hacer la cuenta que queramos.
Los ciclos
 Estructura básica FOR
En este ejemplo vamos a contar desde 1 hasta 5 inclusive.

for (let vuelta = 1; vuelta <= 5; vuelta++) {

{} console.log('Dando la vuelta número ' + vuelta);
};

Dando la vuelta número 1

Dando la vuelta número 2
Dando la vuelta número 3
Dando la vuelta número 4
Dando la vuelta número 5

Los ciclos
Ciclo WHILE
Tiene una estructura similar a la de los condicionales if/else, palabra reservada +
condición entre paréntesis. Sin embargo, el while Loop revalúa esa condición
repetidas veces y ejecuta su bloque de código hasta que la condición deja de
ser verdadera.

while (condicion) {
//código que se ejecutará en cada repetición
{} // Hace algo para que la condición eventualmente se deje
de cumplir
}
Estructura básica WHILE
Tomando el ejemplo utilizado con el for, veamos como sería utilizando while.
let vuelta = 1
while(vuelta <= 5) {
{} console.log('Dando la vuelta número ' + vuelta);
vuelta++ //al final de cada vuelta sumara 1 a vuelta
};

Dando la vuelta número 1

Dando la vuelta número 2
Dando la vuelta número 3
Dando la vuelta número 4
Dando la vuelta número 5
Estructura básica WHILE (cont.)
Es importante generar el contador al comenzar para evitar caer en lo que se
conoce como loop infinito.

let vuelta = 1
while(vuelta <= 5) {
{} console.log('Dando la vuelta número ' + vuelta);
vuelta++
};

El loop infinito sucede cuando nuestra condición es constantemente verdadera,

lo que resulta en ejecutar nuestro código eternamente. Esto puede causar varios
problemas, siendo el más importante que trabe todo nuestro programa.
Ciclo DO WHILE
A diferencia del ciclo while, la condición en este caso se verifica al finalizar el
bloque de código. Por lo tanto, sin importar lo que se resuelva, las acciones se
realizarán al menos una vez.

let vuelta = 5
do{
console.log('Dando la vuelta número ' + vuelta);
{}
vuelta++ //Se suma 1 a vuelta por lo tanto vuelta = 6
} while(vuelta <= 5); //al vuelta ser 6 la condición retorna
false y se termina el bloque de código

Fuera de esto, el ciclo do while es idéntico en funcionalidad al ciclo while.

Evolución histórica en la calidad del software

Validación Vs Verificación
7 prim

7 principios del testing

 Business analyst / Analista de negocio

Business analyst / Analista de negocio: Se encarga de detectar los factores clave del
negocio y es el intermediario entre el departamento de sistemas y el cliente final.

Software developer / Desarrollador de software: Su función es diseñar, producir,

programar o mantener componentes o subconjuntos de software conforme a
especificaciones funcionales y técnicas para ser integrados en aplicaciones.

QA: La principal función es probar los sistemas informáticos para que funcionen
correctamente de acuerdo a los requerimientos del cliente, documentar los errores
encontrados y desarrollar procedimientos de prueba para hacer un seguimiento de los
problemas de los productos de forma más eficaz y eficiente.
Si bien cada actor tiene un rol definido, es necesario un trabajo en comunión entre los 3
actores. Es decir, es necesario que trabajen como equipo. Por eso, utilizamos la analogía
con una mesa de 3 patas, pues si falta alguna de ellas, la mesa no podría estar de pie.

● En algunas empresas de software pequeñas o “start up” es posible que una misma
persona tenga más de un rol.
● Además, algo importante dentro de las metodologías de desarrollo ágiles, es la
reunión de los 3 amigos. Es una sesión en la que participan estos tres roles y cada
uno de ellos da su punto de vista respecto al software que está bajo desarrollo. Aquí,
más que nunca se pone en manifiesto el funcionamiento de la mesa.

Ciclo de vida de un defecto:

Testing positivo y testing negativo

Testing positivo (+)
Son aquellos casos de prueba que validan el flujo normal de un sistema bajo prueba. Es
decir, flujos que están relacionados a los requisitos funcionales del sistema bajo prueba.

Testing negativo (-)

Son aquellos casos de prueba que validan flujos no contemplados dentro de los requisitos
de un sistema bajo prueba.

Casos de uso
Antes de realizar el diseño de los casos de prueba, lo que se debe llevar a cabo es el
análisis de los documentos que van a ser la base para la generación de esos casos de
prueba. Estos documentos van a asegurar los requisitos del cliente. Generalmente, estos
requisitos se encuentran escritos como casos de uso. Un tester debe comprender qué es
un caso de uso y cómo diseñar los casos de prueba a partir de estos.
 Niveles y tipos de prueba
En toda actividad es importante conocer el marco global, es decir, tener esa visión general
para no perder de vista dónde estamos y cómo seguimos. En este módulo, para lograr esta
visión global, comenzaremos por conocer cómo se relacionan en forma lógica y cronológica
las actividades que se desarrollan a lo largo del ciclo de vida de las pruebas de software
(STLC).

Luego, se agruparán estas actividades con el fin de organizarlas y gestionarlas

conjuntamente en los distintos niveles de prueba. Cada nivel de prueba es una instancia
del proceso de prueba, desde componentes individuales hasta sistemas completos.

Finalmente, estas actividades de prueba serán agrupadas de acuerdo a características

específicas que se necesitan probar en un sistema de software o partes de un sistema.
Estos grupos de pruebas con un objetivo específico son llamados tipos de prueba.
Prueba unitaria o de componente:

Prueba de integración:
Prueba de sistema:
Prueba de aceptación:
Enfoque tradicional y enfoque agil:

Ejemplos de tipos de prueba

Los siguientes ejemplos están basados en una aplicación bancaria.

Pruebas funcionales:

● Prueba de componente: las pruebas se diseñan con base en la forma en que un

componente debe calcular el interés a pagar por un préstamo.
● Prueba de integración de componentes: las pruebas se diseñan en función de cómo
la información de la cuenta capturada en la interfaz de usuario se transfiere a la
lógica de negocio.
● Prueba de sistema: las pruebas se diseñan sobre la base de cómo los titulares de
cuentas pueden solicitar una línea de crédito sobre sus cuentas corrientes.
● Prueba de integración de sistemas: las pruebas se diseñan en función de cómo el
sistema utiliza un microservicio externo para comprobar la calificación crediticia del
titular de una cuenta.
 ● Prueba de aceptación: las pruebas se diseñan con base en la forma en que el
empleado del banco tramita la aprobación o rechazo de una solicitud de crédito.

Pruebas no funcionales:

● Prueba de componente: las pruebas de rendimiento están diseñadas para evaluar el

número de ciclos de CPU necesarios para realizar un cálculo de intereses totales
complejo.
● Prueba de integración de componentes: las pruebas de seguridad están diseñadas
para vulnerabilidades de desbordamiento de memoria intermedia debido a que los
datos pasan de la interfaz de usuario a la lógica de negocio.
● Prueba de sistema: las pruebas de portabilidad están diseñadas para comprobar si
la capa de presentación funciona en todos los navegadores y dispositivos móviles
soportados.

Clasificación de los tipos de prueba:

Pruebas funcionales: Con este tipo de pruebas testeamos la funcionalidad de nuestro sistema
o software. Podemos hacernos preguntas sobre cómo funciona, qué debe estar haciendo y
cómo están interactuando los usuarios.Con este tipo de pruebas testeamos la funcionalidad de
nuestro sistema o software. Podemos hacernos preguntas sobre cómo funciona, qué debe estar
haciendo y cómo están interactuando los usuarios.

● Pruebas de sanidad
● Pruebas de aceptación
● Pruebas de sistema

Pruebas No funcionales: Puede que tengamos un sistema funcionando, pero el usuario está
experimentando otro tipo de problemas que no son detectados por las pruebas anteriores.
Factores como lentitud, problemas con la combinación de colores que producen poca legibilidad,
claridad, usabilidad y seguridad, son los que testeamos en este tipo de prueba.
● Pruebas de rendimiento
● Pruebas de portabilidad
 ● Pruebas de usabilidad
● Pruebas de carga
● Pruebas de estrés

Pruebas estructurales: Éstas pruebas están 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.
● Prueba unitaria
● Prueba de integración

Pruebas asociadas al cambio: Este tipo de pruebas están asociadas a los cambios que se
producen debido a nuevos requerimientos o cambios en requerimientos existentes. Estos
cambios son más frecuentes en ciclos de vida de desarrollo iterativos e incrementales —por
ejemplo, Agile—.
● Prueba de confirmación (Re-test)
● Prueba de regresión

Técnica caja negra: En este tipo de técnicas el elemento es estudiado desde el punto de vista
de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su
funcionamiento interno.
● Partición de equivalencia
● Análisis de valores límites

Técnica caja blanca: Método por el cual se mira el código y la estructura del producto que se
va a probar y se usa ese conocimiento para la realización de las pruebas.
● Pruebas de sentencia
● Pruebas de decisión

Forma manual: Las pruebas manuales son ejecutadas directamente por uno o más testers,
simulando las acciones del usuario final, apoyándose de las herramientas necesarias.

Forma automatizada: Las pruebas automatizadas son ejecutadas por testers con habilidades
técnicas, y se apoyan en diversas herramientas para realizar scripts y así, ejecutar las pruebas
automáticamente.
Ejecución de la prueba:
Durante la ejecución de las pruebas, los conjuntos de pruebas se ejecutan luego del
despliegue de cambios en los ambientes de prueba como parte del desarrollo planificado
dentro de un sprint. La ejecución de pruebas incluye las siguientes actividades principales.
Para conocerlas, pasar con el mouse por encima de cada uno de los iconos que se
encuentran a continuación.
1°_ Registrar los identificadores y las versiones de los elementos u objetos de prueba, las
herramientas de prueba y los productos de prueba.
2°_ Ejecutar pruebas de forma manual o utilizando herramientas de ejecución de pruebas.
3°_ Comparar resultados reales con resultados esperados.
4°_ Analizar las anomalías para establecer sus causas probables.
5°_ Informar sobre los defectos en función de los fallos observados.
6°_ Registrar el resultado de la ejecución de la prueba.
7°_ Repetir las actividades de prueba, ya sea como resultado de una acción tomada para una
anomalía o como parte de la prueba planificada.

Pruebas de Humo y Pruebas de Regresión

Las pruebas de humo y las pruebas de regresión son dos de las pruebas más importantes que
se ejecutan a lo largo del desarrollo de un sistema. Ambas son necesarias para el
funcionamiento saludable del producto en construcción y relevantes para la calidad final del
producto.

Las pruebas de humo se ejecutan para evaluar la estabilidad de las compilaciones de software
iniciales o desarrolladas recientemente.

Las pruebas de regresión la tarea de verificar y validar las funcionalidades existentes de la

aplicación después de cada modificación o en la adición de nuevas funciones.

Las pruebas de humo son previas a las de regresión.

Si se encuentra algún problema durante las pruebas de humo, la compilación no se encuentra

estable por lo que retorna al equipo de desarrollo hasta que lo sea. Una vez que nos
encontramos en una versión estable del sistema, se llevan a cabo las pruebas de regresión
sobre las funcionalidades existentes siguiendo la planificación prevista.

Proceso de revisión
Dentro de las pruebas estáticas, una forma de detectar errores es mediante un proceso de
revisión.

Las revisiones consisten en examinar cuidadosamente un producto de trabajo con el principal

objetivo de encontrar y remover errores. Pueden ser realizadas por una o más personas.

Las revisiones pueden ser:

● Revisiones formales: Tienen roles definidos, siguen un proceso establecido y deben ser
documentadas.
● Revisiones Informales: No siguen un proceso definido y no son documentadas
formalmente.

El grado de formalidad del proceso de revisión está relacionado con factores, como el modelo
del ciclo de vida del desarrollo del software, la madurez del proceso de desarrollo, la
complejidad del producto del trabajo que se debe revisar, cualquier requisito legal y/o la
necesidad de un rastro de auditoría.

Requisitos
Una de las revisiones que se realizan en las pruebas estáticas es examinar los requisitos del
software. Pero ¿sabemos qué son los requisitos? ¿Qué tipos de requisitos existen?

Un requisito define las funciones, capacidades o atributos intrínsecos de un sistema de software,

es decir, describe cómo debe comportarse un sistema. Para decir que un sistema tiene calidad
deben cumplirse los requisitos funcionales y no funcionales.

Requisitos funcionales

Definen lo que un sistema permite hacer desde el punto de vista del usuario. Estos requisitos
deben estar especificados de manera explícita. Por ejemplo: “El campo de monto acepta
únicamente valores numéricos con dos decimales” (pruebas funcionales y de sistema).

Requisitos no funcionales

Definen condiciones de funcionamiento del sistema en el ambiente operacional. Ejemplos:

● Requisito de usabilidad: la usabilidad se define como el esfuerzo que necesita hacer

un usuario para aprender, usar, ingresar datos e interpretar los resultados obtenidos de
un software de aplicación (pruebas de usabilidad).
● Requisito de eficiencia: relacionado con el desempeño en cuanto al tiempo de
respuesta, número de operaciones por segundo, entre otras mediciones; así como
 consumo de recursos de memoria, procesador y espacio en disco o red (pruebas de
rendimiento, pruebas de carga, estrés y escalabilidad, pruebas de gestión de la
memoria, compatibilidad e interoperabilidad).
● Requisito de disponibilidad: disposición del sistema para prestar un servicio
correctamente (pruebas de disponibilidad). Requisito de confiabilidad: continuidad del
servicio prestado por el sistema (pruebas de seguridad).
● Requisito de integridad: ausencia de alteraciones inadecuadas al sistema (pruebas de
seguridad, pruebas de integridad). Requisito de mantenibilidad: posibilidad de realizar
modificaciones o reparaciones a un proceso sin afectar la continuidad del servicio
(pruebas de mantenimiento y de regresión).

Ambientes de trabajo

¿Qué es un ambiente?

La ejecución de las pruebas se realizan en diferentes espacios de trabajo de acuerdo a la etapa

del ciclo de desarrollo en el que se encuentre el sistema en construcción o mantenimiento. Estos
entornos son conocidos como ambientes. En otras palabras, hacen referencia a un servidor con
ciertos recursos asignados, software y librerías instalados, su propia base de datos y una
configuración determinada.

Esto nos permitiría desarrollar aplicaciones de forma segura y con entornos diferenciados para
realizar la programación, realizar pruebas, compartir resultados con los clientes y permitirles
realizar pruebas y prácticas; y finalmente publicar una aplicación robusta y estable.

Cada uno de los ambientes son utilizados con un fin específico y presentan ciertas ventajas
sobre los otros en determinado momento del proceso de trabajo.

Niveles de ambientes

Entonces, podemos decir que es conveniente distinguir los siguientes entornos:

● a) Ambiente de desarrollo o DEV :este entorno es el espacio de trabajo donde el

programador desarrolla el código de la aplicación, realiza pruebas iniciales y comprueba
si la aplicación se ejecuta correctamente con ese código. Este ambiente puede ser local
o en la nube, de acuerdo a la necesidad del proyecto.
● b) Ambiente de pruebas o QA : el entorno de pruebas suele estar ubicado en un
servidor en la nube o en una granja de servidores locales (laboratorio). Permite
minimizar incidencias en etapas posteriores, ya que el tester ejecutaría las primeras
pruebas de funcionalidad en este ambiente.
● c) Ambiente de UAT: el entorno de UAT (o de pruebas de aceptación de usuario)
permite a los usuarios del cliente poder verificar que los cambios realizados son los que
realmente se solicitaron, evaluando a su vez accesibilidad y usabilidad.
● d) Ambiente de preproducción o STAGE :este entorno debería poseer una
configuración técnica idéntica a la que nos encontraremos en el entorno de producción.
El propósito principal de este entorno es emular al entorno de producción con el fin de
probar las actualizaciones y asegurar que estas no corromperán la aplicación en los
 servidores en producción cuando sean desplegadas. De esta forma se minimizan las
caídas del sistema y corte de los servicios en producción.
● e) Ambiente de producción o PROD :este es el entorno donde finalmente se ejecuta la
aplicación, donde acceden los usuarios finales y donde se trabaja con los datos reales
de negocio. Es un servidor que posee las mismas características y configuración que
tendrá el servidor de preproducción. Aunque, en este caso, puede estar configurado por
más de un servidor, para efectos de balanceo de carga en aplicaciones que requieren
una infraestructura con capacidad de manejar un tráfico de usuarios pesado y miles de
conexiones concurrentes.
Debugging VS. Testing

Prueba de componente o prueba unitaria (unit test)

La prueba de componente o prueba unitaria es la prueba de los componentes individuales de
software. Son pequeños test creados específicamente para cubrir todos los requisitos del código
y verificar sus resultados. Para generar estos test se utilizan técnicas de caja blanca.

Las pruebas unitarias son generalmente pruebas automatizadas escritas y ejecutadas por
desarrolladores de software para garantizar que una sección de una aplicación —conocida como
la "unidad"— cumpla con su diseño y se comporte según lo previsto.

El proceso general para la creación de estos unit test consta de tres partes:

1. Acuerdo o criterio de aceptación donde se definen los requisitos que debe cumplir el
código principal.
2. Escritura del test el proceso de creación, donde se acumulan los resultados a analizar.
3. Confirmación se considera el momento en que comprobamos si los resultados
agrupados son correctos o incorrectos. Dependiendo del resultado, se valida y continúa,
o se repara, de forma que el error desaparezca (debug).

¿Que es una “unidad”?

Una unidad puede ser casi cualquier parte del código que se quiera: una línea de código, un
método o una clase. En general, cuanto más pequeño, mejor. Las pruebas más pequeñas
brindan una vista mucho más granular de cómo se está desempeñando el código. También
existe el aspecto práctico de que, cuando se prueban unidades muy pequeñas, se pueden
ejecutar rápidamente.

Framework para pruebas unitarias

Es una herramienta que proporciona un entorno para la prueba de unidades o componentes en

el que un componente se puede probar de forma aislada o con adecuados stubs y drivers.
También proporciona otro soporte para el desarrollador, como la capacidad de depuración.

Por ejemplo, para realizar la prueba de componente de código realizado en JavaScript se puede
crear un framework basado en las siguientes herramientas:

● Mocha (https://mochajs.org/api/index.html)
● Chai (https://www.chaijs.com/guide/)

npm

npm es el sistema de gestión de paquetes por defecto para Node.js. Ustedes dirán,
“¿Paquetes? ¿Es lo que usa Amazon para sus entregas?”.

Cuando nos referimos a “paquetes” en realidad a lo que se hace referencia, es a paquetes de

código que vivirán en una carpeta llamada “node_modules” y tendrán una configuración que los
llamará dentro de un archivo llamado “package.json”.

Este se genera al iniciar un proyecto con el comando “npm init” previamente habiendo
descargado node.js.

Esta configuración contendrá información valiosa para el proyecto como por ejemplo:
 ● El autor
● El título del proyecto
● La licencia
● El repositorio
● Las dependencias
● Scripts
● Test
● Otros

A continuación, pueden ver un ejemplo de cómo se ve un package.json

En conclusión

Node.js se usa para ejecutar JavaScript del lado del servidor, el cual tiene un gestor de paquetes
llamado npm que cuenta con una comunidad gigante que sube constantemente sus paquetes de
código para compartir con otros y por medio de unos comandos, pueden usar esos paquetes de
código en sus proyectos.

Para Testing I, usaremos npm para instalar jest, framework que nos permitirá escribir pruebas
unitarias o de componentes.
Técnicas de prueba de caja blanca
Las técnicas de prueba de caja blanca, también conocidas como pruebas estructurales, se
basan en la estructura interna del objeto de prueba, es decir, que está fuertemente ligado al
código fuente.

Estas técnicas se pueden utilizar en todos los niveles de prueba.

Cuando se crean casos de prueba con este tipo de técnicas es aconsejable utilizar también las
técnicas de caja negra como partición de equivalencia y análisis de valores límites. De este
modo se conseguirán datos de prueba que maximicen la cobertura de prueba.

Las siguientes técnicas se utilizan con mayor frecuencia en el nivel de prueba de componentes.

Prueba y cobertura de sentencia

Cuando hablamos de cobertura de sentencia, nos referimos al porcentaje de sentencias

ejecutables que han sido practicadas por un juego de pruebas. Se escriben casos de prueba
suficientes para que cada sentencia en el programa se ejecute (al menos) una vez.

● Ejercita las sentencias ejecutables en el código.

● Expone código que nunca se ejecuta o que se encuentra bajo condiciones imposibles.
● Cuando se logra una cobertura del 100% de sentencia, se asegura de que todas las
sentencias ejecutables del código se han probado al menos una vez, pero no asegura de
que se haya probado toda la lógica de decisión. Por lo tanto, la prueba de sentencia
puede proporcionar menos cobertura que la prueba de decisión.
● La cobertura se mide como:

Prueba y cobertura de decisión

Es aquella prueba en la que se escriben test cases suficientes para que cada decisión en el
programa se ejecute una vez con resultado verdadero y otra con el falso.

● Ejercita las decisiones en el código y prueba el código que se ejecuta basado en los
resultados de la decisión.
● Los casos de prueba siguen los flujos de control que se producen desde un punto de
decisión.
● En el caso de un IF se necesitan dos casos de prueba como mínimo, uno para el valor
VERDADERO y otro para el FALSO de la decisión.
● En el caso de un CASE se necesitan casos de prueba para todos los resultados
posibles, incluido el por defecto.
● Ayuda a encontrar defectos en el código que no fueron practicados por otras pruebas ya
que se deben recorrer todos los caminos de una decisión.
 ● Cuando se alcanza el 100% de cobertura de decisión, se ejecutan todos los resultados
de decisión. Esto incluye probar el resultado verdadero y también el resultado falso,
incluso cuando no hay una sentencia falsa explícita.
● Lograr una cobertura del 100% de decisión garantiza una cobertura del 100% de
sentencia, pero no al revés.
● La cobertura se mide como:

¿Qué es el testing de back end?

Una aplicación web típica tiene tres capas: interfaz (UI), lógica empresarial y una base de datos.
Probar la interfaz, es decir el front end, implica validar aquellas partes de la aplicación que son
visibles para los usuarios finales, por ejemplo: formularios, menús, navegaciones, etc. Por otro
lado, las pruebas de back end tratan con todos esos elementos que los usuarios no pueden ver
(lógica empresarial y base de datos).

Entonces el testing back end nos garantiza que los datos contenidos en la base de datos de una
aplicación y su estructura satisfagan los requisitos del proyecto.

Testing de APIs

Hablando en un alto nivel, nuestro trabajo es entender cómo funciona la API, armar una buena
combinación de parámetros de entrada, ejecutar las pruebas contra la API, verificar el resultado
y reportar cualquier desviación en la funcionalidad esperada. Estas pruebas consisten en hacer
peticiones HTTP (get, post, put y delete) y luego verificar la respuesta.

HTTP y sus métodos

El protocolo de transferencia de hipertexto (hypertext transfer protocol o HTTP) es un sencillo

protocolo cliente-servidor que articula los intercambios de información entre un servidor y una
aplicación que consume estos servicios. Esta comunicación se logra gracias a los métodos
HTTP, los cuales nos permiten enviar y recibir información. En el siguiente video vamos a ver en
forma más profunda estos conceptos y algunos ejemplos.
API’s Testing - Automatización de pruebas

¿Qué son las pruebas automatizadas?

Las pruebas se automatizan mediante la creación de conjuntos de pruebas que se pueden

ejecutar una y otra vez (scripts), y no requieren ninguna intervención manual.

Postman se puede utilizar para automatizar muchos tipos de pruebas, incluidas las unitarias, las
funcionales, de integración, de extremo a extremo, de regresión, las simuladas, etc.

Las pruebas automatizadas evitan errores humanos y agilizan las pruebas.

¿Por qué automatizar una prueba?

A medida que los programas crecen, también aumenta el riesgo de rotura. Se pueden crear
programas más robustos y resistentes a errores aumentando la cobertura y la frecuencia de las
pruebas. Postman permite reutilizar sus conjuntos de pruebas para simplificar el trabajo de
forma más efectiva y productiva.

Automatización de API’s con Postman Tests y JavaScript

Postman Tests permite asegurarnos de que un API funciona como se esperaba. Nos permite
establecer que las integraciones entre los servicios funcionen de manera confiable y verificar
que los nuevos desarrollos no hayan roto ninguna funcionalidad existente. Nos ayuda a verificar
resultados, como el estado exitoso o fallido, la comparación de los resultados esperados, etc.
Esta herramienta nos brinda un conjunto de fragmentos de código javascript con algunas
pruebas por defecto, pero también somos libres de escribir nuestras propias pruebas utilizando
javascript.

Código de respuesta de HTTP:

● 200: «Todo está bien». Este es el código que se entrega cuando una página web o
recurso actúa exactamente como se espera.
● 201: «Creado». El servidor ha cumplido con la petición del navegador y, como resultado,
ha creado un nuevo recurso.
● 204: «Sin contenido». Este código significa que el servidor ha procesado con éxito la
solicitud, pero no va a devolver ningún contenido.
● 301: «El recurso solicitado ha sido trasladado permanentemente». Este código se
entrega cuando una página web o un recurso ha sido reemplazado permanentemente
por un recurso diferente.
● 302: «El recurso solicitado se ha movido, pero fue encontrado». Este código se utiliza
para indicar que el recurso solicitado se encontró, pero no en el lugar donde se
esperaba.
● 400: «Mala petición». El servidor no puede devolver una respuesta debido a un error del
cliente.
● 401: «No autorizado». Esto es devuelto por el servidor cuando el recurso de destino
carece de credenciales de autenticación válidas.
● 403: «El acceso a ese recurso está prohibido». Este código se devuelve cuando un
usuario intenta acceder a algo a que no tiene permiso para ver.
● 404: «No se encontró el recurso solicitado». Este código significa que el recurso
solicitado no existe y el servidor no sabe si alguna vez existió.
● 500: «Hubo un error en el servidor y la solicitud no pudo ser completada». Este es un
código genérico que simplemente significa «error interno del servidor». Algo salió mal en
el servidor y el recurso solicitado no fue entregado.
● 503: «El servidor no está disponible para manejar esta solicitud en este momento.»
Este código puede ser devuelto por un servidor sobrecargado que no puede manejar
solicitudes adicionales.

Patrones de diseño
Los patrones de diseño son soluciones probadas y documentadas a problemas comunes de
desarrollo de software. También son usados en la automatización de software.

Patrones de diseño en automatización

Screenplay:
 ● Este patrón tiene un enfoque de desarrollo encaminado por el
comportamiento Behaviour Driven Development (BDD). Es una estrategia de
desarrollo que se enfoca en prevenir defectos en lugar de encontrarlos en un
ambiente controlado.
● Presenta un alto desacoplamiento de la interfaz de usuario.
● Propone trabajar en términos de tareas y no de interfaz de usuario.
● Cumple con los principios SOLID.

Page Object:

● Es un patrón de diseño que representa los componentes web o página web

en una clase.
● Se utiliza en las pruebas automatizadas para evitar código duplicado y
mejorar el mantenimiento de las mismas.
● No cumple con los principios SOLID.
¿Qué son los principios SOLID?
SOLID es un acrónimo introducido por Robert C.Martin para definir los cinco principios básicos
de la programación orientada a objetos: Single responsibility, Open-closed, Liskov substitution,
Interface segregation y Dependency inversion. SOLID tiene bastante relación con los patrones
de diseño.

Los principios SOLID son guías, buenas prácticas, que pueden ser aplicadas en el desarrollo de
software para eliminar malos diseños. Provocan que el programador tenga que refactorizar el
código fuente hasta que sea legible y extensible. Es decir, que pueden ayudar a escribir un
mejor código: más limpio, mantenible y escalable.

Algunos de los objetivos a tener en cuenta estos principios para código son:

● Crear un software eficaz que cumpla con su cometido y que sea robusto y
estable.
● Escribir un código limpio y flexible ante los cambios: que se pueda modificar
fácilmente según necesidad, que sea reutilizable y mantenible.
● Permitir escalabilidad: que acepte ser ampliado con nuevas funcionalidades
de manera ágil.

En definitiva, desarrollar un software de calidad.

Page Object Model

Page Object Model, también llamado POM, es la implementación del patrón de diseño Page
Object utilizado en la automatización de pruebas. Tiene como objetivo mejorar el mantenimiento
de las pruebas y reducir la duplicación de código.
El concepto básico en el que se basa el Page Object Model es el de representar cada una de las
pantallas que componen al sitio web o la aplicación que nos interesa probar como una serie de
objetos que encapsulan las características (localizadores) y funcionalidades representadas en la
página. De esta manera, nos permite consolidar el código para interactuar con los elementos de
una página en cada uno de los PageObjects.

Las páginas web se representan como clases y los diversos elementos de la página se definen
como variables en la clase. Todas las interacciones de usuario posibles se pueden implementar
como métodos en la clase. Estas interacciones generalmente se dividen en acciones y
validaciones. Las acciones reflejarán aquellos pasos que el usuario debe realizar dentro del sitio
web o aplicación que se encuentra bajo prueba. En cambio, las validaciones serán métodos que
reflejen la confirmación de que el sistema se comporta como se espera luego de una acción
específica.

Cualquier cambio que se produzca en la UI únicamente afectará al PageObject en cuestión, no a

los test ya implementados.

Selenium WebDriver
Selenium WebDriver es uno de los frameworks más importantes con los que se generan
pruebas automatizadas.

Es un conjunto de herramientas para la automatización de navegadores web que utiliza las

mejores técnicas disponibles para controlar las instancias de los navegadores y emular la
interacción del usuario con el navegador.

Permite a los usuarios simular interacciones realizadas por los usuarios finales: como insertar
texto en los campos, seleccionar valores de menús desplegables y casillas de verificación, y
mucho más. Además también permite realizar validaciones en el comportamiento de cualquier
componente. Esto nos sirve para verificar el comportamiento esperado que se encuentra
detallado en los casos de prueba diseñados y listos para ser automatizados.

WebDriver utiliza las API de automatización del navegador proporcionadas por los
desarrolladores de los navegadores para controlarlo y ejecutar pruebas. Esto es como si un
usuario real estuviera manipulándolo con la principal diferencia en la velocidad de ejecución,
WebDriver es considerablemente más veloz que una ejecución manual.

Selenium es compatible con muchos lenguajes de programación como Java, C #, Python, etc., y
con múltiples navegadores como Google Chrome, Firefox, Intebrowser driverSelenium
Webdriver se enmarca en tres componentes principales:

● Los tests a ejecutarse (escritos con un lenguaje a elección entre varios como Java, C#,
Node JS, etc);“Client API”.
● Un servidor standalone en donde se ejecutarán los casos de prueba.
● Un browser driver que conectará los scripts generados con la client API con el browser a
través del Selenium Server.
Gráficamente puede verse así:

Test Plan: Introducción

En 1962, la NASA lanzó la Mariner 1 como su primer intento de enviar una nave espacial a
Venus. Sin embargo, poco después de su lanzamiento, el cohete se desvió de su curso y se vio
obligado a autodestruirse. ¿El costo? $135 millones (en dólares de hoy). ¿La cuestión? Falta de
un guion en el código.

Es por eso que antes de que los usuarios tengan acceso a cualquier software o función nueva,
debemos ponerlo a prueba a fondo: probar e intentar romperlo. Debemos asegurarnos de que
todo lo que hagan los usuarios, responda según lo diseñado. En resumen, necesitamos un plan
de prueba o también conocido como test plan.

Un plan de prueba es una de las partes más importantes de cualquier proceso de desarrollo de
software. Describe cómo se asegurará de que nuestro producto o función haga lo que se supone
que debe hacer y no se rompa cuando los usuarios más lo necesiten.
5 pasos para crear un Test Plan:

1. Analizar el producto o la función que estamos probando:

Debemos tener un conocimiento profundo del producto o función antes de poder

comenzar a crear un plan de prueba para él. Este primer paso es lo que le brinda el
contexto para escribir la introducción y los objetivos del plan de prueba y comenzar a
planificar los recursos que necesitará para completarlo.

2. Diseñar las estrategias de prueba (y el enfoque) que utilizaremos:

Decidir qué probar y documentar en nuestra estrategia de prueba son las partes más
críticas del plan de prueba. Lo que se incluye en el alcance de las pruebas dependerá de
una serie de factores más allá del producto o la función. Necesitamos profundizar y
pensar en:

● Requisito del cliente: ¿qué van a utilizar más nuestros usuarios?

● Presupuesto y cronograma: ¿cuánto tiempo y recursos tenemos para completar
las pruebas?
● Especificaciones del producto: ¿cuáles son las partes más importantes de esta
función que deben probarse?
● Habilidades del equipo: ¿tenemos la experiencia técnica necesaria para completar
cada prueba?

3. Definir los objetivos de la prueba y los criterios de aprobación/reprobación:

A medida que definimos cada prueba diferente que se va a ejecutar, necesitamos saber
cuándo está terminada. Esto implica definir los criterios de aprobación y reprobación para
cada prueba específica, así como algunos ítems mencionados, como los criterios de
salida y suspensión.

4. Planificar el entorno de prueba:

Los resultados de nuestro plan de prueba dependen tanto de la función que esté
probando como del entorno en el que se esté probando. Como parte del alcance,
debemos determinar qué combinaciones de hardware, software, sistema operativo y
dispositivo deseamos utilizar.

5. Ejecutar el plan de prueba y realizar un seguimiento del progreso:

Una vez que nuestro plan de prueba está en su lugar, hay un proceso específico que
debemos seguir. Pensemos en esto como el ciclo de vida de las pruebas de software
(STLC) que vimos al comienzo de la materia.
Técnicas de prueba
 1. Categorías de técnicas de prueba
Agenda 2. Técnicas de caja negra
3. Técnicas basadas en la experiencia

Técnicas de prueba
 Categorías de técnicas
1 de prueba

Técnicas de prueba
 El objetivo de una técnica de prueba
es ayudar a identificar las
condiciones, los casos y los datos
de prueba.

Técnicas de prueba
 Elección de una técnica de prueba
La elección de la técnica de prueba a utilizar depende de los siguientes
factores:
● Tipo y complejidad del componente o sistema
● Estándares de regulación
● Requisitos del cliente o contractuales
● Clases y niveles de riesgo
● Objetivo de la prueba
● Documentación disponible
● Conocimientos y competencias del probador
● Modelo del ciclo de vida del software
● Tiempo y presupuesto

Técnicas de prueba
 Clasificación de las técnicas de prueba
Técnicas de caja negra:
Se basan en el comportamiento extraído del análisis de los documentos que
son base de prueba (documentos de requisitos formales, casos de uso,
historias de usuario, etc). Son aplicables tanto para pruebas funcionales como
no funcionales. Se concentran en las entradas y salidas sin tener en cuenta
la estructura interna.

Técnicas de caja blanca:

Se basan en la estructura extraída de los documentos de arquitectura, diseño
detallado, estructura interna o código del sistema. Se concentran en el
procesamiento dentro del objeto de prueba.

Técnicas basadas en la experiencia:

Aprovechan el conocimiento de desarrolladores, probadores y usuarios para
diseñar, implementar y ejecutar las pruebas.

Técnicas de prueba
 2 Técnicas de caja negra

Técnicas de prueba
 Partición de equivalencia
En esta técnica se dividen los datos en particiones conocidas como clases de equivalencia donde
cada miembro de estas clases o particiones es procesado de la misma manera.
Las características de esta técnica son:

● La “partición de equivalencia válida” contiene valores que son aceptados por el componente
o sistema.
● La “partición de equivalencia no válida” contiene valores que son rechazados por el
componente o sistema.
● Se pueden dividir las particiones en subparticiones.
● Cada valor pertenece a solo una partición de equivalencia.
● Las particiones de equivalencia no válidas deben probarse en forma individual para evitar el
enmascaramiento de fallos.

● La cobertura se mide de la siguiente manera: Cobertura = Particiones probadas

Particiones identificadas

Técnicas de prueba
 Análisis de valores límites
Partición de
Es una extensión de la técnica de partición de equivalencia equivalencia
válida
que solo se puede usar cuando la partición está ordenada, Valor límite Valor límite
y consiste en datos numéricos o secuenciales. mínimo máximo

● Se deben identificar los valores límites mínimo y máximo (o valores inicial y final).
● Se pueden utilizar 2 o 3 valores límites.
● Para 2 valores límites se toma el valor que marca el límite (como valor que corresponde a la
partición válida), y el valor anterior o posterior que corresponda a la partición de
equivalencia inválida.
● Para 3 valores límites se toma el valor que marca el límite, un valor anterior y otro posterior
a ese límite.
● La cobertura se mide de la siguiente manera: Cobertura = Valores límites probados
Valores límites identificados

Técnicas de prueba
 Tabla de decisión
Esta técnica se utiliza para pruebas combinatorias,
formadas por reglas de negocio complejas que un sistema
debe implementar. Las características de esta técnica son:

● Se deben identificar las condiciones (entradas) y las acciones resultantes (salidas). Estas
conforman las filas de la tabla.
● Las columnas de la tabla corresponden a reglas de decisión. Cada columna forma una
combinación única de condiciones y la ejecución de acciones asociadas a esa regla.
● Los valores de las condiciones y acciones pueden ser valores booleanos, discretos,
numéricos o intervalos de números.
● Ayuda a identificar todas las combinaciones importantes de condiciones y a encontrar
cualquier desfase en los requisitos. Cobertura = Número de reglas de decisión probadas
● La cobertura se mide de la siguiente manera: Número de reglas de decisión totales

Técnicas de prueba
 Transición de estados
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. Las características de esta técnica son:

● Una tabla de transición de estado muestra todas las transiciones válidas y las transiciones
potencialmente inválidas entre estados, así como los eventos, las condiciones de guarda y
las acciones resultantes para las transiciones válidas.
● Los diagramas de transición de estado, normalmente, sólo muestran las transiciones
válidas y excluyen las transiciones no válidas.
● La prueba de transición de estado se utiliza para aplicaciones basadas en menús y es
extensamente utilizada en la industria del software embebido. La técnica también es
adecuada para modelar un escenario de negocio con estados específicos o para probar la
navegación en pantalla.
Cobertura = número de estados o transiciones identificados probados
● La cobertura se mide de la siguiente manera: número total de estados o transiciones identificados en el objeto de prueba

Técnicas de prueba
 Técnicas basadas en la
3 experiencia

Técnicas de prueba
 Predicción de errores
Esta técnica se utiliza para anticipar la ocurrencia de
equivocaciones, defectos y fallos basados en el
conocimiento del probador.

Se crea una lista teniendo en cuenta:

● Cómo ha funcionado la aplicación en el pasado.
● Equivocaciones comunes en los desarrolladores.
● Fallos en aplicaciones relacionadas.

En base a esa lista se diseñan pruebas que expongan esos fallos y defectos.

Técnicas de prueba
 Prueba exploratoria
En esta técnica se diseñan, ejecutan, registran y
evalúan de forma dinámica pruebas informales durante
la ejecución de la prueba.
Los resultados de estas pruebas se utilizan para
aprender más sobre el funcionamiento del componente
o sistema.
Generalmente se utilizan para complementar otras
técnicas formales o cuando las especificaciones son
escasas, inadecuadas o con restricciones de tiempo.

Técnicas de prueba
 Prueba basada en listas de comprobación
En esta técnica se diseñan, implementan y ejecutan casos
de prueba que cubren las condiciones que se encuentran en
una lista de comprobación definida.
Se crean basadas en la experiencia y conocimiento de lo que
el probador cree que es importante para el usuario y se
utilizan debido a la falta de casos de prueba detallados.
Durante la ejecución puede haber cierta variabilidad,
dependiendo de quién ejecuta la prueba y condiciones del
contexto. Esto da lugar a una mayor cobertura.

Se utiliza tanto en pruebas funcionales como no funcionales.

Técnicas de prueba
Técnicas de prueba
Frameworks de
automatización
de pruebas
 1. Generalidades
Agenda 2. Tipos de frameworks

Test Automation Frameworks

 1 Generalidades

Test Automation Frameworks

 Un framework define un conjunto
de reglas, pautas o mejores
prácticas que podemos seguir de
manera sistemática para lograr los
resultados deseados.

Test Automation Frameworks

 Generalidades
Un framework de automatización de pruebas es un
conjunto de pautas —como estándares de codificación,
manejo de datos de prueba, tratamiento de repositorios
de objetos, etc.— que, cuando se siguen durante la
secuencia de comandos de automatización, traen
beneficios tales como una mayor reutilización de
código, mayor portabilidad, menor costo de
mantenimiento de secuencias de comandos, etc.

Son pautas y no reglas en el sentido estricto de la

palabra, ya que no son obligatorios. Se puede escribir un
script sin seguir las pautas, pero se perderán las ventajas
de tener un framework.

Test Automation Frameworks

 Tipos
2 de frameworks

Test Automation Frameworks

 Framework de
prueba basado en Framework de prueba
Framework de palabras clave de desarrollo guiado
secuencias de por el comportamiento
comandos lineal

Tipos de frameworks para

automatización de pruebas

Framework de Framework de prueba

prueba modular híbrido

Framework de prueba
basado en datos

Test Automation Frameworks

 Framework de secuencias de comandos lineal

Conocido como grabación y reproducción es el

más simple de todos los frameworks de
automatización de pruebas ya que el tester registra
manualmente cada paso —navegación y entradas
del usuario— e inserta puntos de control —pasos
de validación— en la primera iteración. Luego,
reproduce el script grabado en las iteraciones
siguientes.

Ejemplos: Selenium GRID, UFT, Test Complete,

Sahi.

Test Automation Frameworks

 Framework de secuencias de comandos lineal

● La forma más rápida de generar un script.

● No se requiere experiencia en automatización.
● La forma más sencilla de conocer las
funciones de la herramienta de prueba.

● Poca reutilización de guiones.

● Los datos de prueba están codificados en el script.
● Pesadilla de mantenimiento.

Test Automation Frameworks

 Framework de prueba modular
En el framework de prueba modular, los probadores crean módulos de
scripts de prueba dividiendo la aplicación completa bajo prueba en pruebas
independientes más pequeñas.
En palabras simples, los evaluadores dividen la aplicación en varios módulos y
crean scripts de prueba individualmente. Estos se pueden combinar para hacer
scripts de prueba más grandes utilizando uno maestro para lograr los
escenarios requeridos. Este script maestro se utiliza para invocar los módulos
individuales para ejecutar escenarios de prueba de un extremo a otro (E2E).
La razón principal para usar este framework es construir una capa de
abstracción para proteger el módulo maestro de cualquier cambio realizado en
las pruebas individuales.

Test Automation Frameworks

 Framework de prueba modular

● Mejor escalabilidad y más fácil de mantener debido a la

división de la aplicación completa en diferentes módulos.
● Puede escribir scripts de prueba de forma independiente.
● Los cambios en un módulo tienen un impacto nulo o bajo
en los otros módulos.

● Toma más tiempo analizar los casos de prueba e identificar

flujos reutilizables.
● Debido a los datos codificados en los scripts de prueba no es
posible demandar varios conjuntos de datos.
● Requiere habilidades de codificación para configurar el
framework.

Test Automation Frameworks

 Framework de prueba basado en datos
En este framework, mientras que la lógica del caso de prueba reside en los
scripts de prueba, los datos de prueba se separan y se mantienen fuera de
los scripts de prueba.
Los datos de prueba se leen de los archivos externos —archivos de Excel,
archivos de texto, archivos CSV, fuentes ODBC, objetos DAO, objetos ADO— y
se cargan en las variables dentro del script de prueba.
Las variables se utilizan tanto para los valores de entrada como para los
valores de verificación. Los scripts de prueba se preparan utilizando Linear
Scripting o Test Library Framework.
Ejemplo: UFT, Specflow (C#)

Test Automation Frameworks

 Framework de prueba basado en datos
● Los cambios en los scripts de prueba no afectan los
datos de prueba.
● Los casos de prueba se pueden ejecutar con
múltiples conjuntos de datos.
● Se puede ejecutar una variedad de escenarios de
prueba simplemente variando los datos de prueba
en el archivo de datos externo.

● Se necesita más tiempo para planificar y preparar

tanto los scripts de prueba como los datos de prueba.

Test Automation Frameworks

 Framework de prueba basado en palabras clave
Es conocida como prueba basada en tablas o prueba basada en palabras
de acción. El desarrollo de este framework requiere tablas de datos y palabras
clave, independientemente de la herramienta de automatización de pruebas
utilizada para ejecutarlas.
Las pruebas se pueden diseñar con o sin la aplicación. En una prueba basada en
palabras clave, la funcionalidad de la aplicación bajo prueba se documenta en
una tabla, así como en instrucciones paso a paso para cada prueba.
Aunque trabajar en este framework no requiere muchas habilidades de
programación, la configuración inicial —implementarlo— requiere más
experiencia.
Ejemplo: Robot Framework (Python).

Test Automation Frameworks

 Framework de prueba basado en palabras clave

● Proporciona una alta reutilización de código.

● Herramienta de prueba independiente.
● Aunque la aplicación cambie, los scripts de prueba no cambian.
● Las pruebas se pueden diseñar con o sin la aplicación bajo prueba.

● Dado que la inversión inicial es bastante alta, los beneficios

de esto solo se pueden obtener si la aplicación es
considerablemente grande y los scripts de prueba deben
mantenerse durante bastantes años.
● Se requiere una gran experiencia en automatización para
crear el framework basado en palabras clave.

Test Automation Frameworks

 Framework de prueba híbrido
El framework de automatización de pruebas
híbridas es la combinación de dos o más frameworks
mencionados anteriormente.
Intenta aprovechar las fortalezas y los beneficios de
otros frameworks para el entorno de prueba
particular que administra.
La mayoría de los equipos están construyendo este
framework impulsado por híbridos en el mercado
actual. La industria generalmente utiliza el framework
de palabras clave en una combinación con el de
descomposición de funciones.
Ejemplo: Karate-DSL, Citrus, etc.

Test Automation Frameworks

 Framework de prueba de desarrollo
guiado por el comportamiento
El propósito de este framework de desarrollo guiado por el
comportamiento es crear una plataforma que permita
a todos —como analistas de negocios, desarrolladores,
probadores, etc.— participar activamente. Requiere
una mayor colaboración entre los equipos de desarrollo y
prueba, pero no requiere que los usuarios estén
familiarizados con un lenguaje de programación. se utiliza
un lenguaje natural no técnico para crear especificaciones
de prueba —Gherkin—.
Algunas de las herramientas disponibles en el mercado
para el desarrollo impulsado por el comportamiento son
JBehave (Java) , Cucumber , Specflow (C#), Serenity, etc.

Test Automation Frameworks

 Conclusión
Estos son los beneficios generales de contar con un
framework de prueba:
● Ayuda a reducir el riesgo y los costos.
● Mejora la eficiencia de las pruebas.
● Ayuda a reducir el costo de mantenimiento.
● Permite la reutilización de código
● Permite alcanzar la máxima cobertura de
prueba.
● Maximiza la funcionalidad de la aplicación.
● Ayuda a reducir la duplicación de casos de
prueba
● Ayuda a mejorar la eficiencia y el rendimiento de
la prueba con la automatización de la prueba.

Test Automation Frameworks

Test Plan
 1. ¿Qué es un Plan de pruebas y

Agenda cuál es su utilidad?

2. Características de un buen
Plan de pruebas

Test Plan
 ¿Qué es un Plan
1 de pruebas y cuál
es su utilidad?

Test Plan
 Plan de pruebas

Un plan de prueba es un documento detallado

que describe la estrategia de prueba, los
objetivos, los recursos necesarios, el
cronograma y los criterios de éxito para probar
una nueva característica o pieza de software
específica.
El objetivo principal, por supuesto, es descubrir
defectos, errores y cualquier otra brecha que
pueda hacer que el software no actúe como se
esperaba o que brinde una mala experiencia a sus
usuarios.

Test Plan
 Pero entonces, ¿cuáles son los objetivos?
Un plan de prueba garantiza que el software:

Cumple con los requisitos que guiaron su

diseño y desarrollo, en otras palabras:
¿hace lo que se supone que debe hacer
cuando debe hacerlo?

Test Plan
 Pero entonces, ¿cuáles son los objetivos?

Un plan de prueba garantiza que el software:

Responde según lo esperado a

todo tipo de entradas.

Test Plan
 Pero entonces, ¿cuáles son los objetivos?

Un plan de prueba garantiza que el software:

Cumple con los estándares de

rendimiento descritos y se puede
utilizar según lo previsto.

Test Plan
 Pero entonces, ¿cuáles son los objetivos?

Un plan de prueba garantiza que el software:

Se puede instalar y
ejecutar en todos los
entornos previstos.

Test Plan
 Pero entonces, ¿cuáles son los objetivos?

Un plan de prueba garantiza que el software:

Logra los resultados esperados

por las partes interesadas y el
equipo de QA.

Test Plan
 Características
2 de un buen
Plan de pruebas

Test Plan
 ¿Qué debería incluirse en la
plantilla del plan de prueba?
Cada producto y función tendrá sus propios
criterios, estrategias y necesidades de
prueba específicos, además, el objetivo de la
prueba cambiará la forma en que lo aborda.

Por ejemplo, las pruebas de aceptación del

usuario (UAT) son completamente diferentes de
las pruebas de estrés y carga, y su plan deberá
adaptarse a su objetivo final.

Test Plan
 ¿Qué debería incluirse en la
plantilla del plan de prueba?
Entonces, ¿qué debería (o podría) incluir en mi plan de prueba?
En términos generales, hay algunas áreas principales que son convenientes
incluir y que actuarán como la base del documento:

1. Cobertura: 2. Métodos: 3. Responsabilidades:

¿Qué se está probando ¿Cómo se van a realizar ¿Cuáles son los
exactamente? estas pruebas? resultados deseados?

Test Plan
 1. Cobertura: ¿Qué se está probando exactamente?

Un plan de pruebas debe ser completo, pero no abrumador, es decir, ser

específico sobre lo que se incluirá y lo que no.
Después de una breve introducción que destaca los objetivos del plan de
prueba, el alcance de alto nivel y el cronograma, se deberá definir lo que se
probará o no probará.

● ¿Qué pruebas va a realizar?

● ¿Por qué ha elegido estos (y no otros)?

Test Plan
 2. Métodos: ¿Cómo se van a realizar estas pruebas?
A continuación, se debe explicar tan detalladamente
como sea posible: ¿cuál es la estrategia de prueba?

● ¿Qué reglas seguirán las pruebas?

● ¿Qué métricas se van a recopilar y a qué nivel?
● ¿Cuántas configuraciones o entornos
diferentes se van a probar?
● ¿Existen requisitos o procedimientos
especiales que se deban probar?

Test Plan
 2. Métodos: ¿Cómo se van a realizar estas pruebas?
También se necesita saber cuándo la prueba fue exitosa, es decir:
¿cuáles son los criterios de aprobación/reprobación para cada prueba?
Estos criterios incluyen:
● Criterio de salida: ¿cuándo está bien dejar de probar una función y asumir que la
función tiene éxito en hacer lo que se propuso hacer?
● Criterios de suspensión: ¿cuándo debería pausar una prueba? ¿Existe un umbral de
errores en el que debería dejar de realizar pruebas y empezar a buscar soluciones?
¿Cuáles son los pasos para cerrarlo y documentar lo que se ha hecho hasta ahora?
● Requisitos de reanudación: ¿cómo se sabe cuándo reanudar una prueba en
pausa? ¿Cuáles son los pasos para revisar lo que se ha hecho y retomar?

Test Plan
 2. Métodos: ¿Cómo se van a realizar estas pruebas?
Por otro lado, es una buena idea en este punto enumerar las suposiciones y
riesgos.
En otras palabras: ¿qué se supone que va a suceder y cuáles son algunos de
los riesgos durante las pruebas?

Por último, describir las necesidades de recursos y el cronograma del proyecto

de prueba.

Es decir: ¿Quién está a cargo de las pruebas y qué recursos necesitan

(tanto técnicos como humanos)? ¿Cuándo se realizarán las pruebas y
durante cuánto tiempo?

Test Plan
 3. Responsabilidades: ¿Cuáles
son los resultados deseados?
¿Cuáles son los entregables de prueba
requeridos?
Esto significa los datos que se desean
recopilar, cómo agruparlos en los informes y
los problemas y tareas que se devolverán al
equipo de desarrollo.
Para asegurarse de que no se pierda nada,
cada entrega de prueba debe asignarse a
una persona específica del equipo en una
sección sobre roles y responsabilidades.

Test Plan
Test Plan
Tipos de prueba
Un tipo de prueba es un grupo de actividades de pruebas destinadas a probar las características específicas de un sistema de software,
o de una parte de un sistema, basados en objetivos de pruebas específicas.

Dichos objetivos pueden incluir:

1. Evaluar las características de calidad funcional tales como la completitud, corrección y pertinencia.
2. Evaluar características no funcionales de calidad, tales como la fiabilidad, eficiencia de desempeño, seguridad, confiabilidad y
usabilidad.
3. Evaluar si la estructura o arquitectura del componente o sistema es correcta, completa y según lo especificado.
4. Evaluar los efectos de los cambios, tales como confirmar que los defectos han sido corregidos (prueba de confirmación) y buscar
cambios no deseados en el comportamiento que resulten de los cambios en el software o en el entorno (prueba de regresión)

1
 1. Prueba Funcional 2. Prueba No Funcional 3. Prueba Estructurales 4. Prueba Asociada al Cambio

Definición La prueba funcional de La prueba no funcional Éstas pruebas están Existen 2 tipos de prueba
un sistema incluye prueba “cómo de bien” se basadas en la estructura relacionadas al cambio:
pruebas que evalúan las comporta el sistema. interna del sistema o en ● Prueba de confirmación:
funciones que el sistema su implementación. La Una vez corregido un
debe realizar. Las estructura interna puede defecto, el software se
funciones describen qué incluir código, puede probar con todos
hace el sistema. arquitectura, flujos de los casos de prueba que
trabajo y/o flujos de fallaron debido al defecto,
datos dentro del sistema que se deben volver a
ejecutar en la nueva
versión de software. El
objetivo de una prueba
de confirmación es
confirmar que el defecto
original se ha solucionado
de forma satisfactoria.

● Prueba de regresión: Es
posible que un cambio
hecho en una parte del
código, ya sea una
corrección u otro tipo de
cambio, pueda afectar
accidentalmente el
comportamiento de otras

2
 partes del código, ya sea
dentro del mismo
componente, en otros
componentes del mismo
sistema, o incluso en
otros sistemas. La prueba
de regresión implica la
realización de pruebas
para detectar estos
efectos secundarios no
deseados.

Implementa La prueba funcional El diseño y ejecución de la El diseño y la ejecución Especialmente en los ciclos de
ción observa el prueba no funcional puede de este tipo de pruebas vida de desarrollo iterativos e
comportamiento del implicar competencias y pueden implicar incrementales (por ejemplo,
software. conocimientos especiales, competencias o Agile), las nuevas características,
como el conocimiento de conocimientos los cambios en las características
las debilidades inherentes especiales, como la existentes y la refactorización del
a un diseño o tecnología forma en que se código dan como resultado
-por ejemplo: construye el código, cambios frecuentes en el código,
vulnerabilidades de cómo se almacenan los lo que también requiere pruebas
seguridad asociadas con datos, y cómo utilizar las asociadas al cambio.
determinados lenguajes de herramientas de
programación-. cobertura e interpretar
correctamente sus
resultados.

3
Niveles de Se pueden realizar Se pueden realizar pruebas Se puede realizar en el La prueba de confirmación y la
Prueba pruebas funcionales en no funcionales en todos los nivel de componente y de prueba de regresión se realizan
todos los niveles de niveles de prueba integración. en todos los niveles de prueba
prueba.

Alcance Los requisitos La prueba no funcional del En el nivel de prueba de

funcionales pueden sistema evalúa integración de
estar detallados en los características como la componentes, la prueba
siguientes documentos: usabilidad, la eficiencia del estructural pueden
especificaciones de desempeño o la seguridad. basarse en la
requisitos del negocio, arquitectura del sistema,
épicas, historias de como las interfaces entre
usuarios, casos de uso componentes
y/o especificaciones
funcionales.

Cobertura La cobertura funcional La cobertura no funcional La cobertura estructural Los juegos de prueba de
es la medida en que es la medida en que algún es la medida en que regresión se ejecutan muchas
algún tipo de elemento tipo de elemento no algún tipo de elemento veces y generalmente
funcional ha sido funcional ha sido estructural ha sido evolucionan lentamente, por lo
practicado por pruebas, practicado por pruebas, y practicado mediante que la prueba de regresión es un
y se expresa como un se expresa como un pruebas, y se expresa fuerte candidato para la
porcentaje del tipo o porcentaje del tipo o tipos como un porcentaje del automatización.
tipos de elementos de elementos cubiertos. tipo de elemento La cobertura crece a medida que
cubiertos. cubierto. se agregan más funcionalidades
al sistema por lo tanto más
pruebas de regresión

4
Nuestro primer
test unitario
con JavaScript
 1. Configurar el framework
Índice 2. Nuestro primer test
3. Agrupar unit tests
 Configurar
1 el Framework

Unit Testing
 Framework para JavaScript
Para JavaScript vamos a utilizar el framework Jest. Si queremos
configurarlo, debemos instalar:

1. Un IDE (el recomendado es Visual Studio Code

(https://code.visualstudio.com)

2. Node.js (https://nodejs.org).

Debemos tener en cuenta que si el código brindado no posee

el archivo package.json debemos crearlo, ya que aquí se van
a guardar todas las configuraciones de nuestro proyecto. Para
crearlo debemos correr en la terminal el comando: npm init -y

Unit Testing
 3. JEST (https://jestjs.io/)

Para incluir Jest dentro de nuestro proyecto debemos correr

en la terminal el comando: npm install --save-dev jest
(tener en cuenta que esto debemos realizarlo en cada uno
de los proyectos que vamos a trabajar).

Unit Testing
 Nuestro
2 primer test

Unit Testing
 Crear nuestro primer unit test

Bajar el código fuente del

1
siguiente repositorio:
https://github.com/academind
/js-testing-introduction/tree/s
tarting-setup.

Este programa solicita el

ingreso de Nombre y Edad
y al presionar el botón
Agregar Usuario arma una
lista con los datos
ingresados.

Unit Testing
 Configurar Jest como ejecutor de las pruebas:
2
1. Ir al archivo package.json.
2. En la parte de scripts/test debemos
reemplazar “echo “Error: no test
specified” && exit 1” por “jest”. De esta
forma indicamos que vamos a correr test
con nuestro framework Jest.

Unit Testing
 2

Configurar Jest como ejecutor

de las pruebas:
1. Ir al archivo
package.json.
2. En la parte de scripts/test
debemos reemplazar
“echo “Error: no test
specified” && exit 1” por
“jest”. De esta forma
indicamos que vamos a
correr test con nuestro
framework Jest.

Unit Testing
 Crear la carpeta y archivo de prueba:
3
1. Crear la carpeta __test__ donde se
encontrarán todos los archivos de prueba.
2. Crear el archivo de prueba
NombreArchivo.test.js. Para que Jest
reconozca los archivos de prueba deben
terminar en .test.js. En este caso nuestro
archivo se llamará util.test.js.

Unit Testing
 3

Unit Testing
 Importar el código a probar: debemos importar la sección del código que
4 queremos probar. En este caso vamos a probar el que se encuentra en el
archivo util.js, ya que ahí se encuentra la lógica de nuestro programa.

Unit Testing
 Escribir el código del unit test. Las funciones claves a utilizar son:
5
● test() o it(): donde se define el test. Se debe ingresar un nombre representativo.
● expect(): lo que se desea verificar es parte de la assertion library. En el ejemplo se
quiere verificar la salida que se genera al presionar el botón Agregar Usuario.

Unit Testing
 Para ejecutar el test,
6
primero debemos abrir la
terminal y, luego, ejecutar
el comando npm test.

Unit Testing
 Se puede configurar que los tests
7 se ejecuten cada vez que se
genera un cambio en el código.
Para ello, debemos ir al archivo
package.json e ingresar jest
--watchAll en el nodo “test” que
está dentro de “scripts”.

Unit Testing
 Luego, ejecutar el siguiente
comando: npm test.
Allí, se debe realizar alguna
modificación en el código del
programa (util.js) y, por último, al
momento de guardar el archivo
modificado, se ejecutarán los tests.

Unit Testing
 Agrupar
3 unit tests

Unit Testing
 Agrupar unit tests
8 Para generar
agrupaciones de unit
tests se utiliza la
siguiente palabra clave:
describe()
Esto será útil para
organizar las pruebas de
acuerdo a las
funcionalidades a probar.

Unit Testing