Perguntas de Entrevista sobre Testes de API para Engenheiros QA

Entrevistas de API testing avaliam duas coisas: conhecimento conceitual de métodos HTTP, status codes e fluxos de auth, e julgamento prático sobre o que realmente verificar em cada resposta. As perguntas que derrubam candidatos são baseadas em cenários. Incluem: como testar um endpoint DELETE, como autenticar ao longo de toda a suite, e por que retornar 500 para entrada inválida é um bug.

Perguntas fundamentais

1. "O que é API testing e por que é importante?"

2. "Qual é a diferença entre API testing e UI testing?"

| | API Testing | UI Testing |

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

| O que é testado | Requisição/resposta, lógica de negócio | Interface do usuário, elementos visuais, fluxos do usuário |

| Velocidade | Muito rápido (milissegundos) | Mais lento (segundos, inicialização do navegador) |

| Estabilidade | Alta — sem mudanças de DOM | Menor — seletores de UI quebram |

| Cobertura | Lógica de negócio, segurança, integridade de dados | Experiência do usuário, correção visual |

| Ferramentas | Playwright request API, Postman, REST Assured | Playwright, Cypress, Selenium |

Nenhum substitui o outro: eles capturam bugs diferentes.

3. "O que você verifica em um teste de API?"

Um bom teste de API verifica:

• Status code — é 200 quando deveria ser 201? Um token de auth faltando está retornando 401?
• Corpo da resposta — os campos corretos estão presentes? Os valores estão corretos?
• Tipos de dados — age é um número ou uma string? is_active é um boolean?
• Campos obrigatórios — campos faltando ou nulos que deveriam estar presentes
• Nenhum dado sensível vazado — hashes de senha, IDs internos, PII que não deveriam estar na resposta
• Respostas de erro — requisições inválidas retornam mensagens de erro úteis com o status code certo?
• Performance — a resposta volta dentro de um tempo aceitável?

4. "Explique os métodos HTTP que você usa em API testing."

| Método | Propósito | Exemplo |

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

| GET | Recuperar dados | Obter o perfil de um usuário |

| POST | Criar novo recurso | Registrar um novo usuário |

| PUT | Substituir um recurso completamente | Atualizar todos os campos do usuário |

| PATCH | Atualizar parte de um recurso | Atualizar apenas o e-mail do usuário |

| DELETE | Remover um recurso | Deletar uma conta de usuário |

5. "Quais status codes você verifica mais em API testing?"

Em vez de listar todos os status codes, dê uma resposta orientada a testes:

Perguntas sobre ferramentas e implementação

6. "Como você testa APIs no Playwright?"

test('POST /users retorna 201 com corpo correto', async ({ request }) => {
  const response = await request.post('https://api.becomeqa.com/users', {
    data: {
      email: 'novo_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('novo_usuario@test.com');
  expect(body).not.toHaveProperty('password'); // sem senha na resposta
});

7. "Como você lida com autenticação em testes de API?"

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('requisição autenticada funciona', async ({ request }) => {
  const response = await request.get('/api/users', {
    headers: { Authorization: `Bearer ${authToken}` },
  });
  expect(response.status()).toBe(200);
});

8. "Qual é a diferença entre Postman e Playwright para API testing?"

| | Postman | Playwright |

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

| Tipo | Ferramenta GUI para testes manuais + scriptados | Framework de automação baseado em código |

| Bom para | Exploração de API, verificações rápidas, mocking | Suites de testes automatizados, CI/CD, E2E + API combinado |

| Curva de aprendizado | Baixa | Moderada (requer programação) |

| Integração com CI/CD | Possível (Newman CLI) | Nativo, primeira classe |

| Qualidade do código de teste | Limitada | Suporte completo a TypeScript |

| Debug | Visualizador de requisição/resposta | Logs, trace viewer |

Perguntas baseadas em cenários

9. "Você está testando um endpoint DELETE. O que você verifica?"

Um teste completo de endpoint DELETE deve verificar:

1. Caminho principal: Deletar um recurso com auth válida → 204 No Content

2. Recurso realmente deletado: GET subsequente → 404

3. Idempotência: Segundo DELETE → 404 (não 500, não 204 novamente)

4. Autorização: Deletar sem auth → 401

5. Usuário errado: Deletar recurso de outro usuário → 403

6. Recurso inexistente: Deletar recurso que nunca foi criado → 404 (não 500)

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

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

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

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

10. "Como você testa o tratamento de erros de uma API?"

Checklist de testes:

• Campo obrigatório faltando → 400/422 com mensagem de erro clara
• Tipo de dado errado (string onde número é esperado) → 400/422
• Valor fora do intervalo → 400/422
• JSON válido mas falha na lógica de negócio (e-mail duplicado) → 409
• Corpo JSON malformado → 400
• Header Content-Type faltando → 400 ou 415

11. "O que é contract testing e quando você usaria?"

Contract testing verifica que uma API adere a um contrato acordado: a especificação de como requisições e respostas devem parecer. Ferramentas como Pact definem esses contratos entre consumidor (frontend) e provedor (backend).

12. "Como você testa paginação em uma API?"

test('paginação retorna tamanhos de página corretos', async ({ request }) => {
  // Primeira 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();
  // Itens diferentes da página 1
  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);

  // Além da última página
  const overPage = await request.get(`/api/products?page=${body1.pagination.total_pages + 1}&limit=10`);
  expect(overPage.status()).toBe(200); // ou 404, depende do design da API
  const bodyOver = await overPage.json();
  expect(bodyOver.data).toHaveLength(0); // ou array vazio
});

O que os entrevistadores querem ver

Além de acertar as respostas, os entrevistadores notam: