Questions SQL en Entretiens QA: À Quoi S'Attendre et Comment Répondre

Les questions d'entretien SQL pour les ingénieurs QA se concentrent sur SELECT avec WHERE, les JOINs, GROUP BY avec des fonctions d'agrégation, et les sous-requêtes. Ce sont les requêtes utilisées pour vérifier les données de test, configurer l'état de la base de données, et déboguer les écarts entre l'UI et le backend.

Quel niveau de SQL les entretiens QA testent-ils ?

Pour la plupart des rôles QA en automatisation, le niveau junior couvre SELECT, WHERE, le filtrage de base, et la compréhension conceptuelle des JOINs. Le niveau intermédiaire requiert les JOINs (INNER, LEFT), GROUP BY, les fonctions d'agrégation (COUNT, SUM, AVG) et les sous-requêtes. Le niveau senior va jusqu'aux fonctions fenêtre, à l'optimisation de requêtes et à l'explication des plans d'exécution.

Si la description du poste mentionne "database testing" ou "data validation", attendez-vous à des questions SQL plus approfondies. Sinon, le niveau junior à intermédiaire est typique.

Questions principales et réponses

1. "Quelles requêtes SQL utilisez-vous le plus souvent dans vos tests ?"

Ce qu'ils veulent entendre : des cas d'usage concrets, pas des requêtes théoriques. Réponse solide : "Les requêtes que j'utilise le plus sont SELECT avec WHERE pour vérifier qu'un enregistrement a été sauvegardé avec les bonnes valeurs, et COUNT pour vérifier combien d'enregistrements existent. J'utilise aussi LEFT JOIN pour vérifier les relations entre tables, par exemple pour confirmer que créer une commande a aussi créé les lignes order_items correspondantes. J'utilise DELETE et INSERT pour configurer et nettoyer les données de test dans les environnements inférieurs."

2. "Comment vérifieriez-vous qu'un utilisateur a été créé correctement après une inscription ?"

-- Trouver l'utilisateur et vérifier les champs clés
SELECT id, email, role, is_active, created_at
FROM users
WHERE email = 'test_user@example.com';

Puis vérifier :

La ligne existe (si 0 lignes, l'inscription n'a pas écrit en base)
email correspond à ce qui a été soumis
role est 'member' (pas 'admin' par défaut)
is_active est false (si une confirmation par e-mail est requise avant l'activation)
created_at est récent (pas une ligne préexistante)

3. "Quelle est la différence entre WHERE et HAVING ?"

WHERE filtre les lignes avant l'agrégation. HAVING filtre les groupes après l'agrégation.

-- WHERE : filtrer des lignes individuelles
SELECT user_id, amount FROM orders WHERE status = 'completed';

-- HAVING : filtrer des groupes (après GROUP BY)
SELECT user_id, COUNT(*) as order_count
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 5;
-- Retourne les utilisateurs qui ont plus de 5 commandes

Pertinence pour le test : vous utiliseriez HAVING pour trouver des utilisateurs avec des entrées en doublon, des commandes au-dessus d'un seuil, ou toute condition agrégée.

4. "Expliquez la différence entre INNER JOIN et LEFT JOIN."

INNER JOIN retourne les lignes qui existent dans LES DEUX tables : uniquement les correspondances. LEFT JOIN retourne TOUTES les lignes de la table de gauche, plus les lignes correspondantes de droite. Les lignes de la table de droite sans correspondance ont des valeurs NULL.

-- Quels utilisateurs ont passé au moins une commande ?
SELECT u.email
FROM users u
INNER JOIN orders o ON u.id = o.user_id;
-- Seulement les utilisateurs qui ont des commandes

-- Quels utilisateurs n'ont JAMAIS passé de commande ?
SELECT u.email
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.id IS NULL;
-- Utilisateurs sans commande correspondante (la vérification NULL)

Pertinence pour le test : LEFT JOIN avec WHERE right.id IS NULL est un pattern classique pour trouver des enregistrements "orphelins" ou vérifier que quelque chose n'a PAS été créé.

5. "Comment trouveriez-vous des enregistrements en doublon dans une table ?"

SELECT email, COUNT(*) as count
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

Cela trouve les e-mails qui apparaissent plus d'une fois. Remplacez email par le champ qui doit être unique.

Cas d'usage en test : après une migration ou un import de données, vérifier qu'aucun enregistrement en doublon n'a été créé.

6. "Quelle est la différence entre DELETE et TRUNCATE ?"

| | DELETE | TRUNCATE |

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

| Supprime | Des lignes spécifiques (avec WHERE) ou toutes les lignes | Toutes les lignes (pas de clause WHERE possible) |

| Rollback | Peut être annulé (dans une transaction) | Généralement non (opération DDL) |

| Déclencheurs | Déclenche les triggers DELETE au niveau ligne | Ne déclenche pas les triggers |

| Vitesse | Plus lent pour les grandes tables | Beaucoup plus rapide |

| Usage en test | Configurer/nettoyer des données de test spécifiques | Réinitialiser des tables entières entre les exécutions |

-- Supprimer seulement l'utilisateur de test
DELETE FROM users WHERE email LIKE 'test_%@example.com';

-- Vider entièrement la table test_runs entre les suites
TRUNCATE TABLE test_runs;

7. "Comment utilisez-vous SQL pour la configuration des données de test ?"

Réponse solide : "J'utilise INSERT pour créer des utilisateurs de test, des commandes, ou toutes les données prérequises dans les environnements inférieurs. J'utilise aussi SELECT pour confirmer les pré-conditions avant qu'un test s'exécute, par exemple vérifier que l'utilisateur que je vais tester n'a pas déjà un compte. Après les tests, je nettoie avec DELETE en utilisant les mêmes identifiants que j'ai utilisés pour créer les données, pour laisser l'environnement propre pour la prochaine exécution." Exemple :

-- Configuration : créer un utilisateur de test
INSERT INTO users (email, password_hash, role, is_active)
VALUES ('playwright_test@example.com', '$2b$10$hashedpassword', 'member', true);

-- Vérification : confirmer qu'il existe avec les bonnes valeurs
SELECT id, email, role FROM users WHERE email = 'playwright_test@example.com';

-- Nettoyage : le supprimer
DELETE FROM users WHERE email = 'playwright_test@example.com';

8. "Comment trouveriez-vous toutes les commandes passées dans les 7 derniers jours ?"

SELECT id, user_id, total, status, created_at
FROM orders
WHERE created_at >= NOW() - INTERVAL '7 days'
ORDER BY created_at DESC;

(La syntaxe varie légèrement selon la base de données : PostgreSQL utilise INTERVAL '7 days', MySQL utilise INTERVAL 7 DAY, SQL Server utilise DATEADD(day, -7, GETDATE()))

9. "Qu'est-ce qu'une sous-requête et quand l'utiliseriez-vous ?"

Une sous-requête est une requête à l'intérieur d'une autre requête :

-- Trouver les utilisateurs qui ont passé des commandes de plus de 100 €
SELECT email FROM users
WHERE id IN (
    SELECT user_id FROM orders WHERE total > 100
);

Pertinence pour le test : utile quand vous devez filtrer par une condition qui implique une autre table sans faire un JOIN.

10. "Comment vérifieriez-vous l'intégrité référentielle après une suppression ?"

Si vous supprimez un utilisateur, vous pouvez vérifier que ses enregistrements liés ont aussi été supprimés (suppression en cascade). Vous vérifiez aussi que les contraintes de clé étrangère ont empêché des enregistrements orphelins.

-- Confirmer que l'utilisateur est supprimé
SELECT COUNT(*) FROM users WHERE id = 123;
-- Attendu : 0

-- Confirmer que les commandes liées ont aussi été supprimées (cascade)
SELECT COUNT(*) FROM orders WHERE user_id = 123;
-- Attendu : 0 (si la suppression en cascade est configurée)

-- OU confirmer que les commandes existent encore (si soft-delete est utilisé)
SELECT id, user_id, deleted_at FROM orders WHERE user_id = 123;
-- Attendu : lignes avec deleted_at défini

Conseils pratiques pour l'entretien

Si on vous demande d'écrire une requête sur un tableau blanc ou dans un éditeur de texte : commencez par dire ce que la requête doit faire avant de l'écrire. Écrivez d'abord la structure de base (SELECT ... FROM ... WHERE ...), puis ajoutez la complexité. Mentionnez que vous voudriez tester la requête sur des données réelles avant de la finaliser. Si vous ne vous souvenez pas de la syntaxe exacte : dites "Je vérifierais la documentation pour la syntaxe exacte, mais l'approche serait..." et expliquez la logique. C'est beaucoup mieux que de deviner une syntaxe incorrecte et de la défendre. Si on vous interroge sur une base de données que vous ne connaissez pas : précisez que votre expérience est principalement avec PostgreSQL, mais que le concept est le même en MySQL. La syntaxe pour l'arithmétique de dates est légèrement différente. Montrer une connaissance des différences entre bases de données est un plus.

Référence rapide : requêtes les plus utilisées par les QA

-- Vérifier qu'un enregistrement a été créé
SELECT * FROM table WHERE id = 123;

-- Vérifier le nombre (enregistrement créé ou supprimé)
SELECT COUNT(*) FROM orders WHERE user_id = 456;

-- Trouver des doublons
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1;

-- Trouver des enregistrements orphelins (qui ne devraient pas exister)
SELECT o.* FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE u.id IS NULL;

-- Enregistrements récents
SELECT * FROM logs WHERE created_at > NOW() - INTERVAL '1 hour';

-- Nettoyer les données de test
DELETE FROM users WHERE email LIKE 'test_%';

Le SQL en entretien QA consiste à démontrer que vous pouvez vérifier et manipuler des données. L'objectif est de soutenir le testing, pas d'écrire des schémas de base de données de production. Concentrez-vous sur les patterns pratiques ci-dessus et vous serez bien préparé.