SQL pour les testeurs QA

En QA, SQL sert surtout à déterminer ce qui est réellement arrivé aux données, plutôt qu’à optimiser des requêtes complexes ou administrer une base. Lorsque l’UI et l’API se contredisent, la base fournit souvent la preuve la plus directe.

Même des bases en SQL améliorent sensiblement les tests : vérifier la création d’enregistrements, la persistance des statuts, les doublons, les relations, la concordance des rapports ou la disparition de données après une action.

Pourquoi les testeurs QA ont besoin de SQL

Au quotidien, SQL répond généralement à trois objectifs :

• →Vérifier l’état réel des données après un scénario
• →Analyser plus vite les défauts
• →Déterminer si le problème vient de l’UI, de l’API, de la logique ou des données

De nombreux défauts qui semblent liés à un bouton proviennent en réalité de l’état des données.

• →Un enregistrement apparaît dans l’UI, mais des lignes associées manquent
• →L’API annonce un succès, mais la modification n’a pas été enregistrée
• →Un rapport utilise les mauvaises données
• →Les nouvelles tentatives créent des doublons
• →Un filtre semble défaillant, car les données stockées ne correspondent déjà plus aux attentes du produit

Sans SQL, ces analyses peuvent être lentes et manquer de preuves.

Que faut-il apprendre en premier ?

Il n’est pas nécessaire de maîtriser tout le langage dès le début. Commencez par quelques éléments essentiels.

• →SELECT extrait les données
• →WHERE filtre les lignes
• →ORDER BY définit l’ordre
• →LIMIT évite de récupérer des lignes inutiles
• →COUNT compte les éléments
• →JOIN relie les données de plusieurs tables
• →GROUP BY permet les agrégations et la recherche de doublons
• →IS NULL et IS NOT NULL vérifient les valeurs nulles

Ces éléments couvrent une grande partie des tâches de test quotidiennes.

Comprenez le rôle de chaque construction autant que sa syntaxe. Avec les tables de commandes, d’utilisateurs et de paiements, SQL permet de vérifier un scénario complet, au-delà de l’affichage de lignes.

Ce que SQL apporte aux tests QA

La précision est le principal atout de SQL.

L’UI montre une sélection d’informations ; une API expose la réponse à un appel. L’inspection directe des données permet de répondre à ces questions :

• →L’enregistrement a-t-il été créé ?
• →Combien d’enregistrements de ce type existent réellement ?
• →Y a-t-il des doublons ?
• →À quel utilisateur appartient l’entité ?
• →Le bon statut a-t-il été enregistré ?
• →Existe-t-il des enregistrements orphelins ?
• →Le montant correspond-il à celui de l’interface ?
• →L’opération a-t-elle réellement modifié l’enregistrement, ou seulement donné cette impression ?

Cela est particulièrement utile pour les intégrations, les files de messages, les nouvelles tentatives, les tâches en arrière-plan, les mises à jour en masse et les relations complexes entre entités.

JOIN pour les testeurs QA

JOIN est particulièrement utile pour examiner les relations entre entités, au-delà d’une inspection séparée des tables.

• →Chaque commande possède un propriétaire
• →Une commande contient les lignes d’articles requises
• →Un paiement appartient à la bonne commande
• →Un utilisateur possède le bon rôle
• →Aucun enregistrement ne référence un objet inexistant

Souvent, l’enregistrement existe mais est mal relié, ou une partie de la chaîne de relations est rompue. JOIN rend ces défauts plus visibles.

Erreurs SQL fréquentes en QA

• →Confondre NULL avec une valeur vide
• →Oublier les lignes dupliquées par un JOIN
• →Inspecter uniquement la première ligne pratique
• →Exécuter des écritures inutiles

L’approche habituelle la plus sûre consiste à lire d’abord et à ne modifier les données délibérément que dans un environnement approprié. SELECT suffit pour la plupart des analyses.

Exemple pratique

Supposons qu’un utilisateur signale deux commandes identiques.

L’UI fournit une vue partielle et un endpoint API n’en montre qu’une partie. SQL permet d’établir bien davantage :

• →Si deux lignes de commande existent réellement
• →Si leurs clés métier correspondent
• →Si elles ont été créées au même moment
• →Si elles contiennent les mêmes articles
• →Si une nouvelle tentative a créé le doublon
• →S’il existe deux paiements ou un seul
• →Si le doublon est réel ou si l’UI affiche deux fois le même enregistrement

SQL devient ainsi un outil pratique de QA, au-delà d’un complément technique facultatif.

Bonnes habitudes en QA

• →Commencer par un SELECT simple
• →Inspecter d’abord une entité, puis ses relations
• →Toujours identifier la clé qui désigne les données
• →Éviter de conclure à partir d’une seule ligne lorsqu’une tendance plus large compte
• →Manipuler les requêtes d’écriture avec précaution
• →En cas de doute, comparer les preuves SQL aux comportements de l’API et de l’UI

SQL est particulièrement puissant pour relier les différentes couches du système.

Points essentiels pour les testeurs QA

• →En QA, SQL sert à vérifier la réalité des données plutôt qu’à programmer une base.
• →Les bases de SELECT, WHERE, JOIN, COUNT et GROUP BY permettent des analyses solides des défauts.
• →De nombreux défauts du produit viennent de l’état des données.
• →Relier les preuves de l’UI, de l’API et de la base est une compétence précieuse en test.
• →SQL rend le diagnostic plus précis, plus rapide et plus méthodique.

Lectures complémentaires

• →Dans cette base de connaissances : tests de bases de données
• →Dans cette base de connaissances : JSON et XML
• →Ressource externe : Tutoriel PostgreSQL sur les jointures

Pratiquer sur un jeu de données commun : huit exercices vérifiés

Utilisez la fiche d’exercices QA Hub liée et sql-for-qa-fixture.sql plutôt que de créer un second jeu de données. Il contient quatre clients fictifs et cinq commandes, avec des montants en centimes entiers. Ce guide utilise SQLite 3 ; la ressource décrit aussi du SQL portable, mais ces instructions ne prétendent pas avoir été exécutées sur PostgreSQL. Téléchargez les deux fichiers, ouvrez un terminal dans leur dossier et gardez une même session ouverte.

sqlite3 :memory:
-- At the SQLite prompt:
.read sql-for-qa-fixture.sql
SELECT COUNT(*) FROM qa_customers;
-- Expected: 4
SELECT COUNT(*) FROM qa_orders;
-- Expected: 5

Le script de préparation crée des tables temporaires dans la session courante. Une nouvelle session :memory: démarre vide ; relancer CREATE dans la même session sans réinitialisation échoue, car les tables existent déjà. Fermez la session jetable et démarrez-en une nouvelle pour réinitialiser les données. Aucune connexion ni aucun identifiant de production ne sont nécessaires.

Prédire les lignes avant de consulter les réponses

Exercice de la ressource	Résultat attendu
1 Commandes payées	(101, 1, 1200), (103, 2, 700), (105, 3, 0)
2 Commandes par client, y compris zéro	(1, Ada, 2), (2, Boris, 2), (3, Chen, 1), (4, Dina, 0)
3 Chiffre d’affaires payé par client	(1, 1200), (2, 700), (3, 0), (4, 0)
4 Clients sans commande	(4, Dina)
5 Adresses e-mail non nulles en double	(ada@example.invalid, 2)
6 Montant payé invalide selon la règle de l’exercice	(105, 0)
7 Au moins deux commandes	(1, 2), (2, 2)
8 Adresse e-mail absente	(4, Dina)

Les numéros d’exercice et les résultats sont les mêmes que dans la fiche téléchargeable. L’adresse e-mail dupliquée et la commande payée de montant nul sont introduites volontairement. Leur caractère défectueux dans un vrai produit dépend des exigences. Ne déduisez pas des règles d’unicité, de montant positif ou de normalisation à partir d’une simple requête.

Le piège de LEFT JOIN : un total correct malgré un client manquant

Comparez ces deux requêtes après le chargement du jeu de données commun. Le rapport doit afficher les quatre clients, y compris ceux sans commande payée. La première requête place le filtre sur les commandes payées dans WHERE :

SELECT c.customer_id, COALESCE(SUM(o.amount_cents), 0) AS paid_cents
FROM qa_customers c
LEFT JOIN qa_orders o ON o.customer_id = c.customer_id
WHERE o.status = 'paid'
GROUP BY c.customer_id ORDER BY c.customer_id;

Elle renvoie (1,1200), (2,700), (3,0) : Dina disparaît. Les champs de commande de sa ligne sans correspondance valent NULL ; la condition WHERE ne la conserve donc pas. La somme reste de 1900 centimes : vérifier uniquement le total général ne détecte pas le défaut.

Placez le filtre dans la condition de jointure pour conserver les clients sans correspondance :

SELECT c.customer_id, COALESCE(SUM(o.amount_cents), 0) AS paid_cents
FROM qa_customers c
LEFT JOIN qa_orders o
  ON o.customer_id = c.customer_id AND o.status = 'paid'
GROUP BY c.customer_id ORDER BY c.customer_id;

Résultat attendu : (1,1200), (2,700), (3,0), (4,0). Vérifiez à la fois les ID exacts des clients et les montants. Pour compter les commandes, utilisez COUNT(o.order_id) ; COUNT(*) compte aussi la ligne sans correspondance d’une jointure externe. Vérifiez NULL avec IS NULL, pas avec = NULL. La fiche de réponses contient ces cas et leurs requêtes exécutables.

Transformer un écart en preuve utile

Consignez la version du jeu de données, le dialecte SQL, la requête, la règle métier, les lignes attendues et les lignes obtenues. Triez explicitement les résultats avant une comparaison ordonnée. Pour un résultat non ordonné, comparez des ensembles ou des multiensembles selon la signification des doublons. Une requête exécutée sans erreur ne prouve pas la justesse du résultat métier.

Pour aller plus loin

Étendre les vérifications au comportement de la base

Signaler un écart de données avec des preuves

Télécharger le jeu de données SQL commun

Télécharger les huit exercices SQL et leurs réponses

Documentation SQLite : SELECT, jointures externes et filtrage