Lección 1 de 7 · 9 min
Fundamentos de APIs para QA
Al terminar sabrás
9 min- Explicar qué es una API y por qué un QA debe probarla, no solo la UI
- Leer las 4 partes de una llamada: método, URL, body y status de respuesta
- Usar la pestaña Network del navegador para descubrir la API real de una app
Construyes: Un mapa de las llamadas que hace una app real, leídas desde el DevTools.
La interfaz es solo la punta
Cuando reservas una hora en una app, la pantalla que ves es apenas la superficie. Por debajo, el navegador le envía mensajes al servidor —"crea esta reserva", "dame los horarios libres"— y recibe respuestas. Esos mensajes viajan por una API (Application Programming Interface).
Probar solo por la UI tiene dos problemas: es lento, y la interfaz 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.
El vocabulario mínimo
Una llamada a una API tiene cuatro partes que te importan:
- Método: la intención.
GET(leer),POST(crear),PUT/PATCH(modificar),DELETE(eliminar). - URL / endpoint: a qué recurso apuntas.
https://api.ejemplo.cl/bookings/123 - Body: los datos que envías, casi siempre en formato JSON.
- Status de respuesta: cómo salió.
POST https://api.ejemplo.cl/bookings
{
"servicio": "corte",
"fecha": "2026-08-01T15:30:00",
"cliente": { "nombre": "Ana Pérez", "telefono": "+56 9 1234 5678" }
}
Los status que debes memorizar
| Rango | Significado | Ejemplos |
|---|---|---|
| 2xx | Éxito | 200 OK · 201 creado · 204 sin contenido |
| 3xx | Redirección | 301/302 |
| 4xx | Error del cliente (tu pedido) | 400 inválido · 401/403 sin permiso · 404 no existe · 409 conflicto |
| 5xx | Error del servidor | 500 explotó · 503 no disponible |
Regla de oro: 4xx es culpa del que llama, 5xx es culpa del servidor. Si mandas un body inválido y recibes 500 en vez de 400, ahí hay un bug.
Por qué esto te sube de nivel
En las ofertas de trabajo, "pruebas de API" es la línea que separa al QA junior del semi-senior. No porque sea difícil, sino porque poca gente manual se atreve a cruzar de la UI al backend. Después de este curso, tú sí.
Comprueba lo aprendido en el quiz y mapea una API real en el reto.
Compruébalo
0/3Responde sin mirar atrás. Verás la explicación al instante.
1. ¿Por qué un QA debería probar la API y no solo la interfaz?
2. Creas un recurso con POST y sale bien. ¿Qué status esperas?
3. ¿Cómo descubres qué llamadas hace una app si no tienes documentación?
Reto: mapea la API de una app real
Abre una app o sitio que uses (banco, delivery, la que sea), abre el DevTools en la pestaña Network y usa la app normalmente unos minutos.
Anota 5 llamadas: método, URL (sin datos sensibles) y status de respuesta.