Introducción a QA - Metodología

¿Qué es un QA?
Para resumir en un par de líneas, QA (Quality Assurance) o Aseguramiento de
Calidad, hace referencia a la forma de medir la calidad, no solo del producto, sino
también del proceso de desarrollo.

Existen dos perfiles muy marcados en el mundo del software, los cuales son el Tester y
el QA. Es de suma importancia saberlos diferenciar bien, debido a que son dos roles
totalmente distintos y cada uno tiene sus respectivas responsabilidades.

Tareas de un Tester
• Diseñar el plan de pruebas.
• Definir los casos de prueba en base a los requisitos funcionales, no funcionales y
técnicos. • Test de integración: Definir las pruebas de Integración que se realizarán. •
Generar datos o lotes de prueba.
• Ejecutar los casos de prueba.
• Realizar la documentación de las pruebas (evidencia).
• Registrar los incidentes encontrados durante la fase de pruebas, así como también
realizar su seguimiento para asegurar su adecuada corrección.
• Pruebas avanzadas (carga, estrés, performance, seguridad, etc)

Tareas de un QA
• Diseño y preparación de la estrategia general de Calidad • Revisión de historias
de usuario con el Product Owner.
• Revisión de criterios de aceptación (a partir de los cuales se genera escenarios
de prueba).
• Identificación dependencias entre las historias de usuario.
• Sugiere mejoras funcionales y de usabilidad.
• Identifica los escenarios y flujos más vitales del negocio.
• Colaboración junto con los stakeholders en las pruebas UAT
• Preparación de ambientes de prueba.
• Seguimiento de releases.
• Automatización de pruebas funcionales (BDD, E2E, etc).
• Creación y aplicación de las métricas de calidad de Software.
• Mas todo lo listado en la lista del Tester.

Metodologías de trabajo
Con el tiempo, las metodologías de trabajo fueron adaptándose a las nuevas exigencias
del mercado.
Cascada
Esta metodología puede verse en bancos o proyectos gubernamentales. Es una
metodología vieja y casi obsoleta, pero entenderla sirve para entender cómo evolucionó
en el tiempo.
Esta metodología se basa en pedirle al cliente todos los requerimientos de la
aplicación, luego se hace el diseño de la misma (mockups, modelo de base de datos,
etc) Cuando ya tenemos todo eso, se desarrolla y se implementa. Finalmente
procedemos a verificarla o testear para ver si funciona bien y se presenta al cliente. En
caso de que la aplicación cumpla con todos los requisitos, ya queda productiva y
empieza la etapa de mantenimiento.
En caso de que contenga errores, nuevamente se deben revisar los requisitos y volver
a empezar desde el principio.

requisitos -> diseño -> implementación -> verificación -> mantenimiento

Kanban
En la actualidad se utilizan otras metodologías de trabajo que son ágiles. Entre ellas
se encuentra Kanban.
Kanban es muy utilizada en proyectos pequeños y para implementarla se utiliza un
pizarrón o un tablero.

Este tablero tiene varias columnas y cada una de ellas representa un

estado. Con tarjetas o post it, representamos las tareas a desarrollar.
Cada card o cada post it, se asigna a una persona distinta del equipo. De esta forma,
es fácil saber qué está haciendo cada persona y en qué estado está esa tarea

Scrum
Scrum es un framework que puede ser aplicado a cualquier tipo de proyecto. Desde
la construcción de un edificio, hasta el desarrollo de un software

Tiene como finalidad entregar al cliente algo utilizable después de cada iteración, con el
fin de poder sacar rápidamente un MVP de un producto y probarlo en el mercado.

Scrum tiene varias ceremonias (reuniones) y cada una de ellas con un objetivo en particular.

1. Planificación del Sprint o Sprint Planning

2. Reuniones Scrum Diarias o Daily Meetings
3. Refinamiento
4. Sprint review - Demo
5. Retrospectiva
Casos de prueba - Test suite - Test plan
¿Qué es un Caso de prueba o Test Case?
Un caso de prueba es el elemento menor de una prueba de calidad.

Consta de un conjunto de valores de entrada, condiciones previas de ejecución,

condiciones de ejecución y resultados esperados, y es desarrollado para cubrir las
condiciones de prueba determinadas.

En otras palabras: todas las situaciones posibles a las cuales vamos a someter a prueba
a un sistema.

¿Cómo sabemos cuándo comenzar a crear un caso de prueba?

Un caso de prueba deberá comenzar a confeccionarse paralelamente al inicio de un

proyecto: es decir, cuando los programadores van desarrollando, nuestra tarea consiste
en escribir los test cases.
Al haber observado las historias de usuario, haber realizado un testing exploratorio,
haber recolectado información del funcionamiento de la aplicación con el cliente o el PO,
ir conociendo las reglas del negocio, leer la documentación funcional… En base a toda
esta información recaudada, imaginamos como sería la pantalla y escribimos los test
cases pensando en cada cosa que podría probarse en ella.
Un QA se “adueña” y conoce el proyecto con claridad, pues se dedica a estudiar la
aplicación y busca la forma de probarlo exhaustivamente para encontrar toda la
calidad posible en el resultado final. Es importante clarificar la idea de cómo
elaboramos las pruebas y cómo aplicar esa idea a aspectos puntuales del producto.

Estrategias para test cases

1. IDENTIFICAMOS PARÁMETROS: Observamos la plataforma a detalle, es decir; cada
pantalla, objetos, campos, pestañas, espacios de trabajo, vistas de lista, tableros… A
medida que se van desarrollando módulos, un QA registra qué pruebas se pueden llevar
a cabo en cada uno.

2. ASIGNAMOS VALORES: Por ejemplo, al llenar un formulario… ¿Permite mayúsculas

o minúsculas?, ¿Se puede usar una cierta cantidad límite de letras o números?...

3. COMBINAMOS RESULTADOS POSIBLES: Si se cumplen los dos pasos anteriores

correctamente, se observan aquellos datos obtenidos y se tendrán en consideración
las opciones que permitan realizar una prueba más eficiente.

Tip: Tener en cuenta que los resultados esperados o casos negativos también pueden
arrojar error, es un buen hábito a tener en cuenta para planificar escenarios de prueba
con distintas variables.

¿Cómo escribimos un caso de prueba

correctamente?
ID: (Un número de identificación único para cada test case)
Título: [Pantalla] (Título breve y descriptivo del error)
Descripción: (Comentar de qué se trata el error y que se logre entender fácilmente
cómo es, de forma resumida y lo más claro posible)
Requerimientos o Precondiciones: (Ingresar a la aplicación según las reglas definidas
por el negocio: ¿el usuario es válido? ¿Hay un entorno definido de pruebas? ¿Cuál?)
Pasos de reproducción: (Se enumeran todos los pasos posibles para replicar el error) 1-
Paso 1 2- Paso 2 (…)
Resultado Actual: (¿Qué es lo que está pasando ahora?)
Resultado Esperado: (¿Cómo debería funcionar la aplicación?)
Screenshot/Video: (Captura de pantalla, gif o video del error
Campos opcionales
Versión: (Versión o “Build” de la aplicación)
Ejemplos: VERSIÓN 1.0, VERSIÓN 2.1.1, etc.
Browser: (Especificar en qué navegador/es se encuentra el
error)
Ejemplos: GOOGLE CHROME, FIREFOX, BRAVE, OPERA,
EDGE, etc.
Ambiente: (Especificar en qué ambiente se encontró el error)
Ejemplos:
Si es en PC: WINDOWS (y su versión), LINUX, MAC
Si es en Mobile: ANDROID, iOS…
¿Cómo ejecutamos el caso de prueba?
¿Qué es un test suite?
Se llama Test Suite a un conjunto de casos de prueba.
Funciona como un contenedor que agrupa al conjunto de test cases.
Es muy útil para organizar la ejecución de pruebas de QA y también para ordenar el
status de las mismas (Si la prueba pasó, está en proceso, falló, no aplica o si no se
ejecutó.) Un mismo caso de prueba se puede añadir a varias Test Suites (Pueden ser
componentes que son comunes a todas las páginas del sistema)

¿Para qué nos puede ayudar organizarnos con test suites?

Un conjunto de pruebas permite categorizar los casos de prueba de tal manera
que coincidan con las necesidades de planificación y análisis.

Se podría establecer por las siguientes razones:

1. Funcionalidad del producto:

Si por ejemplo, tengo varios casos de prueba creados que se relacionan con el login de
una aplicación, se crea la suite de “Login”. Cualquier caso nuevo se puede agregar sobre la
marcha a la suite y se puede ejecutar en la medida de lo posible.

2. Tipo de prueba que hago en el sistema con esa suite:

Pruebas de Regresión, de Humo (Smoke), de Performance, de Aceptación del Usuario

(UAT), etc. Estos conjuntos de pruebas pueden tener cualquier combinación de casos de
prueba que se requieran para la fase de prueba correspondiente. Por lo tanto, 2
conjuntos de pruebas pueden tener test cases iguales o muy diferentes.
Un Test Suite, por ejemplo, puede contener cuatro casos de prueba, que si bien
parecen similares, cada uno tiene un script de prueba independiente:
Caso de prueba #1: Iniciar sesión con usuario válido,
Caso de prueba #2: Iniciar sesión con usuario no válido,
Caso de prueba #3: Iniciar sesión con contraseña válida,
Caso de prueba #4: Iniciar sesión con contraseña no válida. Los conjuntos de pruebas
pueden identificar brechas en un esfuerzo de prueba donde la finalización exitosa de
un caso de prueba debe ocurrir antes de comenzar el siguiente caso de prueba.

¿Qué es un test plan?

Se llama Test Plan a un conjunto que combina suites y test cases.
Un plan de prueba es generalmente un documento general que describe el enfoque de
prueba y las metodologías que se utilizan para probar el proyecto, los riesgos, el
alcance (scope) de la prueba, las herramientas específicas, etc.
Es el nivel más superior en el proceso.

¿Qué necesitamos saber de un plan de pruebas?

Un Plan de pruebas es un registro amplio del proceso de planificación de la prueba. El test
plan también sirve como una forma de probar integraciones o el conjunto de varios
módulos relacionados.
No es necesario agregar todos los test cases de todas las posibles combinaciones, sino
que se puntualizan los más vitales para completar el flujo completo, desde el registro de un
nuevo usuario, hasta el proceso final del producto.

Abarca toda la siguiente información:

● las características que se probarán,
● las etiquetas y sprints,
● todos los suites y casos de prueba,
● quién realizará cada tarea,
● La integración con el resto de los módulos…
Entre otros criterios a elección del equipo de QA.
Casos de prueba - Test suite - Test plan en la herramienta
Herramientas para gestionar pruebas y planes de pruebas:
● Testlink
● TestRail
● XRay
● Test Case Lab
● ALM
● Testpad

Test link es una herramienta para gestionar nuestras pruebas. En la misma vamos a
poder generar nuestras suites, casos de prueba y planes de prueba, como así también
priorizar los casos, asignarlos, colocarle keywords, generar métricas, entre otras
funcionalidades.

Creación de un proyecto
1. Ir a “Gestión de Proyectos de Pruebas”
2. Dar click en botón “Crear”
3. Completar los campos: a. Nombre b. Prefijo c. Descripción del
proyecto 4. Tildar las funciones avanzadas que se necesiten
5. Configurar la herramienta del “Gestor de Defectos”
6. Indicar si es público y si está activo
Creación de una test suite
1. Ir a “Editar Caso(s) de Prueba”
2. Pararse en la carpeta raiz
3. Ir al engranaje que se encuentra en la parte superior de la pantalla 4. Hacer clic en
el icono con el signo +
5. Completar los campos: a. Nombre de la Suite de Pruebas b.
Detalles 6. Click en Guardar
Creación de un caso de prueba
1. Ir a “Editar Caso(s) de Prueba”
2. Pararse en la carpeta raiz
3. Ir al engranaje que se encuentra en la parte superior de la
pantalla 4. Hacer clic en el icono con el signo +
5. Completar los campos: a. Nombre de la Suite de Pruebas b.
Detalles 6. Click en Guardar

Creación y uso de las keywords

1. Ir a “Gestión de Keywords”
2. Hacer clic en “Crear Keyword”
3. Colocar Keyword y, opcional, notas.
4. Guardar
5. Clic en “Asignar a los Casos de Prueba”
6. Ir al caso de prueba
7. Seleccionar las keywords
8. Hacer clic en la flecha hacia la derecha para colocarlas en
asignadas 9. Dar clic en “Asignar”

Creación de un test plan

1. Ir a “Gestión de Planes de Pruebas”.
2. Hacer clic en “Crear”.
3. Colocar Nombre y descripción.
4. Configurar si está activo y público.
5. Hacer clic en “Crear”

Creación de una build

1. Ir a “Gestión de Builds”.
2. Hacer clic en “Crear”.
3. Colocar Nombre y descripción.
4. Colocar la fecha de despliegue.
5. Configurar si está activo y abierta.
6. Hacer clic en “Crear”
Ejecución de caso de prueba
1. Ir a “Access Execute Tests”.
2. Revisar “Plan de Pruebas” y “Build”
3. En filtros colocar los asignados al tester y aplicar el filtro
4. Seleccionar un caso de prueba.
5. Colocar el tiempo de ejecución.
6. Colocar una nota si es necesario.
7. Comenzar la ejecución presionando las caritas o los engranajes dependiendo del
estado de cada uno.

Tipos de Testing
Clasificación: Se pueden clasificar en Funcionales o No Funcionales
Pruebas Funcionales
Su objetivo se basa en comprobar si las funcionalidades del desarrollo se realizaron
siguiendo las especificaciones y requisitos del cliente, como también las
necesidades iniciales.

Exploratorio:
Primera experiencia que el QA tiene sobre la aplicación, suelen basarse en la experiencia
y conocimientos del ejecutor
Es un testing intuitivo, pero no es aleatorio y no se realizan Test Case

Smoke:
Es un test que se realiza no para encontrar errores pero sí para asegurarnos que
las características más importantes del sistema funcionan como se espera En otra
parte el smoke sirve para validar si el deploy fue realizado correctamente Si lleva
Test Case

Unit Test:
Consiste en probar el correcto funcionamiento de una pieza de código, generalmente
una función. Es realizado por los desarrolladores

Integración:
Una vez probadas las funcionalidades por separado se realizan testeos de integración
para verificar que funcionan bien de forma conjunta. Por otro lado, también sirven para
probar la integración con servicios externos.

Regresión
Se realiza cuando hay cambios en el sistema y sirve para verificar que lo que
estaba funcionando no falle Se ejecuta una selección de pruebas relevantes
existentes

Pruebas de aceptación (UAT)

Usualmente son un conjunto de pruebas manuales que se realizan luego de que una
fase de desarrollo ha finalizado Son ejecutadas por el cliente

Pruebas No Funcionales
Se evalúa la forma en que un desarrollo o aplicativo opera, haciendo foco en los atributos
y calidad. Asegurando así una buena experiencia del usuario más allá de las
funcionalidades que debería tener.

Pruebas de Usabilidad (UX)

Tienen como objetivo facilitar la experiencia web del usuario y dejarla más simple e intuitiva.
Pruebas de Performance
Estas pruebas sirven para medir y optimizar nuestras aplicaciones con el fin de reducir
los tiempos de carga Suelen ir de la mano con las pruebas de Stress

Pruebas de Stress
Es una prueba que se le somete al sistema con la finalidad de identificar cuantas
peticiones se pueden hacer al mismo tiempo
Se realizan con software
● FunkLoad
● FWPTT load testing
● loadUI
● jmeter

Pruebas de Volumen
Las pruebas de volumen tienen como objetivo medir el rendimiento de la base de
datos, insertando datos de manera masiva

Pruebas de Seguridad (Pentesting)

Consiste en explorar algún tipo de falla de seguridad que pueda tener la
aplicación Usualmente se enfoca en el Top 10 de OWASP.

Criterios de Aceptación:
Todas las funcionalidades de un sistema deben estar plasmadas en las User Story o
Historias de Usuario. Contienen información sobre todo lo que debe hacer y cómo debe
ser una funcionalidad de la aplicación.

Pruebas Automatizadas
Son pruebas que permiten la optimización de la calidad del software. Pruebas reusables
Bugs y ciclos de vida

Bug Historia
Antes de comenzar definiciones veamos el origen del bug con un poco de historia…

El origen de este término es tan viejo como la programación misma, e incluso hay
quienes afirman que el término “bug” se utilizaba en la “era pre-ordenador”, cuando
alguna polilla atascaba los delicados mecanismos de alguna máquina.
En la informática, en Harvard (1.947) los científicos que se encargaban de la
supercomputadora Mark II vieron que algo no iba bien, Después de revisar la máquina
vieron que la fuente del problema era una polilla que se había colado en el interior y había
causado el mal funcionamiento, Grace Murray Hopper (una licenciada en física y
destacada matemática), que trabajaba programando fue quien hizo el reporte, lo pegó con
cinta adhesiva en la bitácora con la siguiente entrada:
“First actual case of bug being found”, en español “Primer caso real de bug

encontrado”

¿Qué es un bug?

En informática un bug se define como un fallo o un defecto detectado en el software, el

cual fue originado por un error que se genera en el diseño y desarrollo del software, esto
da como respuesta resultados no esperados.

El significado de “Bug” en inglés es “insecto” en términos informáticos esto es

definido como una falla detectada en el software.

Un bug se puede definir como una falla no esperada en el software, pero también se
puede denominar como aquellas características que no satisfacen las necesidades según
las definiciones del usuario

¿Cuál es la diferencia entre error, defecto y fallo?

Error
Un error es una acción humana que produce un resultado, puede ser originada por el
desarrollador, por ejemplo en el código o en la lógica de programación, este error
puede originar más de un defecto en el sistema

Defecto
Es la presencia del error en el software, esta imperfección ocasiona resultados
no esperados

Fallo
Es la manifestación física o funcional de un defecto, es decir es detectado durante
la ejecución de pruebas, por ejemplo: al colocar los datos de
Login(usuario/contraseña) correctos el sistema no permite iniciar sesión

“Un Error de un desarrollador, causa un Defecto en el software, lo

cual provoca un Fallo en el momento en el que la prueba se ejecuta.”
Estructura de un bug
Cuando se detecta un bug, este debe ser reportado al equipo de desarrollo para su
solución, para esto es importante tener en cuenta algunos puntos que deben incluir en
este reporte:

Entorno
Se debe indicar en el reporte, en qué ambiente se realizaron las pruebas, como por
ejemplo el ambiente de pruebas del analista QA, credenciales o perfil utilizado (si aplica)

Pasos
Esta es una parte importante donde se debe indicar el paso a paso a seguir para reproducir
el bug detectado por ejemplo: Paso 1 ingresar al link , Paso 2 Ingresar usuario y
contraseña, Paso 3 Dar clic en botón Login

Descripción
Es una descripción detallada de los pasos descritos anteriormente para guiar
al desarrollador a la reproducción del bug

Criterios de aceptación
Es una descripción de los resultados esperados definidos en la historia de usuario. Por
ejemplo: al colocar usuario y contraseña, y dar clic en el botón de Login el sistema
debe permitir iniciar sesión

Evidencia
En esta sección se colocan las evidencias que respaldan la detección del bug, por
ejemplo, unas imágenes las cuales deben tener buena definición y ser explícitas, o un
video donde se graba el proceso donde se detectó el bug

Prioridad de bugs

Al momento de reportar un bug es importante definir cuál es la prioridad del bug, de esta
forma el equipo de desarrollo podrá definir cuáles son los bugs que deben ser atendidos
de forma inmediata y cuáles pueden ser atendidos luego de resolver los más críticos

La gravedad de un bug nos permite definir cual es el impacto que este tiene sobre
el funcionamiento de un sistema
Los tipos de prioridades que se pueden ver en un
bug son:
Medium(medio) High (Alta) Highest (Más alta) Low(Baja)

Medium(medio)
Son bugs que se presentan en el sistema donde se obtienen resultados incorrectos,
como mensajes que no deben mostrarse por ejemplo, pero estos errores no detienen el
flujo de trabajo

High (Alta)
Los bugs que se colocan en esta categoría son aquellos que afectan la funcionalidad en
el flujo de ejecución de casos de prueba, donde afecta flujos principales del sistema

Highest (Más alta)

Son bug críticos que detienen o bloquean flujos del sistema y no permite realizar todo
un ciclo de pruebas afectando la verificación de las funcionalidades del sistema

Low(Baja)
Estos bugs son de bajo impacto, se consideran que afectan poco o nada la
funcionalidad del sistema como por ejemplo errores ortográficos o estéticos.

Ciclo de vida de un bug

El ciclo de vida de un bug se puede definir como las distintas etapas por las que puede
pasar un bug, es un periodo donde pasará por distintos estados durante todo su ciclo de
vida, este ciclo inicia cuando el tester detecta el bug y finaliza cuando el tester procede
a cerrarlo. Para esto vamos a conocer las distintas etapas por las que pasa un bug

Etapas de ciclo de vida de un bug

Nuevo—--- En análisis—-- En curso—-- Por probar—--- Devuelto
—--Resuelto —-Completado—--- Reabierto —------Rechazado
—-----Bloqueado

Nuevo
Este es el estado inicial del bug cuando es detectado y creado por primera vez

En análisis
Luego de que el bug es detectado y reportado, el bug pasa a estar en análisis por el
equipo de desarrollo

En curso
Este estado se puede visualizar cuando el bug fue asignado a un desarrollador y
está trabajando en la solución
Por probar
Cuando el desarrollador obtiene la solución del bug, esta solución está lista para probar en
el ambiente de pruebas y el tester debe hacer las pruebas y verificar si el bug realmente
fue resuelto o no.
Devuelto
Este estado del bug se aplica cuando pasan la solución del bug al ambiente de pruebas y
el tester al realizar el flujo de pruebas detecta que no fue solucionado, procede a devolverlo
al desarrollador para que vuelva a ser verificado y solucionado

Resuelto
Este estado aplica cuando se pasa la solución del bug al ambiente de pruebas y el
tester realiza el flujo de pruebas y verifica que fue resuelto

Completado
Luego de que un bug es resuelto se colocan las evidencias y se procede a cerrar el
bug donde se indica que fue corregido

Reabierto
Este estado en particular se puede presentar cuando un bug finalizó todo su ciclo y fue
cerrado, pero surge un factor imprevisto y este se presenta nuevamente por lo que se
debe reabrir nuevamente el bug

Rechazado
Este escenario se presenta cuando el bug luego de ser analizado por el equipo de
desarrollo no es considerado un error, para esto se deben presentar las evidencias
donde se justifique que no aplica como bug

Bloqueado
Este estado es colocado por el desarrollador cuando algún factor le impide poder dar
solución al bug y se encuentra a la espera de este desbloqueo para seguir con la
solución del bug

TEORÍA DE BUGS Y REPORTES DE JIRA

Definición de bug
● Error: Acción humana que produce un resultado incorrecto.
● Defecto: Presencia de un error en el software.
● Fallo: Manifestación física o funcional de un defecto.

Cómo reportar un bug en JIRA

1. Verificar exista el bug.
2. Ingresar al JIRA
3. Dar clic en CREAR
4. Consejos para reportar el bug en JIRA
4.1. El tipo de incidencia va a ser siempre ERROR
4.2. El campo RESUMEN es el título del bug, debe ser corto, entendible. Ya que
el desarrollador lo va a enlazar al Bitbucket.
4.3. Descripción del bug
Entorno: aquí se coloca la url en la que se ejecutó, ambiente, etc.
Usuario y perfil con que se ejecutó la prueba: Puede ser usuario administrador,
Backoffice, ventas etc.
Pasos: la N cantidad de pasos pasos para reproducir el bug.
Descripción detallada: Explicación detallada de la detección del bug.
Resultado Obtenido: El error específico del bug.
Resultado Esperado: Resultados esperados basados en la definición de HU. Evidencia: se
coloca la evidencia, en una captura de pantalla o un video del bug detectado 4.4.
Seleccionar Incidencia, las historias que se ven afectadas por el bug que voy a levantar.
4.5. Responsable, se le asigna al funcional o scrum.
4.6. Epic link.
4.7. Sprint
5. Por último darle clic en el botón CREAR
Cómo enlazar mi bug creado con test
link
1. Ingresar al test link
1. Ir al caso de prueba que deseamos vincular al bug recién creado.
2.1. El emoticon de carita triste me sirve para desaprobar un caso de

prueba.

Testeo de APIS con postman

Interfaz
Es una capa de abstracción para que dos sistemas se comuniquen.
una capa de abstracción permite que interactúas con un sistema sin necesidad de
saber qué está pasando por debajo

ej: volante de un vehículo, derecha va hacia la derecha, pero no tenemos ni idea de

la mecánica interna

API
Es una interfaz para que se comuniquen aplicaciones, programas de software y
compartan datos entre ellos ( en ingles application programming interface ).
Son un conjunto de comandos, funciones y protocolos que permiten la comunicación
entre software

Servicio web ( web services )

Conjunto de estándares y protocolos para intercambiar datos entre aplicaciones a travez
de internet, osea de http

Formatos ( json, XML, texto plano )

JSON
Hoy en dia es el lenguaje mas usado para transferir información, significa javascript
object notation.
Es muy facil de entender y manipular
Esta construido por una colección de pares de nombre y valor
REST
Rest es un tipo de arquitectua de desarrollo web que se apoya totalmente en el
estandar HTTP
Significa Representational State Tranfesr
Es el enfoque mas popular para la creación de API
Se basa en una relación cliente-servidor que
separa las partes frontal y posterior de la API

Métodos HTTP
Una de las cosas que especifica el protocolo HTTP son los verbos ( métodos ),
estos indican acciones.

Get: leer, traer información desde un servidor, cualquier dato que necesitemos una lista o
un recurso en específico
Post: crear, para enviar información hacia el servidor, es especifico para la creación
de recursos
Put: modificar, para actualizar todo un recurso ( por completo )
PATCH: modificar, se usa para actualizar solo una parte del recurso
DELETE: eliminar un recurso determinado ( rara vez se utiliza )

Códigos de estado
Cuando se solicita información a través de una API, el servidor puede contestar con
distintos códigos. Con estos vas a saber que paso con tu petición.
Los estados sirven para describir el estado de la petición

código 200: cuando las respuesta son exitosas ( get )

200 OK. Respuesta estándar para peticiones correctas
201 Created. La petición ha sido completada y ha resultado en la creación de
un nuevo recurso ( post )
Código 300: cuando hay que tomar acciones adicionales para completar la solicitud. Por
lo general indican redirección. ( problema de segridad de cache )

Código 400: cuando son errores del cliente, Indica que se hizo mal una solicitud,
faltan datos, headers o cualquier otro error
-400 Bad request. La solicitud contiene sintaxis erronea
-403 Forbidden. La solicitud fue legal, pero en el servidor rehusa a responder dado que
el cliente no tiene los privilegios para hacerla
-404 Not Found. Recurso no encontrado. Se utiliza cuando en el servidor web no
se encuentra la página o recurso solicitado.

Código 500: cuando existen problemas con el servidor. Indica que fallo completamente
la ejecución. No necesariamente tenemos control sobre ellos.
-500 Internal Server Error. Comunmente emitido por aplicaciones empotradas en servidores
web, cuando se encuentran con situaciones de error ajenas a la naturaleza del servidor
web

¿Qué son las APIs y para qué sirven? https://youtu.be/u2Ms34GE14U

¿Qué es una API REST?

https://tech.tribalyte.eu/blog-que-es-una-api-rest

API testing: guía práctica para iniciarse:

https://cl.abstracta.us/blog/api-testing-guia-practica/

¿Cuáles son los tipos y las diferencias de APIs?

https://revistaitnow.com/cuales-son-los-tipos-y-las-diferencias-de-apis/

API REST. En qué se diferencia de otros tipos

https://appmaster.io/es/blog/que-es-la-api-rest-y-en-que-se-diferencia-de-otros-tipos

Probar API con Postman:

https://underc0de.org/foro/qa-(quality-assurance)/testeo-de-apis-con-postman/msg146191/
# msg146191

¿Qué es postman?
herramienta que principalmente se utiliza para probar api de tipo rest

Postman es una herramienta muy completa que además de probar, documentar y

ayudar incluso en el proceso de desarrollo de APIs, sirve para automatizar: se pueden
agregar scripts de prueba en JS

Su interfaz de usuario es mucho más amigable e intuitiva, dispone de colecciones y

agrupaciones de peticiones, lo que la hacen más simple de entender, incluso para
aquellos que estan recien comenzando
Menues

Home: veo informacion sobre mi usuario como el historial de mis actividades o espacio
de trabajo

Workspaces: es el espacio de trabajo donde voy a crear mis colecciones y peticiones

API Network: lugar central tanto para consumidores como productores de API
para descubrir explorar y compartir

Reports: es un menú pago

Explore: menú explorador de API de terceros

Para conocer mas sobre los menues opciones:

https://learning.postman.com/docs/getting-started/navigating-postman/

¿Dónde trabajo?
Vamos a trabajar en workspace, de espacio privado
1. Voy a la opción de menú Workspace -> Botón create workspace 2. Se despliega
la ventana de workspace, ingreso el nombre que desee, el detalle o descripción de
mi espacio de trabajo, la visibilidad y presiono el botón create workspace

¿Que es una colección?

Son carpetas donde se almacenan las peticiones y que permiten ser estructuradas
por recursos, módulos o como el equipo lo desee.

¿Cómo crear una colección?

En mi workspace hago click en el botón new en donde se despliegan varias opciones
y hago click en colecction

Importar una colección

Para este ejemplo vamos a trabajar con la misma API: https//:petstore.swagger.io/
Testeo de APIS con POSTMAN 2

Usando variables

Variables
Una variable es una representación simbólica de datos que me permite acceder a un
valor sin tener que ingresarlo manualmente donde lo necesite.

Esto puede ser útil si estamos utilizando los mismos valores en varios lugares.

Por ejemplo, si tenemos la misma URL en más de una solicitud, pero la URL puede
cambiar más tarde, podemos almacenar la URL en una variable base_url y hacer referencia
a ella en las solicitudes mediante {{base_url}}.

Si la URL cambia, podemos cambiar el valor de la variable y se reflejará en toda

la colección, donde sea que hayamos usado el nombre de la variable.

El mismo principio se aplica a cualquier parte de una solicitud donde se repiten los datos.

Las variables en Postman son pares clave-valor. Cada nombre de variable representa
su clave, por lo que hacer referencia al nombre de la variable le permite acceder a su
valor.

Ámbitos de las variables (scope)

Admite variables en diferentes ámbitos, lo que le permite adaptar su procesamiento a
una variedad de tareas de desarrollo, prueba y colaboración.
En orden del más amplio al más limitado, estos ámbitos son: global ,
collection, environment, data y local .

Variable Global

Están disponibles en todo el espacio de trabajo (workspace)

Permiten acceder a datos entre colecciones, solicitudes, scripts de prueba y entornos.

Variable de Colección
Están disponibles en todas las solicitudes de una colección y son independientes de
los entornos.
Son adecuadas si está utilizando un solo entorno, por ejemplo, para detalles de URL
o autenticación

Variable de entorno
Permiten encuadrar nuestro trabajo en diferentes entornos, por ejemplo, desarrollo
local frente a pruebas o producción.
Gestión de Entornos

Entornos(Environments)
Un entorno es un conjunto de variables que podemos usar en las solicitudes de Postman.
Podemos usarlos para agrupar conjuntos de valores relacionados y administrar el acceso
a los datos compartidos de Postman si trabajamos como parte de un equipo.

Probar una API con la heurística POISED

Es una estrategia para probar una API.

Se puede utilizar como checklist al momento de diseñar los casos de prueba. Es
especialmente útil cuando surge la pregunta “¿estamos cubriendo todos los
aspectos importantes de la API?”
Con POISED se cubren varios aspectos:
1-Parameters (Parámetros): considerar todos los parámetros pasados a la API.
2-Output (Salidas): validar las salidas adecuadas para parámetros válidos e inválidos.
3-Interoperability (Interoperabilidad): verificar la coherencia con otras API. 4-Security
(Seguridad): verificar el mantenimiento del acceso y la autorización para las llamadas
a la API.
5-Exceptions (Excepciones): verificar que se informen los errores de forma clara y
precisa. 6-Data (Datos): verificar que se manejan las estructuras de datos y los datos
reales correctamente y en el tiempo adecuado.

Ejemplo: considerar una operación POST simple sobre determinado endpoint que se
encargaría de crear una persona o usuario en la base de datos, a partir de los
valores enviados en el body del mensaje con datos básicos de una persona o usuario
de un sistema:

1- Parámetros
4- Seguridad

Identificar cómo trata la API las credenciales activas, caducadas y no válidas.

Aplicar vulnerabilidades potenciales, como pasar parámetros que en realidad son

scripts entre sitios, y observar los resultados.

Por ejemplo, esto puede incluir autenticación o aspectos de seguridad en los parámetros.
Conclusión POISED
La heurística podría llegar a servir de alguna manera para estandarizar dentro de un
equipo de varios testers la forma de probar una API, manteniendo una estructura y
enfoque. Da un
modelo de referencia para tener en cuenta al pensar la cobertura que nos interesa
alcanzar al probar una API.
Existen otras formas también interesantes de probar una API (incluso otras heurísticas,
por ejemplo la heurística VADER).

Testing con SWAGGER

¿Qué es una API?

El término API es una abreviatura de Application Programming Interfaces, que en español

significa interfaz de programación de aplicaciones. Se trata de un conjunto de definiciones
y protocolos que se utiliza para desarrollar e integrar el software de las
aplicaciones, permitiendo la comunicación entre dos aplicaciones de software a través de
un conjunto de reglas

¿Para qué sirve una API?

Establece cómo un módulo de un software se comunica o interactúa con otro para

cumplir una o muchas funciones.
● Poder facilitar el trabajo a los desarrolladores y ahorrar tiempo y dinero. ● Pueden ser
privadas para el uso de una empresa, abiertas sólo para partners, o públicas para que
cualquier desarrollador interactúe con ellas o crear sus propias API para que lo hagan.
También pueden ser API locales para aplicaciones que se comunican dentro de un mismo
ambiente o dispositivo, o remotas para cuando hay que acceder a otro punto diferente

Endpoints & métodos

Endpoints
Los EndPoint son las URLs de una API y cada EndPoint puede tener varios métodos.

Métodos
Los métodos son todas las formas que tenemos de poder interactuar con ese EndPoint

POST: crear un recurso nuevo.

PUT: modificar un recurso existente.
GET: consultar información de un recurso.
DELETE: eliminar un recurso determinado.
PATCH: modificar solamente un atributo de un recurso.

Ejemplo: Supongamos que tenemos una tienda e-commerce integrada con una API de
productos. Con el método POST, podemos crear un nuevo producto. Con el método PUT
podemos modificar un producto de la tienda, con el GET podemos traer todos los
productos o un producto en específico, con el DELETE podemos eliminar el producto y con
el PATCH podemos modificar un atributo de un producto.

¿Qué pasa cuando dos personas no hablan un mismo idioma?

Las APIs no comparten un idioma común en demasiadas ocasiones, no cuentan con un
estándar de diseño común y ni siquiera existen unos parámetros comunes para
documentarlas. Es decir, no sólo no hablan el mismo idioma, sino que no hay un
diccionario que nos ayude a descifrarlas.

Swagger
Su objetivo es estandarizar el vocabulario que utilizan las APIs. Es el diccionario API.

Cuando mencionamos a Swagger, nos referimos a una serie de reglas, especificaciones

y herramientas que nos ayudan a documentar nuestras APIs, documentación que todo el
mundo pueda entender.
Existen varias plataformas que hacen esto mismo, pero la más conocida es Swagger,
tiene una buena interfaz de usuario que se llama Swagger UI, que permite no solo ver los
endpoint y métodos, sino que también permite probarlos.

Testing con Swagger

Estrategia P.O.I.S.E.D.( Parameters Outputs Interoperability Security Errors Data )

Códigos HTTP más comunes

200: Respuesta exitosa
400: Bad Request
401: Unauthorized
404: Not Found
500: Internal server error

Jmeter
Pruebas de stress y performance WEB
Los Testing de performance permiten conocer el desempeño de alguna aplicación. JMeter
es uno de los programas más usados a la hora de hacer un testing de stress y
performance, ya que es muy eficiente a la hora de dar resultados.

JMeter se puede usar para aplicaciones que manejen estos

protocolos: Web – HTTP, HTTPS
SOAP
Database via JDBC
LDAP (Lightweight Directory Access Protocol)
JMS (Java Message Service)Mail – POP3
Cabe aclarar que Jmeter funciona en todos los navegadores (en pruebas no manuales

) ¿Qué es Apache Jmeter?

La aplicación Apache JMeter™ es un software de código abierto, una aplicación Java 100
% pura diseñada para cargar, probar el comportamiento funcional y medir el rendimiento.
Originalmente fue diseñado para probar aplicaciones web, pero desde entonces se ha
expandido a otras funciones de prueba.

JMeter se puede usar para probar el rendimiento tanto en recursos estáticos

como dinámicos, aplicaciones dinámicas web.
Se puede usar para simular una carga pesada en un servidor, grupo de servidores, red u
objeto para probar su fuerza o para analizar el rendimiento general bajo diferentes tipos
de carga

Tipos de pruebas de performance

Carga – Load test
Con esta prueba, la empresa puede conocer la cantidad de usuarios que soporta su
producto en un lapso de tiempo determinado, según los usuarios que espera tener el
cliente en su sistema sin forzarlo a una capacidad mayor a la esperada.

Por ejemplo: Se necesita probar un puente para saber su comportamiento con 100
personas sobre él (el dato de la cantidad es determinado por el cliente), los arquitectos de
pruebas lo que hacen es dividir este grupo total en grupos más pequeños que vayan
ingresando al puente de manera paulatina en un lapso de tiempo (5 personas inician, al
minutos ingresan otras 5 y así sucesivamente hasta completar las 100 personas) y con
una actividad específica como “saltar” , lo que al final permite evaluar el comportamiento
del puente y si su estructura y estado final tuvieron el comportamiento saludable para
soportar esta actividad

Capacidad – Capacity Test

El objetivo de las pruebas de capacidad es evaluar el punto de quiebre de la aplicación, es
determinar la carga máxima de usuarios que puede soportar la aplicación (escalabilidad).
Tomando nuevamente el ejemplo de la analogía del puente se agregaría más personas por
intervalo de tiempo superando las 100 personas que inicialmente esperábamos que
soportara el puente, ejemplo 150 personas en total, siempre haciendo pausas entre cada
grupo que se suman a las que ya están saltando en el puente, llegando hasta el punto
puente colapse o se vea seriamente afectado, de esta manera nos daríamos cuenta de que
capacidad tiene el sistema para atender usuarios de manera concurrente

Estrés – Stress Test

Acá colocamos a prueba la robustez y la confiabilidad del software probado, sometiéndolo
a condiciones de uso extremas. Entre estas condiciones se incluyen el envío excesivo de
peticiones y la ejecución en condiciones de hardware limitadas. El objetivo es saturar el
programa hasta un punto de quiebre donde aparezcan bugs (defectos) potencialmente
peligrosos y verificar si los mismos pueden recuperar sus recursos físicos de forma
autónoma sin requerir la intervención humana.

Por ejemplo: Continuando con el ejemplo de personas saltando sobre el puente, en esta
prueba colocamos a las mismas 150 personas de participaron en la prueba de capacidad,
pero sin pausa entre salto y salto, con el objetivo de evidenciar si el puente puede
recuperar su forma después de alterar su estructura durante la prueba.
Algunas cosas a tener en cuenta al momento de probar stress
– Estas pruebas NO deben realizarse nunca en producción
– Se debe ejecutar esta prueba en el flujo más pesado de la aplicación. En este caso
apunté al inicio del foro, pero quizás lo correcto hubiese sido apuntar a una petición POST
a la hora de crear un post, ya que debe ir y almacenar las cosas en la base de datos.
– Estas pruebas se realizan en un ambiente espejo de producción. Es decir, no se deben
hacer ni en producción, ni en un servidor de QA o Desarrollo. Debe ser otro ambiente que
tenga las mismas características que la producción. De lo contrario, los datos que
obtendremos no serán datos de escenarios que pasarán en producción.
- Al momento de hacer esta prueba, nadie debería estar conectado en ese
ambiente para no afectar los resultados de las pruebas