Postman para QA: cómo probar flujos completos de una API

Una prueba de API puede confirmar que una petición individual responde con el código HTTP esperado, pero eso no siempre demuestra que el sistema funcione correctamente. Un usuario real normalmente ejecuta un flujo: crea una cuenta o un recurso, consulta la información generada, la modifica y finalmente verifica el estado resultante.

Para QA, probar ese recorrido completo permite validar algo más importante que una respuesta aislada: cómo cambia el sistema a lo largo de una operación de negocio. En este artículo veremos cómo diseñar en Postman un flujo encadenado para crear un recurso, guardar su identificador, consultarlo, actualizarlo, comprobar su estado final y limpiar los datos generados.

Por qué una request aislada no siempre es suficiente

Una petición puede devolver un código 200 o 201 y, aun así, existir un problema funcional. Por ejemplo:

La respuesta de creación no devuelve el identificador esperado.
El recurso se crea, pero no puede recuperarse posteriormente.
La actualización responde correctamente, aunque no modifica el campo solicitado.
El sistema permite consultar un recurso que debería estar eliminado.
Una petición depende de datos generados en un paso anterior y utiliza un valor incorrecto.

Por eso conviene modelar la prueba como un flujo con precondiciones, pasos dependientes, validaciones y limpieza. Postman puede ayudar a ejecutar este tipo de escenarios mediante variables y scripts de prueba.

El flujo de ejemplo

Usaremos un recurso genérico llamado tasks. El nombre concreto puede sustituirse por clientes, pedidos, productos o cualquier otra entidad de una API.

Preparar la autenticación y el entorno.
Crear una tarea.
Guardar el identificador generado por la API.
Consultar la tarea creada.
Modificar su estado.
Validar que el cambio persiste.
Eliminar el recurso para dejar el entorno limpio.

Diseñar la prueba antes de abrir Postman

El primer paso no es crear requests, sino definir qué comportamiento se quiere verificar. Un caso de prueba de flujo debería indicar los datos de entrada, las dependencias entre pasos y las condiciones esperadas.

Ejemplo de caso de prueba

Precondición: existe un entorno disponible y el usuario de prueba tiene permisos para crear, consultar, actualizar y eliminar tareas.
Datos iniciales: título y descripción de una tarea identificable.
Resultado de creación: la API responde con el código esperado y devuelve un identificador.
Resultado de consulta: el recurso recuperado contiene los datos enviados.
Resultado de actualización: el estado cambia al valor solicitado.
Limpieza: el recurso generado se elimina al finalizar la prueba.

Esta definición evita que la colección se convierta en una secuencia de requests sin criterio. También ayuda a distinguir entre una falla funcional y un problema de configuración, autenticación o datos de prueba.

Separar configuración y datos dinámicos

La URL base, los tokens y los identificadores generados no deberían estar escritos directamente en cada request. Es preferible utilizar variables, por ejemplo:

baseUrl: dirección del entorno bajo prueba.
authToken: credencial o token utilizado por la API.
taskId: identificador generado durante la creación.

Así, la misma colección puede ejecutarse contra distintos entornos sin modificar cada petición. Los nombres exactos de los mecanismos de entorno o variables pueden depender de la versión de Postman y de la configuración utilizada, pero el principio es el mismo: mantener separada la configuración del flujo.

Crear el recurso y guardar su identificador

La primera request funcional puede ser una petición POST a una ruta como {{baseUrl}}/tasks. El cuerpo podría contener datos de prueba similares a los siguientes:

{
  "title": "Validar actualización de una tarea",
  "description": "Recurso creado para una prueba de flujo",
  "status": "pending"
}

En la pestaña de pruebas de Postman, la validación debería comprobar tanto el protocolo como el contenido relevante de la respuesta. No basta con verificar que la respuesta sea exitosa; también es necesario confirmar que existe el identificador que utilizarán los pasos posteriores.

pm.test("La tarea se crea correctamente", function () {
  pm.response.to.have.status(201);
});

const body = pm.response.json();

pm.test("La respuesta contiene un identificador", function () {
  pm.expect(body.id).to.exist;
});

pm.environment.set("taskId", body.id);

El ejemplo supone que la API devuelve el identificador en una propiedad llamada id. Si el contrato utiliza otro nombre, como taskId o un objeto anidado, la aserción debe ajustarse al contrato real.

Qué debe validarse en este paso

El código HTTP esperado para una creación exitosa.
La presencia del identificador.
El tipo de dato del identificador, si el contrato lo define.
Los campos que deben conservar el valor enviado.
La estructura mínima de la respuesta.

También es recomendable evitar identificadores de prueba repetidos cuando la API impone restricciones de unicidad. Un título dinámico puede ayudar, aunque no debe ocultar el objetivo de la prueba ni dificultar la trazabilidad de los datos.

Encadenar la consulta usando variables

Una vez guardado taskId, la siguiente request puede consultar el recurso mediante una URL como {{baseUrl}}/tasks/{{taskId}}. La dependencia es explícita: si la creación no guardó correctamente el identificador, la consulta debe fallar o quedar bloqueada, en lugar de probar accidentalmente otro recurso.

pm.test("La tarea puede recuperarse", function () {
  pm.response.to.have.status(200);
});

const task = pm.response.json();

pm.test("El recurso consultado corresponde al creado", function () {
  pm.expect(String(task.id)).to.eql(
    String(pm.environment.get("taskId"))
  );
});

pm.test("La tarea conserva el título inicial", function () {
  pm.expect(task.title).to.eql(
    "Validar actualización de una tarea"
  );
});

Comparar el identificador recuperado con el identificador almacenado es importante. Validar solamente que la respuesta sea 200 podría ocultar un problema de enrutamiento, autorización o sustitución incorrecta de variables.

Controlar variables inexistentes

Un error habitual consiste en ejecutar la consulta sin haber ejecutado antes la creación. En ese caso, la URL puede contener una variable vacía, antigua o perteneciente a otra ejecución. Para reducir ese riesgo:

Limpiar la variable antes de iniciar una nueva ejecución cuando corresponda.
Ejecutar las requests en el orden definido por el flujo.
Verificar en la consola de Postman el valor resuelto de la URL si la prueba falla.
Evitar reutilizar datos persistentes de una ejecución anterior sin validarlos.

Actualizar el recurso y comprobar el estado final

La actualización debe probarse como una operación independiente y como parte del flujo. Por ejemplo, una petición PATCH a {{baseUrl}}/tasks/{{taskId}} podría enviar:

{
  "status": "completed"
}

La respuesta de actualización puede variar según el contrato de la API. Algunas implementaciones devuelven el recurso modificado; otras responden sin cuerpo. Por ello, las aserciones deben basarse en el comportamiento acordado, no en una suposición general sobre el método HTTP.

pm.test("La actualización se acepta", function () {
  pm.response.to.have.status(200);
});

Si la API devuelve el recurso actualizado, se puede validar directamente el estado. Si no lo devuelve, el siguiente paso debe consultar nuevamente el recurso para comprobar la persistencia:

pm.test("El estado final es completed", function () {
  const task = pm.response.json();
  pm.expect(task.status).to.eql("completed");
});

Cuando la respuesta no contiene un cuerpo, no conviene llamar a pm.response.json() porque el script puede fallar por una razón distinta a la funcionalidad que se intenta validar.

Validar el efecto, no solamente la respuesta

Una prueba de actualización es más valiosa cuando confirma el efecto observable del cambio. El patrón recomendado es:

Enviar la modificación.
Validar el código HTTP y, si existe, la respuesta inmediata.
Consultar nuevamente el recurso.
Comprobar que el campo modificado tiene el valor esperado.
Confirmar que los campos que no debían cambiar permanecen intactos.

Este último punto es especialmente útil para detectar actualizaciones que reemplazan accidentalmente todo el recurso en lugar de modificar únicamente los atributos indicados.

Gestionar precondiciones, fallas y limpieza de datos

Un flujo completo debe considerar qué sucede cuando un paso intermedio falla. Si la creación funciona, pero la actualización no, el recurso creado no debería quedar abandonado en el entorno de pruebas.

Diseñar una limpieza segura

La limpieza puede implementarse mediante una request DELETE que utilice el identificador guardado: {{baseUrl}}/tasks/{{taskId}}. Después, se puede comprobar que el recurso ya no está disponible, siempre de acuerdo con el contrato de la API.

pm.test("La tarea se elimina correctamente", function () {
  pm.expect([200, 202, 204]).to.include(pm.response.code);
});

Los códigos aceptados deben definirse según la API concreta. No conviene aceptar varios valores únicamente para hacer la prueba más tolerante: cada código puede representar un comportamiento distinto, como eliminación inmediata o procesamiento asíncrono.

Si la colección se ejecuta con un runner o dentro de una automatización, la limpieza debe diseñarse para ejecutarse incluso cuando falle una validación intermedia. La forma concreta de organizarlo depende de la estrategia de ejecución. En algunos casos se utiliza una request final de limpieza; en otros, una colección separada o un mecanismo de preparación y desmontaje.

Qué hacer con datos existentes

Una alternativa es buscar y reutilizar un recurso ya existente, pero esto introduce riesgos:

El recurso puede haber sido modificado por otra prueba.
Puede pertenecer a un usuario con permisos diferentes.
Su estado inicial puede no coincidir con la precondición.
La limpieza podría eliminar datos que no fueron creados por la prueba.

Para flujos de integración suele ser más seguro crear datos identificables para la prueba y eliminar únicamente los recursos cuyo identificador fue generado durante esa ejecución.

Errores frecuentes al probar flujos con Postman

Validar únicamente códigos HTTP: una respuesta exitosa no confirma por sí sola que el contenido sea correcto.
Usar valores fijos para identificadores: el recurso puede no existir o haber sido cambiado por otra ejecución.
No comprobar la dependencia entre requests: una consulta podría estar probando un recurso diferente al creado.
Asumir siempre que existe un cuerpo JSON: algunas respuestas de actualización o eliminación no devuelven contenido.
Dejar datos de prueba en el entorno: con el tiempo pueden contaminar otros casos y dificultar el diagnóstico.
Aceptar demasiados resultados como válidos: una aserción demasiado flexible puede ocultar una regresión.
Mezclar pruebas funcionales con pruebas de carga: Postman puede servir para validaciones funcionales y automatizaciones, pero la estrategia para medir rendimiento requiere herramientas y criterios específicos.
Depender de un orden implícito: el flujo debe documentar qué request prepara los datos que utiliza la siguiente.

Cómo convertir el flujo en una prueba mantenible

Una colección útil para QA debe ser entendible por otra persona del equipo. Para conseguirlo, conviene organizar las requests por objetivo de negocio y no solamente por método HTTP.

Recomendaciones prácticas

Utilizar nombres descriptivos, como Crear tarea para flujo de actualización o Verificar tarea después de actualizar.
Mantener las variables de entorno separadas de los datos generados durante la ejecución.
Agregar aserciones pequeñas y específicas en lugar de un único script difícil de diagnosticar.
Documentar las precondiciones, permisos requeridos y códigos esperados.
Usar datos de prueba que permitan identificar el origen del recurso.
Incluir casos positivos y negativos relacionados con el mismo flujo.
Revisar qué ocurre cuando falta el token, el identificador es inválido o el recurso ya no existe.

También es importante diferenciar entre una prueba de contrato y una prueba de flujo. La primera se enfoca en la estructura y las reglas de una operación individual. La segunda verifica la interacción entre varias operaciones y el estado que dejan en el sistema. Ambas son necesarias, pero responden a preguntas distintas.

Conclusión: probar cómo cambia el sistema

Probar una API con Postman desde la perspectiva de QA no consiste únicamente en enviar requests y revisar códigos HTTP. Un flujo completo debe representar una operación real: preparar condiciones, crear datos, transportar identificadores entre pasos, comprobar efectos, validar el estado final y limpiar lo generado.

La decisión clave es definir qué comportamiento de negocio se quiere demostrar y convertirlo en una secuencia de validaciones explícitas. Las variables resuelven las dependencias dinámicas; las aserciones comprueban el contrato y los resultados; la limpieza mantiene confiable el entorno de pruebas.

Deja de validar requests aisladas y practica cómo cambia el sistema a lo largo de un flujo de negocio completo. Esta forma de trabajo es una base importante para seguir desarrollando habilidades de QA y automatización, como las que se profundizan en el curso QA Tester de Mentores Tech.

Postman para QA: cómo probar flujos completos de una API