Entendiendo las Entrevistas de API Testing
Las entrevistas de API testing evaluan tu comprension de protocolos HTTP, arquitectura REST, mecanismos de autenticacion y tu capacidad para probar servicios backend independientemente del frontend.
Areas de Conocimiento Principal
Metodos HTTP y sus Implicaciones de Testing
| Metodo | Proposito | Idempotente | Foco de Testing |
|---|---|---|---|
| GET | Obtener datos | Si | Formato de respuesta, filtrado, paginacion |
| POST | Crear recurso | No | Validacion, prevencion de duplicados |
| PUT | Reemplazar recurso | Si | Reemplazo completo, campos faltantes |
| PATCH | Actualizacion parcial | No | Logica de actualizacion parcial |
| DELETE | Eliminar recurso | Si | Soft vs hard delete, autorizacion |
Conocimiento de Codigos de Estado
Exito (2xx): 200 OK, 201 Created, 204 No Content Redireccion (3xx): 301 Moved, 304 Not Modified Errores cliente (4xx): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable, 429 Too Many Requests Errores servidor (5xx): 500 Internal Error, 502 Bad Gateway, 503 Unavailable
Testing de Autenticacion
API Keys: Probar con key valida, invalida, faltante, expirada, revocada OAuth 2.0: Adquisicion de token, flujo de refresh, expiracion, validacion de scope JWT: Estructura de token, validacion de firma, expiracion, payload manipulado Basic Auth: Credenciales validas, invalidas, header faltante
Preguntas Comunes de Entrevista
P1: Como pruebas una API sin documentacion?
- Herramientas de desarrollador del navegador para capturar requests
- Analizar patrones de request/response
- Probar con diferentes metodos HTTP
- Buscar mensajes de error que revelen estructura
P2: Como validas el schema de respuesta de una API?
- Validacion JSON Schema para estructura y tipos
- Verificar campos requeridos
- Comprobar tipos de datos
- Validar objetos anidados y arrays
P3: Como pruebas el rendimiento de una API?
- Tiempo de respuesta bajo carga normal
- Throughput con usuarios concurrentes esperados
- Comportamiento bajo estres
- Connection pooling y timeouts
P4: Que es idempotencia y por que importa para testing?
- Operaciones idempotentes producen el mismo resultado sin importar cuantas veces se llamen
- GET, PUT, DELETE son idempotentes; POST tipicamente no
- Probar llamando el mismo endpoint multiples veces
Demostracion Practica de API Testing
Enfoque para testing de API CRUD:
1. Flujo positivo:
POST /users → 201 (crear)
GET /users/id → 200 (verificar creacion)
PUT /users/id → 200 (actualizar)
DELETE /users/id → 204 (eliminar)
GET /users/id → 404 (verificar eliminacion)
2. Testing de validacion: Campos vacios, tipos invalidos, duplicados 3. Testing de autorizacion: Sin token, token invalido, rol incorrecto 4. Casos borde: Modificaciones concurrentes, payloads grandes, caracteres especiales
Ejercicio: Desafio de API Testing en Vivo
Prueba esta especificacion API como si estuvieras en entrevista:
Endpoint: POST /api/bookings
Cuerpo: guest_name (string, requerido), check_in/check_out (fecha), room_type (standard|deluxe|suite), guests (1-4)
Escribe al menos 15 test cases.
Solucion
- Booking valido → 201
- Sin guest_name → 400
- Sin check_in → 400
- check_out antes de check_in → 400
- check_in en el pasado → 400
- Misma fecha check_in/check_out → clarificar
- Formato de fecha invalido → 400
- room_type invalido → 400
- guests = 0 → 400
- guests = 5 → 400
- guest_name muy largo → 400
- Caracteres especiales en nombre → 200
- Inyeccion SQL → 400
- Booking duplicado → 409 o 200
- Cuerpo vacio → 400
Puntos Clave
- Domina metodos HTTP, codigos de estado y patrones de autenticacion
- Estructura testing API por capas: funcional, validacion, auth, casos borde
- Demuestra enfoque sistematico al probar APIs desconocidas
- Entiende idempotencia, paginacion y rate limiting
- Se comodo tanto con Postman como con testing basado en codigo