Questions d'Entretien sur les Tests d'API pour les Ingénieurs QA

Les questions d'entretien sur les tests API couvrent les méthodes HTTP, les codes de statut, et les flux d'authentification. Elles portent aussi sur la structure des requêtes et réponses, et sur l'utilisation d'outils comme Postman et APIRequestContext de Playwright pour tester les endpoints directement.

Questions fondamentales

1. "Qu'est-ce que le test d'API et pourquoi est-il important ?"

2. "Quelle est la différence entre le test d'API et le test UI ?"

| | Test d'API | Test UI |

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

| Ce qui est testé | Requête/réponse, logique métier | Interface, éléments visuels, parcours utilisateur |

| Vitesse | Très rapide (millisecondes) | Plus lent (secondes, démarrage du navigateur) |

| Stabilité | Haute : pas de changements DOM | Plus basse : les sélecteurs UI cassent |

| Couverture | Logique métier, sécurité, intégrité des données | Expérience utilisateur, correction visuelle |

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

Aucun ne remplace l'autre : ils détectent des bugs différents.

3. "Que vérifiez-vous dans un test d'API ?"

Un bon test d'API vérifie :

• Le code de statut : est-ce un 200 quand ça devrait être un 201 ? Un token d'authentification manquant renvoie-t-il bien 401 ?
• Le corps de la réponse : les bons champs sont-ils présents ? Les valeurs sont-elles correctes ?
• Les types de données : age est-il un nombre ou une chaîne ? is_active est-il un booléen ?
• Les champs obligatoires : champs manquants ou null qui devraient être présents
• Aucune donnée sensible exposée : hachages de mot de passe, IDs internes, données personnelles qui ne devraient pas figurer dans la réponse
• Les réponses d'erreur : les requêtes invalides renvoient-elles des messages d'erreur utiles avec le bon code de statut ?
• La performance : la réponse revient-elle dans un délai acceptable ?

4. "Expliquez les méthodes HTTP que vous utilisez dans les tests d'API."

| Méthode | Objectif | Exemple |

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

| GET | Récupérer des données | Obtenir le profil d'un utilisateur |

| POST | Créer une nouvelle ressource | Enregistrer un nouvel utilisateur |

| PUT | Remplacer une ressource entièrement | Mettre à jour tous les champs d'un utilisateur |

| PATCH | Mettre à jour une partie d'une ressource | Mettre à jour uniquement l'email d'un utilisateur |

| DELETE | Supprimer une ressource | Supprimer un compte utilisateur |

5. "Quels codes de statut vérifiez-vous le plus dans les tests d'API ?"

Plutôt que de lister tous les codes de statut, donnez une réponse orientée test :

Questions sur les outils et l'implémentation

6. "Comment testez-vous les APIs avec Playwright ?"

test('POST /users renvoie 201 avec le bon corps', async ({ request }) => {
  const response = await request.post('https://api.becomeqa.com/users', {
    data: {
      email: 'new_user@test.com',
      password: 'ValidPass1',
      role: 'member',
    },
  });

  expect(response.status()).toBe(201);
  
  const body = await response.json();
  expect(body.id).toBeTruthy();
  expect(body.email).toBe('new_user@test.com');
  expect(body).not.toHaveProperty('password'); // pas de mot de passe dans la réponse
});

7. "Comment gérez-vous l'authentification dans les tests d'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('la requête authentifiée fonctionne', async ({ request }) => {
  const response = await request.get('/api/users', {
    headers: { Authorization: `Bearer ${authToken}` },
  });
  expect(response.status()).toBe(200);
});

8. "Quelle est la différence entre Postman et Playwright pour les tests d'API ?"

| | Postman | Playwright |

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

| Type | Outil GUI pour les tests manuels et scriptés | Framework d'automatisation basé sur du code |

| Idéal pour | Exploration API, vérifications rapides, mocking | Suites de tests automatisés, CI/CD, E2E + API combinés |

| Courbe d'apprentissage | Faible | Modérée (nécessite de programmer) |

| Intégration CI/CD | Possible (Newman CLI) | Native, prioritaire |

| Qualité du code de test | Limitée | Support TypeScript complet |

| Débogage | Visualiseur requête/réponse | Logs, trace viewer |

Questions basées sur des scénarios

9. "Vous testez un endpoint DELETE. Que vérifiez-vous ?"

Un test complet d'endpoint DELETE doit vérifier :

1. Chemin nominal : supprimer une ressource avec une auth valide → 204 No Content

2. Ressource vraiment supprimée : GET suivant → 404

3. Idempotence : deuxième DELETE → 404 (pas 500, pas 204 à nouveau)

4. Autorisation : supprimer sans auth → 401

5. Mauvais utilisateur : supprimer la ressource de quelqu'un d'autre → 403

6. Ressource inexistante : supprimer une ressource qui n'a jamais existé → 404 (pas 500)

test('DELETE /orders/:id couverture complète', async ({ request }) => {
  // Créer la commande à supprimer
  const createResp = await request.post('/api/orders', { 
    data: { product_id: 1, quantity: 2 },
    headers: { Authorization: `Bearer ${userToken}` },
  });
  const { id } = await createResp.json();

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

  // Vérifier qu'elle a disparu
  const getResp = await request.get(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(getResp.status()).toBe(404);

  // Deuxième suppression → 404, pas de plantage
  const redoResp = await request.delete(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(redoResp.status()).toBe(404);
});

10. "Comment testez-vous la gestion des erreurs API ?"

Checklist de test :

• Champ obligatoire manquant → 400/422 avec un message d'erreur clair
• Mauvais type de données (chaîne à la place d'un nombre) → 400/422
• Valeur hors limites → 400/422
• JSON valide mais qui échoue la logique métier (email en double) → 409
• Corps JSON malformé → 400
• Header Content-Type manquant → 400 ou 415

11. "Qu'est-ce que le contract testing et quand l'utiliseriez-vous ?"

Le contract testing vérifie qu'une API respecte un contrat convenu : la spécification de ce à quoi les requêtes et réponses doivent ressembler. Des outils comme Pact définissent ces contrats entre le consommateur (frontend) et le fournisseur (backend).

12. "Comment testez-vous la pagination dans une API ?"

test('la pagination renvoie les bonnes tailles de page', async ({ request }) => {
  // Première page
  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();

  // Deuxième page
  const page2 = await request.get('/api/products?page=2&limit=10');
  const body2 = await page2.json();
  // Éléments différents de la page 1
  expect(body2.data[0].id).not.toBe(body1.data[0].id);

  // Dernière page
  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);

  // Au-delà de la dernière page
  const overPage = await request.get(`/api/products?page=${body1.pagination.total_pages + 1}&limit=10`);
  expect(overPage.status()).toBe(200); // ou 404 selon la conception de l'API
  const bodyOver = await overPage.json();
  expect(bodyOver.data).toHaveLength(0); // ou tableau vide
});

Ce que les recruteurs veulent voir

Au-delà des bonnes réponses, les recruteurs observent :