Lección 6 de 7 · 3 min
Pruebas de API para QA manual
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?
Ejercicio
Usa una API pública de práctica (reqres.in o jsonplaceholder.typicode.com): haz el CRUD completo de un recurso (crear, leer, modificar, borrar) y luego rompe cada llamada de 3 formas distintas. Documenta status y mensaje de cada intento — esa tabla es material de portafolio.