Lección 6 de 7 · 2 min
Pruebas de API para QA manual
Al terminar sabrás
11 min- Leer una llamada de API: método, URL, body y status de respuesta
- Probar una API con Postman sin escribir una línea de código
- Encontrar los bugs que la UI esconde (validaciones y seguridad)
Construyes: Una tabla de pruebas de API sobre una API pública — material directo para tu portafolio.
Por qué un QA manual necesita probar APIs
La interfaz es la punta del iceberg: debajo, tu app conversa con el servidor por APIs. Probar solo por UI tiene dos problemas — es lento, y la UI te esconde errores (un backend que responde mal puede verse "bien" si el frontend lo disimula). El QA que sabe mirar la API encuentra bugs que el resto no ve, y es el requisito que separa las ofertas junior de las semi-senior.
El vocabulario mínimo
Una llamada a API tiene cuatro partes que te importan:
- Método: GET (leer), POST (crear), PUT/PATCH (modificar), DELETE (eliminar).
- URL:
https://api.ejemplo.cl/bookings/123 - Body: los datos que envías (JSON, casi siempre).
- Status de respuesta:
200OK ·201creado ·400pedido inválido ·401/403sin permiso ·404no existe ·409conflicto ·500explotó el servidor.
Tu primera prueba con Postman
- Descarga Postman (o usa Bruno/Insomnia, da igual).
- Crea una request
POST https://api.ejemplo.cl/bookingscon body:
{
"servicio": "corte",
"fecha": "2026-08-01T15:30:00",
"cliente": { "nombre": "Ana Pérez", "telefono": "+56 9 1234 5678" }
}
- Verifica: ¿status
201? ¿La respuesta trae elidde la reserva? ¿La reserva aparece después con unGET?
Los casos que la UI no te deja probar
Aquí está el valor real. La UI valida antes de enviar — pero ¿y si alguien llama a la API directo?
- Sin campos obligatorios: manda el body sin
telefono. ¿Responde400con mensaje claro, o500(bug)? - Tipos incorrectos:
"fecha": "mañana"— ¿la valida el servidor o solo la validaba el formulario? - Sin autenticación: quita el token de una llamada de admin. ¿
401, o te deja pasar (bug de seguridad grave)? - El doble POST: manda la misma reserva dos veces seguidas. ¿
409o reserva duplicada?
Comprueba lo aprendido en el quiz y rompe una API de verdad en el reto.
Compruébalo
0/3Responde sin mirar atrás. Verás la explicación al instante.
1. Creas un recurso con POST y todo sale bien. ¿Qué status esperas?
2. Una regla (ej: teléfono obligatorio) se valida solo en el formulario, no en la API. ¿Qué haces?
3. Quitas el token de autenticación de una llamada de admin y el servidor te deja pasar. ¿Qué es eso?
Reto: rompe una API de práctica
Usa una API pública de práctica (reqres.in o jsonplaceholder.typicode.com). Haz el CRUD completo de un recurso: crear, leer, modificar y borrar.
Luego rompe cada llamada de 3 formas distintas y documenta el status y mensaje de cada intento. Esa tabla es material de portafolio.