Preguntas de Entrevista sobre Testing de API para QA

Las entrevistas de testing de API evalúan dos cosas: el conocimiento conceptual de métodos HTTP, códigos de estado y flujos de autenticación, y el juicio práctico sobre qué verificar realmente en cada respuesta. Las preguntas que complican a los candidatos son las basadas en escenarios: cómo testear completamente un endpoint DELETE, cómo manejar la autenticación en un suite de tests, y por qué un 500 como respuesta a input inválido es en sí mismo un bug. Cada pregunta a continuación incluye qué está evaluando el entrevistador y una respuesta que demuestra experiencia real, no solo definiciones.

Preguntas fundamentales

1. "¿Qué es el testing de API y por qué es importante?"

Respuesta sólida

2. "¿Cuál es la diferencia entre testing de API y testing de UI?"

| | Testing de API | Testing de UI |

|-|----------------|---------------|

| Qué se testea | Solicitud/respuesta, lógica de negocio | Interfaz de usuario, elementos visuales, flujos del usuario |

| Velocidad | Muy rápido (milisegundos) | Más lento (segundos, arranque del navegador) |

| Estabilidad | Alta, sin cambios de DOM | Menor, los selectores de UI se rompen |

| Cobertura | Lógica de negocio, seguridad, integridad de datos | Experiencia del usuario, corrección visual |

| Herramientas | API de request de Playwright, Postman, REST Assured | Playwright, Cypress, Selenium |

Ninguno reemplaza al otro: detectan bugs distintos.

3. "¿Qué verificás en un test de API?"

Un buen test de API verifica:

• Código de estado: ¿devuelve 200 cuando debería ser 201? ¿Un token de auth faltante devuelve 401?
• Body de la respuesta: ¿están presentes los campos correctos? ¿Los valores son correctos?
• Tipos de datos: ¿age es un número o una cadena? ¿is_active es un booleano?
• Campos obligatorios: campos faltantes o nulos que deberían estar presentes
• Sin datos sensibles filtrados: hashes de contraseñas, IDs internos, PII que no debería estar en la respuesta
• Respuestas de error: ¿las solicitudes inválidas devuelven mensajes de error útiles con el código de estado correcto?
• Tiempo de respuesta: ¿la respuesta llega dentro de un tiempo aceptable?

4. "Explicá los métodos HTTP que usás en el testing de API."

| Método | Propósito | Ejemplo |

|--------|-----------|---------|

| GET | Recuperar datos | Obtener el perfil de un usuario |

| POST | Crear un nuevo recurso | Registrar un nuevo usuario |

| PUT | Reemplazar un recurso por completo | Actualizar todos los campos de un usuario |

| PATCH | Actualizar parte de un recurso | Actualizar solo el email del usuario |

| DELETE | Eliminar un recurso | Eliminar una cuenta de usuario |

Distinción clave

GET debe ser idempotente (llamarlo 10 veces produce el mismo resultado). DELETE también debe ser idempotente (eliminar un recurso ya eliminado debería devolver 404, no fallar). POST no es idempotente: llamarlo dos veces normalmente crea dos registros.

5. "¿Qué códigos de estado verificás más en el testing de API?"

En lugar de listar todos los códigos, una respuesta orientada al testing:

Preguntas sobre herramientas e implementación

6. "¿Cómo testeás APIs en Playwright?"

test('POST /users devuelve 201 con el body correcto', async ({ request }) => {
  const response = await request.post('https://api.becomeqa.com/users', {
    data: {
      email: 'nuevo_usuario@test.com',
      password: 'ValidPass1',
      role: 'member',
    },
  });

  expect(response.status()).toBe(201);

  const body = await response.json();
  expect(body.id).toBeTruthy();
  expect(body.email).toBe('nuevo_usuario@test.com');
  expect(body).not.toHaveProperty('password'); // la contraseña no debe estar en la respuesta
});

7. "¿Cómo manejás la autenticación en los tests de API?"

Estructura de una respuesta sólida

let authToken: string;

test.beforeAll(async ({ request }) => {
  const response = await request.post('/api/auth/login', {
    data: { email: 'admin@test.com', password: 'AdminPass1' },
  });
  const body = await response.json();
  authToken = body.token;
});

test('la solicitud autenticada funciona', async ({ request }) => {
  const response = await request.get('/api/users', {
    headers: { Authorization: `Bearer ${authToken}` },
  });
  expect(response.status()).toBe(200);
});

8. "¿Cuál es la diferencia entre Postman y Playwright para el testing de API?"

| | Postman | Playwright |

|-|---------|-----------|

| Tipo | Herramienta GUI para testing manual y con scripts | Framework de automatización basado en código |

| Bueno para | Testing exploratorio de APIs, verificaciones rápidas, mocking | Suites de tests automatizados, CI/CD, E2E + API combinados |

| Curva de aprendizaje | Baja | Media (requiere programación) |

| Integración con CI/CD | Posible (Newman CLI) | Nativa, de primera clase |

| Calidad del código de tests | Limitada | Soporte completo de TypeScript |

| Depuración | Visor visual de solicitud/respuesta | Logs, trace viewer |

Preguntas basadas en escenarios

9. "Estás testeando un endpoint DELETE. ¿Qué verificás?"

Un test completo de un endpoint DELETE debe verificar:

1. Camino feliz: Eliminar un recurso con auth válida → 204 No Content

2. El recurso realmente fue eliminado: GET de seguimiento → 404

3. Idempotencia: Segundo DELETE → 404 (no 500, no 204 de nuevo)

4. Autorización: Eliminar sin auth → 401

5. Usuario incorrecto: Eliminar el recurso de otra persona → 403

6. Recurso inexistente: Eliminar un recurso que nunca existió → 404 (no 500)

test('DELETE /orders/:id cobertura completa', async ({ request }) => {
  // Crear la orden a eliminar
  const createResp = await request.post('/api/orders', {
    data: { product_id: 1, quantity: 2 },
    headers: { Authorization: `Bearer ${userToken}` },
  });
  const { id } = await createResp.json();

  // Eliminarla
  const deleteResp = await request.delete(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(deleteResp.status()).toBe(204);

  // Verificar que fue eliminada
  const getResp = await request.get(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(getResp.status()).toBe(404);

  // Segundo DELETE → 404, no falla
  const redoResp = await request.delete(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(redoResp.status()).toBe(404);
});

10. "¿Cómo testeás el manejo de errores de una API?"

Lista de verificación:

• Campo obligatorio faltante → 400/422 con mensaje de error claro
• Tipo de dato incorrecto (cadena donde se espera número) → 400/422
• Valor fuera de rango → 400/422
• JSON válido pero falla la lógica de negocio (email duplicado) → 409
• JSON malformado en el body → 400
• Header Content-Type faltante → 400 o 415

11. "¿Qué es el contract testing y cuándo lo usarías?"

El contract testing verifica que una API cumple con un contrato acordado: la especificación de cómo deben verse las solicitudes y respuestas. Herramientas como Pact definen estos contratos entre el consumidor (frontend) y el proveedor (backend).

12. "¿Cómo testeás la paginación en una API?"

test('la paginación devuelve el tamaño de página correcto', async ({ request }) => {
  // Primera página
  const page1 = await request.get('/api/products?page=1&limit=10');
  const body1 = await page1.json();
  expect(body1.data).toHaveLength(10);
  expect(body1.pagination.current_page).toBe(1);
  expect(body1.pagination.total_pages).toBeTruthy();

  // Segunda página
  const page2 = await request.get('/api/products?page=2&limit=10');
  const body2 = await page2.json();
  // Ítems distintos a los de la primera página
  expect(body2.data[0].id).not.toBe(body1.data[0].id);

  // Última página
  const lastPage = await request.get(`/api/products?page=${body1.pagination.total_pages}&limit=10`);
  const bodyLast = await lastPage.json();
  expect(bodyLast.data.length).toBeGreaterThan(0);
  expect(bodyLast.data.length).toBeLessThanOrEqual(10);

  // Más allá de la última página
  const overPage = await request.get(`/api/products?page=${body1.pagination.total_pages + 1}&limit=10`);
  expect(overPage.status()).toBe(200); // o 404, depende del diseño de la API
  const bodyOver = await overPage.json();
  expect(bodyOver.data).toHaveLength(0); // o array vacío
});

Qué buscan los entrevistadores

Más allá de responder correctamente, los entrevistadores notan: