Cuando testeas a través de la UI, estás testeando la API de forma indirecta: la UI llama a la API en tu nombre, ocultando modos de fallo que solo existen en la capa HTTP. Testear la API directamente significa enviar solicitudes HTTP sin un navegador, lo que expone qué pasa con campos obligatorios faltantes, tokens de autenticación inválidos, o IDs que no existen. Este artículo cubre la base completa: estructura de solicitudes y respuestas HTTP, qué verificar en cada respuesta, patrones de autenticación, y cómo escribir tests de API en Playwright.

Qué es una API desde la perspectiva del testing

Puedes pensar en una API como un contrato. Un sistema dice: "Envíame una solicitud con esta forma y te daré una respuesta con esa otra forma." Tu trabajo como ingeniero QA es verificar que el contrato se cumple: que el sistema entrega lo que promete, rechaza lo que debería rechazar, y falla de forma controlada cuando algo sale mal.

En la práctica, la mayoría de las APIs que vas a testear son APIs REST que se comunican a través de HTTP. Una app de reservas de viajes tiene un endpoint que crea una reserva. Un sistema de gestión de usuarios tiene un endpoint que devuelve una lista de usuarios. Una plataforma de e-commerce tiene endpoints para agregar al carrito, verificar el inventario y procesar pagos.

Cuando testeas a través de la UI, estás testeando la API de forma indirecta: la UI llama a la API en tu nombre. Cuando testeas la API directamente, eliminas la UI de la ecuación por completo. Eso significa tests más rápidos, mensajes de fallo más claros, y la capacidad de testear escenarios que la UI no expone: ¿qué pasa si alguien envía un precio negativo, un campo obligatorio vacío, o una solicitud sin autenticación?

Fundamentos de HTTP para testers

Cada interacción con una API es una solicitud HTTP seguida de una respuesta HTTP. Esto es lo que contiene cada parte.

Una solicitud tiene cuatro partes: el método, la URL, los headers y un body opcional.

El método le dice al servidor qué operación quieres realizar. Los cuatro que vas a usar constantemente son GET (recuperar datos), POST (crear algo nuevo), PUT o PATCH (actualizar algo) y DELETE (eliminar algo). Enviar un GET a /api/users devuelve una lista de usuarios. Enviar un POST a /api/users con datos de usuario en el body crea un nuevo usuario.

La URL es la dirección del recurso. Suele tener una base como https://api.example.com, una ruta como /users/42, y a veces parámetros de consulta como ?status=active&page=2.

Los headers llevan metadatos: el tipo de contenido del body (Content-Type: application/json), credenciales de autenticación (Authorization: Bearer eyJ...), e instrucciones al servidor sobre qué formato acepta el cliente (Accept: application/json).

El body contiene los datos que estás enviando, típicamente en JSON para las APIs REST modernas.

Una respuesta refleja esta estructura. Tiene un código de estado, headers y un body. El código de estado es la parte más importante para el testing:

  • 200 OK: la solicitud tuvo éxito, aquí está lo que pediste
  • 201 Created: algo se creó exitosamente
  • 400 Bad Request: tu solicitud estaba mal formada o le faltaban campos obligatorios
  • 401 Unauthorized: no estás autenticado
  • 403 Forbidden: estás autenticado pero no tienes permiso para hacer esto
  • 404 Not Found: ese recurso no existe
  • 422 Unprocessable Entity: la solicitud estaba bien formada pero era semánticamente inválida
  • 500 Internal Server Error: el servidor falló
La diferencia entre 401 y 403 confunde a muchos testers. 401 significa "No sé quién eres, por favor autentícate." 403 significa "Sé exactamente quién eres, y no tienes permiso para hacer esto." Siempre verifica cuál devuelve la API para cada escenario.

Qué testear en una API

El instinto es testear solo el camino feliz: enviar datos válidos, recibir un 200, listo. Ese enfoque detecta tal vez el 20% de los bugs. Acá hay un marco más completo.

Los caminos felices verifican que la API hace lo que se supone que debe hacer cuando se usa correctamente. Un POST para crear un usuario con datos válidos debería devolver 201 y el objeto de usuario creado. Un GET con el ID de ese usuario debería devolver 200 y los mismos datos. Los casos de error son donde las APIs están más frecuentemente rotas. ¿Qué pasa cuando falta un campo obligatorio? ¿Cuando el ID en la URL no existe? ¿Cuando el usuario no está autenticado? Cada uno de estos debería devolver un código de estado específico y un mensaje de error significativo. Testea que lo hagan. Los casos extremos sondean los límites de lo que acepta la API. ¿Qué pasa con una cadena vacía donde se espera texto? ¿Un cero o número negativo para una cantidad? ¿Una cadena exactamente un carácter más larga que el máximo permitido? ¿Una fecha en el pasado para un endpoint de "solo eventos futuros"? Los fundamentos de seguridad pertenecen a toda suite de tests de API, incluso a nivel principiante. ¿Podés acceder a los datos de otro usuario adivinando su ID? ¿La API acepta solicitudes sin autenticación? ¿Devuelve más datos en la respuesta de los que el cliente debería ver (over-fetching)? Estas no son pruebas de penetración, solo verificaciones de sentido común.

Un modelo mental útil: para cada endpoint, hazte tres preguntas. ¿Qué debería funcionar? ¿Qué debería fallar? ¿Cómo debería verse el error cuando falla?

Herramientas: Postman, Playwright y curl

Tres herramientas cubren la mayor parte de lo que necesitas.

curl es la forma más rápida de hacer una solicitud HTTP puntual desde la terminal. No necesitas instalar nada; ya está en la máquina de cada desarrollador. Úsalo para verificaciones rápidas durante la exploración: 

# Solicitud GET
curl https://lab.becomeqa.com/api/items

# POST con body JSON
curl -X POST https://lab.becomeqa.com/api/items \
  -H "Content-Type: application/json" \
  -d '{"destination": "Tokio", "status": "planned"}'

# Con header de Authorization
curl https://lab.becomeqa.com/api/items \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..."

Postman es tu herramienta de exploración. Úsalo cuando trabajas con una API por primera vez: testeando endpoints manualmente, inspeccionando respuestas, descubriendo qué parámetros son obligatorios. El collection runner de Postman puede ejecutar una secuencia de solicitudes y sirve como borrador antes de escribir tests automatizados reales. Piénsalo como un REPL para APIs. Playwright es tu herramienta de automatización. Tiene un cliente HTTP integrado que te permite escribir tests de API en el mismo framework que tus tests de UI. El fixture request funciona sin abrir un navegador, se ejecuta en milisegundos, y se integra con tus reportes de tests existentes: 

import { test, expect } from '@playwright/test';

test('POST /api/items crea un nuevo ítem', async ({ request }) => {
  const response = await request.post('https://lab.becomeqa.com/api/items', {
    data: {
      destination: 'Tokio',
      status: 'planned'
    }
  });

  expect(response.status()).toBe(201);

  const created = await response.json();
  expect(created).toHaveProperty('id');
  expect(created.destination).toBe('Tokio');
});

El flujo es: explora con Postman y curl, automatiza con Playwright.

Anatomía de un test de API REST

Un buen test de API verifica más que solo el código de estado. Esto es lo que verificar en cada respuesta.

El código de estado es la primera puerta. Verificalo antes de hacer cualquier otra aserción. Si el estado es incorrecto, todo lo demás es irrelevante.

La estructura del body de la respuesta importa. Si la API promete devolver un objeto de usuario con id, email y role, tu test debería verificar que los tres campos están presentes en cada respuesta. Esto detecta regresiones silenciosas donde alguien agrega un campo obligatorio al contrato del front-end pero se olvida de incluirlo en la respuesta de la API.

Los valores de los campos importan, no solo su existencia. Si creaste un usuario con email test@example.com, la respuesta debería reflejar exactamente ese email. Si la API devuelve un campo de estado, verificá que sea uno de los valores esperados, no solo cualquier cadena.

Los headers de la respuesta también llevan información. Verificá Content-Type: application/json si esperás JSON. Para endpoints que devuelven datos paginados, verificá los headers de paginación como X-Total-Count o los links en el body de la respuesta.

El tiempo de respuesta es una señal. Playwright no te da aserciones sobre el tiempo de respuesta de forma nativa, pero podés medirlo manualmente. Un endpoint que normalmente responde en 50ms devolviendo en 2000ms vale la pena marcarlo incluso si los datos son correctos.

Autenticación en tests de API

Casi toda API en producción requiere autenticación. Los dos patrones que vas a encontrar todos los días son API keys y tokens Bearer.

Las API keys son cadenas estáticas que identifican una aplicación cliente. Generalmente se envían como un header: 

curl https://api.example.com/data \
  -H "X-API-Key: tu-api-key-aqui"

En tus tests automatizados, nunca escribas la clave directamente en el código. Almacenala en una variable de entorno y leela desde ahí. Esto mantiene los secretos fuera de tu código de tests y facilita cambiar entre credenciales de staging y producción.

Los tokens Bearer son dinámicos. Expiran, y normalmente obtenés uno llamando primero a un endpoint de login. El patrón en tus tests es siempre el mismo: llamar al endpoint de autenticación, extraer el token, pasarlo en el header Authorization de las solicitudes siguientes.
Siempre testea los caminos de autenticación fallidos de forma explícita. ¿Qué devuelve la API cuando no envías token? ¿Un token expirado? ¿Un token emitido para otro usuario? Estos deberían devolver 401, no 500, y definitivamente no 200 con los datos de otra persona. Una respuesta 200 en una solicitud sin autenticación es un bug de seguridad.

Testear los casos extremos relacionados con autenticación (tokens inválidos, tokens faltantes, tokens con permisos incorrectos) es uno de los testings de API de mayor valor que podés hacer. Las consecuencias de que la autenticación falle son graves, y estos bugs frecuentemente viven en la API, no en la UI donde los tests de UI los detectarían.

Dónde encaja el testing de API en la pirámide de tests

La pirámide de tests es un modelo para distribuir tus tests. En la base: muchos tests unitarios, rápidos y baratos, que testean funciones individuales. En el medio: tests de integración y de API, que testean cómo se comunican los sistemas entre sí. En la cima: pocos tests de UI, que testean journeys completos del usuario.

Los tests de API están en el punto óptimo. Son significativamente más rápidos que los tests de UI. Un test de API típico corre en 50 a 200 milisegundos versus 3 a 10 segundos para un test de UI. Son más estables porque no se rompen cuando cambia la etiqueta de un botón o se mueve un selector CSS. Y testean la capa donde realmente viven la mayoría de los bugs de backend.

Una distribución práctica para una aplicación web típica: por cada 1 test de UI que cubre un flujo de usuario, escribe 3 a 5 tests de API que cubran los endpoints subyacentes. El test de UI verifica que las piezas se conectan correctamente. Los tests de API verifican que cada pieza funciona correctamente por sí sola.

Esto importa especialmente para la lógica de negocio. Si una app de e-commerce calcula descuentos en el backend, testea ese cálculo vía la API, no llenando un formulario de checkout en un navegador. El test de API será diez veces más rápido y testeará cada caso extremo (cero ítems, códigos de cupón expirados, descuentos apilados) sin ninguna de la fragilidad de la UI.

Cómo aplicar esto el lunes a la mañana

No necesitas refactorizar toda tu suite de tests. Así puedes empezar pequeño esta semana.

Elige una funcionalidad que tenga tests de UI pero no tests de API. Mira el tráfico de red en Chrome DevTools mientras usas esa funcionalidad. Vas a ver las llamadas que hace la UI a la API. Elige el endpoint más importante (generalmente el que crea o recupera los datos principales) y escribe un test de API para él en Postman primero.

Verifica el camino feliz. Luego escribe un test para un 404 (solicita un recurso con un ID inexistente). Luego escribe un test para un 400 (envía un POST con un campo obligatorio faltante). Tres tests que tardan 30 minutos en escribir, y estableciste el patrón.

Luego, pasa esos tres tests a Playwright para que se ejecuten en CI junto con tus tests existentes. Usa la estructura de código de los ejemplos de este artículo. Ejecútalos una vez para confirmar que pasan.

Desde ahí, expande la cobertura preguntándote: "¿Cuál es el siguiente endpoint más importante?" y "¿Qué casos de error tiene este endpoint que no estoy testeando?"

→ See also: API Testing con Playwright: Más Allá de la UI | ¿Qué es una API REST? Guía Práctica para Ingenieros QA | Códigos de Estado HTTP que Todo Ingeniero QA Debe Conocer | Postman para Ingenieros QA: Del Primer Request a la Suite de Tests API | Roadmap de Automatización QA 2026: Habilidades Esenciales para Conseguir Trabajo