Cómo testear una API REST con Postman: guía para QA

Si llevas un tiempo mirando ofertas de QA en España, seguro que has visto esta combinación en más de un anuncio: "testing manual, Jira y nociones de Postman". La automatización de interfaz (Cypress, Playwright, Selenium) acapara toda la atención en los cursos, pero el testing de API es una habilidad que muchas ofertas piden y que casi nadie enseña bien.

La buena noticia es que probar una API REST con Postman es mucho más accesible de lo que parece. No hace falta saber programar para empezar, y los conceptos básicos se aprenden en una tarde.

En esta guía vas a ver cómo funciona una petición HTTP, cómo montar tu primera colección en Postman, cómo escribir comprobaciones automáticas (asserts) y cómo dar el salto a ejecutarlo todo desde la línea de comandos con Newman.

Por qué un QA debería testear la API, no solo la pantalla

Cuando pruebas solo la interfaz, estás probando dos cosas a la vez: la lógica de negocio y cómo se pinta en pantalla. Si algo falla, no siempre sabes si el problema está en el backend o en el frontend.

Probar la API directamente elimina esa ambigüedad. Le hablas al servidor sin pasar por la interfaz, así que si la respuesta es incorrecta, el problema está ahí, no en un botón mal maquetado.

• Es más rápido. Una petición a la API tarda milisegundos. Cargar una página entera para llegar al mismo punto puede tardar segundos.
• Es más estable. No depende de que un elemento cargue a tiempo en el DOM, así que no sufre la inestabilidad típica de los tests de interfaz.
• Llega antes a producción. El backend suele estar listo antes que la interfaz completa, así que puedes empezar a probar la lógica de negocio desde el primer día del sprint.
• Te hace más completo como QA. Combinar testing manual de interfaz con testing de API es justo el perfil que piden las ofertas de QA Automation Junior.

Anatomía de una petición HTTP: lo que hay que entender antes de abrir Postman

Antes de tocar Postman conviene tener claros cuatro conceptos: el método HTTP, la URL del endpoint, las cabeceras (headers) y el cuerpo (body) de la petición.

El servidor responde siempre con un código de estado (status code) que indica qué ha pasado. Aprenderte los rangos principales te ahorra horas de confusión:

Un fallo habitual en QA junior: dar por bueno un test solo porque la petición "no ha dado error". Un 200 con el cuerpo de la respuesta vacío o incorrecto también es un bug, aunque el código de estado esté bien.

Postman paso a paso: tu primera colección

Postman es gratuito para uso individual y no necesitas instalar nada más que la aplicación de escritorio o usar la versión web. Los tres conceptos que vas a usar todo el rato son la request (una petición individual), la collection (un grupo de peticiones relacionadas) y el environment (variables que cambian según dónde pruebes: local, staging o producción).

1. Crea una collection nueva y ponle el nombre del proyecto o la funcionalidad que vas a probar.
2. Dentro, crea tu primera request: elige el método (GET, POST...), pega la URL del endpoint y pulsa "Send".
3. Revisa la pestaña de respuesta: código de estado, tiempo de respuesta y el cuerpo (body) que ha devuelto el servidor.
4. Crea un environment con variables como base_url o token, y sustituye la URL fija por {{base_url}}/api/productos.

El paso del environment parece pequeño, pero es el que marca la diferencia entre una colección mantenible y una que hay que reescribir cada vez que cambias de entorno.

Verificar respuestas con asserts en la pestaña Tests

Enviar la petición y mirar la respuesta a ojo sirve para explorar, pero no escala. La pestaña "Tests" de Postman deja escribir comprobaciones automáticas en JavaScript que se ejecutan cada vez que lanzas la request.

// Comprueba que el status code es 200
pm.test("El status code es 200", function () {
    pm.response.to.have.status(200);
});

// Comprueba un valor concreto del cuerpo de respuesta
pm.test("El precio final es correcto", function () {
    const json = pm.response.json();
    pm.expect(json.precio_final).to.equal(18.99);
});

// Comprueba que la respuesta no tarda demasiado
pm.test("Responde en menos de 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

Con esto, cada vez que ejecutes la colección entera, Postman indica exactamente qué peticiones han fallado y por qué, sin que tengas que revisar cada respuesta a mano.

Automatizar la colección con Newman y meterla en el pipeline

Una vez que la colección tiene tests que funcionan, el siguiente paso natural es dejar de ejecutarla a mano. Newman es el ejecutor de línea de comandos de Postman: corre la misma colección desde la terminal y devuelve el resultado como cualquier otro test automatizado.

# Instalar Newman (una vez)
npm install -g newman

# Ejecutar una colección exportada
newman run coleccion.json --environment entorno.json

Newman es lo que hace posible meter la colección en un pipeline de integración continua: cada vez que se sube código nuevo, la suite de API se ejecuta sola y avisa si algo se ha roto, sin esperar a que un QA la lance manualmente. Es el mismo principio que hay detrás de la automatización de interfaz con Playwright o Cypress, aplicado a la capa de API.

Errores habituales al empezar a testear APIs

• Solo probar el camino feliz. Enviar siempre datos correctos y no comprobar qué pasa si falta un campo, el tipo es incorrecto o el valor está fuera de rango.
• Ignorar los códigos de error. No verificar que un 401 o un 404 devuelven realmente esos códigos cuando deberían, y no otro por error.
• No revisar los headers. Cabeceras como el tipo de contenido o el token de autenticación se dan por hechas y a veces esconden bugs reales.
• Depender de datos que pueden cambiar. Probar contra IDs o registros fijos que otro proceso puede borrar o modificar, rompiendo el test sin que haya ningún bug real detrás.

¿Merece la pena aprender esto viniendo del testing manual?

Sí, y no hace falta que sea el primer paso. Si estás empezando en QA, lo prioritario sigue siendo entender bien el testing manual: casos de prueba, bug reports, criterios de aceptación. Pero en cuanto tengas eso interiorizado, el testing de API con Postman es de las inversiones más rentables que puedes hacer.

No requiere aprender un lenguaje de programación desde cero, se puede aplicar desde el primer proyecto real y es exactamente el tipo de habilidad intermedia que separa un perfil QA manual puro de uno con perfil QA con automatización, que es donde sube de verdad el sueldo.

Si quieres dar el salto ordenado, desde los fundamentos del testing manual hasta la automatización con herramientas como Postman, Cypress o Playwright, el curso de introducción a la automatización está pensado exactamente para ese momento.