¿Cómo hacer pruebas de APIs con Postman?

Postman es una herramienta gratuita que te permite enviar peticiones HTTP a una API y verificar si sus respuestas son correctas, sin escribir una sola línea de código.

Cuando la API falla y nadie sabe por qué

Imagina que Liverpool lanza una nueva función en su app: el carrito de compras ya no guarda los productos. El equipo de desarrollo dice que el backend funciona. El equipo de front dice que el error viene del servidor. Nadie sabe quién tiene razón.

Ahí entra el tester de QA con Postman. En cinco minutos puede enviar una petición directa a la API, ver la respuesta exacta y señalar con precisión dónde está el problema. Sin adivinar. Sin debates.

Esa es la ventaja de saber probar APIs: conviertes discusiones en evidencia.

El Sistema PETICIÓN-RESPUESTA-VALIDACIÓN

Probar una API con Postman siempre sigue el mismo ciclo de tres pasos. Llámalo el Sistema PRV:

1. Petición: tú defines qué quieres pedirle a la API.
2. Respuesta: la API te devuelve un resultado.
3. Validación: tú verificas si ese resultado es correcto.

Cada prueba que hagas en Postman repite este ciclo. Una vez que lo dominas, puedes probar cualquier API, sin importar la empresa o la tecnología.

Conceptos clave antes de abrir Postman

Antes de enviar tu primera petición, necesitas entender tres términos.

Endpoint: es la dirección URL a la que le hablas. Por ejemplo: https://api.mercadolibre.com/items/MLM123456.

Método HTTP: define qué tipo de acción quieres hacer. Los más comunes son:

• GET: obtener información.
• POST: crear algo nuevo.
• PUT o PATCH: modificar algo existente.
• DELETE: eliminar algo.

Código de estado: la API te responde con un número que indica si todo salió bien. Los más importantes son:

• 200 OK: éxito.
• 201 Created: se creó un recurso nuevo.
• 400 Bad Request: tu petición tiene un error.
• 401 Unauthorized: necesitas autenticarte.
• 404 Not Found: el recurso no existe.
• 500 Internal Server Error: el servidor falló.

Cómo instalar y abrir Postman

Descarga Postman gratis desde postman.com. Está disponible para Windows, Mac y Linux. También puedes usar la versión web si no quieres instalar nada.

Al abrirlo verás un panel central con una barra de URL. Ahí es donde empieza todo.

Tu primera petición GET paso a paso

Vamos a consultar la API pública de Mercado Libre. Esta API no requiere registro ni contraseña.

Paso 1: Abre Postman y haz clic en "New" → "HTTP Request".

Paso 2: Selecciona el método GET en el menú desplegable.

Paso 3: Escribe esta URL en la barra:

https://api.mercadolibre.com/sites/MLM/search?q=laptop

Paso 4: Haz clic en el botón azul "Send".

Paso 5: Observa la respuesta en el panel inferior. Verás un JSON con resultados de búsqueda de laptops. El código de estado debe ser 200 OK.

Eso es una prueba GET exitosa. Ahora vamos a validarla formalmente.

Cómo agregar validaciones automáticas con Scripts

Postman tiene una sección llamada "Tests" (pestaña dentro de cada petición). Ahí escribes código JavaScript simple para validar la respuesta automáticamente.

Estas validaciones se ejecutan cada vez que envías la petición. Postman te muestra en verde si pasan y en rojo si fallan.

Ejemplo 1: verificar que el código de estado sea 200

pm.test("El status es 200", function () {
    pm.response.to.have.status(200);
});

Ejemplo 2: verificar que la respuesta llegue en menos de 2 segundos

pm.test("Respuesta rápida", function () {
    pm.expect(pm.response.responseTime).to.be.below(2000);
});

Ejemplo 3: verificar que el JSON contenga la propiedad results

pm.test("Contiene resultados", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property("results");
});

Estos tres scripts cubren la mayoría de las validaciones básicas que necesitas en un proyecto real.

Cómo probar una petición POST

Una petición POST envía datos al servidor para crear algo. Por ejemplo, imagina que FEMSA tiene una API interna para registrar nuevos distribuidores.

Paso 1: Selecciona el método POST.

Paso 2: Escribe la URL del endpoint:

https://api.femsa-demo.com/distribuidores

Paso 3: Ve a la pestaña "Body", selecciona "raw" y cambia el formato a JSON.

Paso 4: Escribe el cuerpo de la petición:

{
  "nombre": "Distribuidora Norte SA",
  "ciudad": "Monterrey",
  "presupuesto": 250000
}

Paso 5: Agrega en la pestaña "Tests":

pm.test("Distribuidor creado correctamente", function () {
    pm.response.to.have.status(201);
});

Si la API responde con 201 Created, tu prueba pasa. Si responde 400 o 500, tienes un bug que reportar.

Colecciones: el corazón del trabajo profesional

Una colección en Postman es una carpeta donde agrupas todas las peticiones de un mismo proyecto. Es la diferencia entre un tester amateur y uno profesional.

Imagina que trabajas en Bimbo probando su API de pedidos. Tienes estas peticiones:

• GET /productos: lista todos los productos.
• POST /pedidos: crea un pedido nuevo.
• GET /pedidos/{id}: consulta un pedido específico.
• DELETE /pedidos/{id}: cancela un pedido.

Sin colección, cada prueba vive suelta. Con una colección, las tienes organizadas, puedes ejecutarlas todas en orden con un solo clic y compartirlas con tu equipo en segundos.

Cómo crear una colección:

1. Haz clic en "Collections" en el panel izquierdo.
2. Haz clic en el ícono "+" para crear una nueva.
3. Ponle un nombre descriptivo: "API Pedidos Bimbo - QA".
4. Arrastra tus peticiones adentro.

Variables de entorno: trabaja como profesional

Las variables de entorno te permiten cambiar la URL base sin editar cada petición. En México, los proyectos tienen al menos dos ambientes: desarrollo y producción.

En lugar de escribir https://dev.api.bimbo.com/pedidos en cada petición, defines una variable:

{{base_url}}/pedidos

Luego creas dos entornos en Postman:

• Desarrollo: base_url = https://dev.api.bimbo.com
• Producción: base_url = https://api.bimbo.com

Con un clic cambias de ambiente. Todas tus peticiones se actualizan solas. Eso es eficiencia real.

Errores comunes al probar APIs con Postman

Error 1: No revisar los headers. Muchas APIs requieren que envíes un header Content-Type: application/json en peticiones POST. Si lo omites, recibirás un 400 Bad Request aunque tu JSON esté perfecto.

Error 2: Confundir 401 con 403. 401 Unauthorized significa que no enviaste credenciales. 403 Forbidden significa que sí te autenticaste, pero no tienes permiso. Son errores distintos y requieren soluciones distintas.

Error 3: No guardar las peticiones. Postman no guarda automáticamente. Si cierras la pestaña sin guardar, pierdes tu trabajo. Presiona Ctrl+S después de cada cambio.

Error 4: Probar solo el camino feliz. La mayoría de los testers novatos solo prueban lo que debería funcionar. Un buen tester también prueba qué pasa si envías datos vacíos, datos con caracteres especiales, o un ID que no existe. Prueba el GET /pedidos/999999 cuando ese pedido no existe. ¿La API responde 404? ¿O explota con un 500?

Error 5: Ignorar el tiempo de respuesta. Una API que responde en 8 segundos tiene un bug de rendimiento aunque devuelva 200 OK. Siempre agrega la validación de tiempo de respuesta en tus scripts.

Ejecutar toda la colección de una vez

Cuando terminas de construir tu colección, puedes ejecutarla completa con el Collection Runner.

1. Haz clic derecho sobre tu colección.
2. Selecciona "Run collection".
3. Postman ejecuta todas las peticiones en orden.
4. Al final ves un reporte: cuántas pruebas pasaron y cuántas fallaron.

Este reporte lo puedes exportar y adjuntarlo en tu ticket de Jira o enviarlo por correo a tu líder técnico. Eso es evidencia profesional de QA.

El valor real de Postman en un equipo de QA

En equipos reales en México, el tester que sabe Postman tiene una ventaja concreta: puede detectar bugs de API antes de que lleguen al front-end. Eso ahorra horas de debugging y reduce los costos de corrección.

Un perfil de QA con conocimientos de Postman puede aspirar a sueldos de $18,500 a $28,000 al mes en empresas de tecnología en Ciudad de México, Guadalajara o Monterrey. Es una habilidad que se nota en el CV y se demuestra en la primera entrevista técnica.

Postman convierte tu intuición de tester en evidencia verificable: el lenguaje que hablan los equipos de ingeniería.