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.

Mejores estrategias para pensar nuestros 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.

SOQL Fundamentos

Que es SOQL.
SOQL es el lenguaje de consulta de objetos de Salesforce. Puede usar SOQL para leer la
información almacenada en la base de datos de su organización. SOQL es similar desde el
punto de vista sintáctico a SQL (lenguaje de consulta estructurado).

Ventajas de utilizar SOQL

● No es necesario conectarse a un base de datos.
● El SOQL está integrado directamente al Salesforce.
● Sentencias fáciles de comprender.
● Si hay errores en la sentencia, son claros lo mensajes donde nos indican por qué está mal
la sentencia

Sentencias de SOQL

● Consulta simple SELECT campos a consultar FROM Objeto

Ejemplo: SELECT Id, Name FROM Account

● Consulta con WHERE

SELECT campos a consultar FROM Objeto WHERE el campo que quiero en específico.

Ejemplo: SELECT id, Name FROM Account WHERE Name = 'JORGE LUIS VEGA
SORIANO'

● Consultar dos objetos a la vez.

SELECT objeto.campo_objeto, objeto.campo_objeto FROM OBJETO

Ejemplo: SELECT [Link], [Link] FROM Contact

● Me trae todos los campos de un objeto

SELECT FIELDS(STANDARD) FROM objeto

Ejemplo: SELECT FIELDS(STANDARD) FROM Contact

● Uso del NULL Ejemplo: SELECT Id, Name FROM account WHERE Apellido_Materno__c
= null
● El uso del LIKE Ejemplo: SELECT Name FROM Account WHERE Name LIKE 'A%'
● Expresiones de tiempo

SELECT Name, Birthdate FROM Contact WHERE Birthdate = THIS_MONTH

LAST_MONTH= Mes pasado

THIS_MONTH= Este mes
LAST_90_DAYS= días atrás
NEXT_90_DAYS = Próximos días
THIS_WEEK= Esta semana
NEXT_WEEK= Próxima semana
LAST_WEEK= Semana pasada
YESTERDAY= Ayer
TODAY= Hoy

También podemos escribir fecha el formato sería el siguiente = 2022-03-16 o

2011-04-26T10:00:00-08:00

SELECT name FROM Account WHERE CALENDAR_YEAR(CreatedDate) = 2022

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? [Link]

¿Qué es una API REST?: [Link]

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

[Link]

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

[Link]

API REST. En qué se diferencia de otros tipos

[Link]

Probar API con Postman:

[Link]
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:

[Link]

¿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//:[Link]/
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 de APIS 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