DEV Community: Alfred Tejeda

Segunda parte: Definiciones/Conceptos del día a día

Alfred Tejeda — Wed, 26 Jun 2024 13:37:26 +0000

Como mencioné en la introducción, la idea al finalizar esta serie de publicaciones es tener las herramientas y el conocimiento para poder convertirnos expertos en API Testing, por tanto poder manejar y tener claridad de los conceptos es esencial. No vamos a crear un diccionario, ya que haría la publicación muy larga si buscamos definir todo, así que el enfoque va a ser definir lo que vamos a estar utilizando en nuestro día a día. Empecemos:

Contract o contrato
El contrato es básicamente la específicación de como se de debe hacer la petición y como va a responder este según la manera en la que se arma la petición. (Esencial para hacer contract testing)

cURL
La definición oficial: es una herramienta de línea de comandos, que permite transferir datos hacia o desde un servidor sin interacción del usuario.
En la actualidad es un estandar para compartir una petición que estamos realizando, ya sea desde el navegador o de alguna herramienta para diseño/prueba y prueba de APIs. Para entender mejor como se construye un cURL les recomiendo visitar Curl Builder

Endpoint
Los endpoints son en pocas palabras el medio con lo que accedemos o interactuamos con la API aunque es normal al momento de hablar de endpoint mencionar solo la path de este, ejemplo: si tenemos http://localhost/user/info , diríamos: El que falla es el user info , cada endpoint es la url + metodo + data disponible que utilizamos para hacer alguna acción sobre el servidor.

Header
Los headers tienen una definición un poco compleja y para entender esto al 100% debemos hablar de redes (y soy bastante ignorante en esta materia), voy a tratar de simplificar el concepto.
Debemos saber que podemos tener cabeceras de petición y de respuesta.
Ya con esto podemos decir que en las cabeceras de petición, lo utilizamos para proporcionar al servidor información adicional o complementaria del tipo de petición que estamos realizando.
La cabecera de petición más común es el Content-Type que lo utilizamos para indicar el formato de texto a utilizar en el payload (definido más abajo), esto se conforma por un par llave-valor por lo que la definición completa de esta cabecera sería Content-Type:application/json
Otra cabecera muy común es Authorization utilizada para agregar un token.
En la industria también se ha creado un estandar para utilizar cabeceras customizadas y estas tienden a iniciar con una letra equis (x) aunque no es obligario, ejemplo: X-Api-Key
Existen palabras reservadas o cabeceras pre-definidas y justo cuando una cabcera custom coincide con el nombre de una de las pre-definidas es cuando entra en juego el usar la X. Les comparto el listado completo de cabeceras por si quieren darle una mirada: List of all HTTP headers

Path param
Path param (parámetros de ruta) son básicamente variables de solicitud que se agregan a la url para indicar que queremos acceder a un recurso específico. No existe un posición específica en la que deba estar, aunque es muy común que al momento de crear la definición del endpoint se agregue al final de la ruta, ejemplo: /user/1234 , a nivel de código encontraremos algo así /user/:userId
Otro ejemplo que puedo mostrarles: /client/:clientId/department/:departmentId/employees

Payload o Request Body
En el contexto de APIs, payload o request body hace referencia a los datos que van a ser enviados en una petición. En esencia el conetenido de un mensaje que será enviado entre un cliente y un servidor. La mayoría de las APIs implementan JSON como formato pero hay que ser consciente que no es el único, también existen XML, Raw text y Plain text. (Desconozco si existen otros formatos. Si conocen algún otro lo pueden dejar en los comentarios y lo agrego y así habilitamos de alguna manera el modo colaborativo).

Query param
A diferencia de los parámetros de ruta, los parámetros de consultas son fáciles de identificar: se colocan al final de la url, viene después del signo de interrogación (?) y se utiliza bajo la premisa de llave-valor.
Estos parámetros tienen en defición una funcionalidad específica: filtrar la respuesta, un caso de uso común sería seleccionar los usuarios que solo estén con status pendiente, ejemplo: /users?status=pending
Se pueden utilizar cuanto parámetros sean necesarios para ser lo más específico en lo que deseamos obtener como respuesta, y para poder agregar más parámetros tan solo debemos agregar un ampersand(&), ejemplo: /users?status=pending&sort=desc

Dato extra: también existe matrix param aunque la utilización es casi nula, siempre suma el saber de su existencia.

Request
Bastante sencillo, es la petición en si. Podemos decir que al utilizar un cURL estamos creando una petición.
Para desglozar un poco, podemos decir que una request se compone por: un método, una url, cabeceras y payload

Response
Al igual que request, la definición es muy sencilla. Es la respuesta a una petición. Esta respuesta se compone por: cabeceras de respuesta, un código de estatus y un cuerpo de respuesta (si aplica)

Como describo en el título las deficiones presentadas son solamente aquellas que vamos a estar utilizando en el día a día, obviamente nos faltan muchas definiciones por lo que les comparto para búsqueda otras que son importantes de conocer:

API
Rest
API Rest
API Rest full
URI
Métodos o Verbos HTTP
HTTP
Signature (hmac)

Con esto hemos finalizado lo que podríamos llamar la introducción a APIs, en la siguiente publicación hablaremos sobre las buenas prácticas para construcción de una Api Rest que nosotros como probadores debemos conocer, ya que también es parte de nuestra labor poder participar en la definición de los endpoints.

Esta lista ha sido corta pero con saber esto ya tenemos medio camino cruzado.
¿Consideras qué hay alguna otra definición que debamos agregar? Comentala y actualizo!

Primera parte: Introducción API Rest

Alfred Tejeda — Thu, 06 Jun 2024 01:31:41 +0000

API Rest es tal vez la arquitectura de backend más utilizada en la industria y que parece ser atemporal. Aunque fue creada para resolver un problema, se usa para solucionar casi cualquier problema 😶.

Al ser (volvernos) probadores funcionales, el backend es algo que generalmente desconocemos ya que solo nos piden que nuestro foco esté en lo que ve el usuario, disminuyendo así las combinaciones o escenarios de pruebas posibles a ejecutar ya que algunas casuísticas requieren manipulación de datos a nivel de base de batos (y no tenemos acceso a ellas) o manipulación de las respuestas de los endpoints que son consumidos (ya que desconocemos la manera en como la información consultada es devuelta (retornada) al front).

Como mencioné al principio Rest API es muy utilizado, tan así; que podemos notar su presencia en casi todas las aplicaciones que usamos en nuestro día a día así como las que tenemos que probar (ya sean web, mobile, desktop, iot) por tanto conocer y sobre todo entender con que se come API marca una gran diferencia a la hora de asegurar la calidad de un producto digital.

Luego de esta mediana introducción, ahora si entremos en materia:

Qué es API Rest?
Sin entrar en tecnicismos (más adelante si profundizaremos en esto) y de manera muy simple, una API es básicamente un medio que permite crear, consultar, actualizar y/o eliminar información con el sistema que estamos interactuando (interno o externo) sin importar con que lenguaje de programación se encuentra construído.

Visualmente una API Rest es:

La imagen anterior, para mi; es la mejor representación visualmente hablando sobre qué es un API. Es aquel (aquello) al que le hacen una solicitud (orden) y luego que esta es preparada (solicitud procesada) se entrega la preparación al comensal (consumidor).

Para no saturar de información, este primer post de la serie es tan solo una introducción, en cada post iremos profundizando hasta tener todo lo necesario para volvernos expertos en API Testing!

Herramientas que todo tester debe conocer si desea realizar web testing

Alfred Tejeda — Tue, 16 Jan 2024 16:28:06 +0000

Aunque el web testing tiende a ser sencillo (abrir el navegador e ir a la url que vamos a probar) es recomendable contar con herramientas que nos ayuden a agilizar los tiempos de ejecución de pruebas o ejecutar otros escenarios que nos ayuden a ampliar el alcance y cobertura de las pruebas.

Charles proxy

Esta es la herramienta que para mí siempre va a estar en el top 1, Charles permite principalmente (y entre otras cosas) capturar las peticiones http/https (llamados a nuestra API o de terceros) que realiza la aplicación web e interceptar las mismas.
Gracias a esto podemos modificar tanto la petición como la respuesta ideal para realizar pruebas de nuestros casos negativos, por ejemplo si queremos validar si se muestra un toast cuando obtenemos un error 4XX como código de respuesta, o si la aplicación realiza reintentos (retry) al obtener como respuesta del servicio 5XX, esto sin la necesidad de tener que indisponibilizar los servicios.

Hay otras alternativas como ProxyMan y Fiddler.

Responsively App

Probar una web responsive es muy tedioso, tanto que puede llegar a ser complejo ya hay muchas resoluciones y tener que estar manipulando el navegador para ir viendo una a una hace que esto se vuelva más lento, por su puesto al igual que el mobile testing debemos tener armar una estrategia para no tener que probar todas.
Con Responsively podemos seleccionar multiples resoluciones (y agregar personalizada de ser necesario) y ver todas estas en tiempo real a medida que vamos interactuando.
Ideal para casos en lo que se deba de mostrar o no ciertos elementos según la resolución.

Jam Dev

Jam es un descubrimiento reciente para mí (antes usaba otras herramientas un poco más complicadas), más allá de ser una herramienta que permite hacer screenshots y videos (con voz si lo desean) también te muestra el "Developer tool", lo que permite que podamos explorar errores en console y network
de manera interactiva, en el caso de la pestaña Network podemos en caso de ser necesario copiar el cURL que es algo siempre vital de tener cuando probamos aplicaciones cuya responsabilidad de negocio se encuentra en el backend, además con las diferentes integraciones que tiene podemos enviar esto a través de slack o crear un bug en jira entre otros.

Esta es una lista corta y precisa pero con alto impacto si las usamos correctamente, en la actualidad cada vez que voy a iniciar mis activades de testing siempre tengo habilitado Charles y Jam (ya que por el momento no es responsive la web de mi trabajo actual). Esta es una "deadly combination" que ayuda a encontrar y reportar defectos de manera muy eficaz, rápida y con baja dependencia.

Cabe destacar que este listado también es una recomendación basada 100% en mi experiencia.

¿Quisieras conocer a detalle alguna de estas herramientas?
¿Conocees alguna alternativa?
Dejámelo saber en los comentarios.

También te invito a comentar que te ha parecido este tipo de publicaciones.

Me gusta enseñar lo que he aprendido durante estos 7 años de experiencia (al momento de escribir el post) por lo que me he propuesto a compartir con la comunidad de testing en español todo lo que pueda.
Si esta publicación ha sido de tu agrado puedes apoyarme compartiendo o agregando una reacción.

Si mi contenido te gusta y está a tu disposición puedes regalarme también un café