Ingénieur QA Questions d'entretien & Réponses

Exemple de réponse

Lors des tests de régression pour une mise à jour du traitement des paiements, j'ai remarqué que la conversion de devises arrondissait incorrectement pour les transactions inférieures à $1. La suite de tests automatisés avait réussi parce que tous les cas de test utilisaient des montants supérieurs à $10. Je l'ai découvert grâce aux tests exploratoires : j'ai systématiquement testé les valeurs limites proches de zéro, et constaté que les transactions de $0.99 ou moins étaient arrondies à $0.00 après la conversion. La cause principale était une division entière au lieu d'une division en virgule flottante dans la fonction de conversion. Si cela avait atteint la production, cela aurait affecté environ 15% de nos micro-transactions, soit environ 8,000 transactions quotidiennes représentant une perte estimée à $3,200 par jour. Après la correction, j'ai ajouté 20 cas de test sur les valeurs limites à la suite automatisée, couvrant les petits montants, les montants nuls et les montants maximaux dans chaque devise prise en charge.

Exemple de réponse

Notre suite de tests de bout en bout prenait 3 heures à s'exécuter et bloquait chaque fusion de pull request. Les développeurs sautaient les tests ou regroupaient les PR pour éviter l'attente. J'ai analysé la suite et identifié trois problèmes : les tests s'exécutaient en séquence au lieu de s'exécuter en parallèle, 30% des tests étaient redondants (ils testaient les mêmes chemins de code), et des tests instables provoquaient l'échec de 40% des exécutions dès le premier essai. J'ai conteneurisé l'environnement de test pour permettre l'exécution en parallèle sur 8 workers, supprimé 45 tests redondants, et mis en quarantaine 12 tests instables en en corrigeant les causes profondes (principalement des conditions de course et des données de test codées en dur). Le temps d'exécution est passé de 3 heures à 25 minutes, l'instabilité est tombée de 40% à moins de 2%, et la fréquence de fusion des PR par les développeurs a doublé. L'équipe est passée de voir les tests comme un obstacle à leur faire confiance comme filet de sécurité.

Exemple de réponse

J'ai constaté que notre fonctionnalité de recherche renvoyait des résultats dans un ordre différent lorsque la même requête était exécutée deux fois. Le développeur disait que c'était 'by design' parce que les résultats avaient des scores de pertinence égaux et que la base de données ne garantissait pas l'ordre en cas d'égalité. J'ai soutenu que c'était un bug UX même si c'était techniquement correct : les utilisateurs s'attendent à des résultats cohérents. J'ai présenté des enregistrements de sessions utilisateurs montrant leur confusion face à des résultats qui changeaient d'une recherche à l'autre. Nous avons trouvé un compromis : ajouter un tri secondaire par date de création pour les résultats de pertinence égale, ce qui donne un ordre déterministe sans modifier l'algorithme de pertinence. J'ai appris que les débats 'bug ou fonctionnalité' se résolvent mieux en examinant l'impact sur l'utilisateur, pas la correction technique. Si les utilisateurs sont perturbés, quelque chose doit changer, quelle que soit la spécification.

Exemple de réponse

Quand j'ai rejoint l'équipe, les développeurs écrivaient un minimum de tests unitaires et comptaient entièrement sur l'AQ pour détecter les bugs. Au lieu de faire des discours sur la couverture de tests, j'ai commencé à écrire du code de test en binôme avec les développeurs lors des revues de code. Je disais : 'Voilà comment je testerais cette fonction. Vous voulez ajouter ces cas ?' Après quelques sessions, les développeurs ont commencé à écrire leurs propres tests. J'ai également créé un 'mur des bugs' : un tableau de bord montrant où les bugs étaient trouvés (test unitaire, test d'intégration, AQ, production). En 3 mois, les données montraient clairement que les bugs détectés plus tard coûtaient exponentiellement plus cher à corriger. Le nombre de bugs en production a chuté de 55% à mesure que les développeurs intégraient la philosophie shift-left. L'essentiel était de rendre cela collaboratif : je me positionnais comme un facilitateur de la qualité, pas comme un agent de contrôle.

Exemple de réponse

La pyramide de tests comporte trois couches : les tests unitaires à la base (rapides, isolés, nombreux), les tests d'intégration au milieu (ils vérifient les interactions entre composants, en nombre modéré), et les tests de bout en bout au sommet (lents, système complet, peu nombreux). En pratique, je vise environ 70% unitaires, 20% d'intégration, 10% E2E. Les tests unitaires couvrent les fonctions individuelles et les cas limites : ils s'exécutent en quelques millisecondes et donnent un retour immédiat. Les tests d'intégration vérifient que les composants fonctionnent ensemble : les endpoints API renvoient des réponses correctes, les requêtes de base de données fonctionnent sur un schéma réel, les consommateurs de messages traitent correctement les messages. Les tests E2E couvrent les parcours utilisateurs critiques : inscription, achat, flux principal. Je les garde au minimum car ils sont lents, instables et coûteux à maintenir. L'anti-modèle que je combats le plus : la 'pyramide inversée', où les équipes ont 500 tests E2E et 20 tests unitaires. Résultat : des exécutions de 3 heures, une instabilité constante, et des développeurs qui ignorent les échecs de tests.

Exemple de réponse

Je testerais à quatre niveaux. Tests de contrat : valider que les schémas de requête et de réponse correspondent à la spécification OpenAPI. Cela détecte les changements cassants avant qu'ils n'affectent les consommateurs. Tests fonctionnels : pour chaque endpoint, tester les chemins nominaux, les erreurs de validation (champs manquants, types incorrects, valeurs limites), l'authentification et l'autorisation (accès non autorisé, mauvais rôle), et les cas limites (collections vides, tailles de charge utile maximales, caractères spéciaux). Tests d'intégration : vérifier que l'API interagit correctement avec ses dépendances, notamment les opérations de base de données, les appels aux services externes et la publication dans les files de messages. Utiliser une vraie base de données avec des données de test, mais simuler les services externes au niveau réseau. Tests de performance : mesurer le temps de réponse sous charge normale (référence), tester en charge pour trouver le point de rupture, et tester en endurance pour détecter les fuites mémoire sur des périodes prolongées. J'automatiserais tout cela dans le pipeline CI : tests de contrat et fonctionnels à chaque PR, tests d'intégration à la fusion sur main, tests de performance chaque nuit. J'utiliserais Postman/Newman pour les tests fonctionnels, k6 ou JMeter pour les performances, et Pact pour les tests de contrat.

Exemple de réponse

Un stub renvoie des réponses préconfigurées : il remplace une dépendance par une version simplifiée qui produit une sortie prévisible. J'utilise les stubs quand j'ai besoin qu'une dépendance renvoie des données spécifiques pour mon test, sans me soucier de la façon dont elle est appelée. Un mock est un stub qui enregistre aussi comment il a été appelé et permet de vérifier les interactions : cette méthode a-t-elle été appelée avec ces arguments ? J'utilise les mocks quand le comportement que je teste est l'interaction elle-même, par exemple vérifier qu'un service envoie un e-mail après l'inscription, sans s'intéresser au contenu de l'e-mail. Un fake est une implémentation fonctionnelle avec des raccourcis : une base de données en mémoire au lieu de PostgreSQL, un système de fichiers local au lieu de S3. J'utilise les fakes quand j'ai besoin d'un comportement réaliste mais que je ne peux pas utiliser la vraie dépendance dans les tests. Ma règle de base : préférer les fakes pour les entrepôts de données (plus réalistes), les stubs pour les API externes (prévisibles), et les mocks avec parcimonie pour la vérification des interactions. Le sur-mock est un anti-modèle courant : si vous simulez tout, vous testez vos mocks, pas votre code.

Exemple de réponse

Les tests instables sont un problème sérieux : ils érodent la confiance dans la suite de tests et habituent les développeurs à ignorer les échecs. Mon approche se déroule en quatre étapes. D'abord, identifier les tests instables de manière systématique. Je marque les tests qui échouent de façon intermittente et je suis leur taux d'échec. Tout test qui échoue plus d'une fois sans modification du code est considéré comme instable. Ensuite, la mise en quarantaine : déplacer les tests instables dans une suite séparée qui s'exécute mais ne bloque pas les déploiements. Cela préserve le rapport signal/bruit de la suite principale. Puis, corriger les causes profondes. Les sources les plus courantes sont les problèmes de timing (ajouter des attentes explicites pour les opérations asynchrones plutôt que des sleep), l'état partagé (assurer l'isolation des tests avec une configuration et un nettoyage appropriés), les dépendances externes (les simuler ou les conteneuriser), et la dépendance à l'ordre d'exécution (tests qui réussissent seuls mais échouent après un autre test). Enfin, prévenir les nouveaux tests instables : ajouter une détection des nouvelles tentatives au CI. Si un test réussit lors d'une nouvelle tentative, il est signalé comme potentiellement instable et un ticket est créé. Traiter les tests instables avec la même urgence que les bugs de production maintient la suite fiable.

Exemple de réponse

Je ne plaiderais pas pour du 'temps de test' dans l'abstrait : je rendrais le risque concret. Je demanderais : 'Quel est le coût si nous livrons un bug critique à nos 50K utilisateurs ?' Puis je présenterais un plan de test basé sur les risques. Je ne peux pas tout tester, donc j'identifierais les zones à risque le plus élevé : le nouveau code, le code modifié, et les flux utilisateurs critiques (paiement, authentification, intégrité des données). Je proposerais un plan de test ciblé sur 2 jours couvrant ces zones, avec des tests de régression automatisés exécutés en parallèle. Je présenterais également l'alternative : nous pouvons livrer sans tests, mais nous avons besoin d'un plan de retour arrière rapide et de quelqu'un d'astreinte pour répondre aux incidents. Rendre le compromis explicite ('nous gagnons 2 jours mais acceptons le risque de X') change généralement la conversation. Si le chef de produit insiste sur zéro test, je documenterais la décision et les risques par écrit. Dans mon expérience, quand vous quantifiez clairement le risque, la réponse est presque toujours 'trouvons ces 2 jours'.

Exemple de réponse

D'abord, j'évaluerais la gravité et l'impact. S'il affecte les fonctionnalités principales (perte de données, sécurité, paiements), je remonterais immédiatement l'information et recommanderais de retarder la livraison, sans exception. S'il s'agit d'un problème d'interface ou d'un flux mineur, je déterminerais si nous pouvons livrer avec un problème connu et un correctif sous 24 heures. Je communiquerais clairement au responsable de la livraison et au chef de produit : voici le bug, voici l'impact, voici les options. Option A : retarder la livraison, corriger le bug, relancer la régression. Option B : livrer sans la fonctionnalité concernée (la désactiver par feature flag). Option C : livrer avec un problème connu et fournir un correctif demain. Je fournirais ma recommandation mais laisserais les décideurs décider. Ce que je ne ferais pas : ignorer le bug, le minimiser, ou tenter une correction précipitée sans tests. Chaque 'correction rapide' tentée 1 heure avant une livraison que j'ai pu observer a introduit un second bug, pire que le premier.

Exemple de réponse

Je commencerais par tester ce que je peux déduire de la fonctionnalité : l'utiliser comme un utilisateur et documenter mes hypothèses. Je créerais un plan de test basé sur ces hypothèses et le partagerais avec le chef de produit et le développeur : 'Voici ce que je prévois de tester. Voici les hypothèses que je fais. Sont-elles correctes ? Qu'est-ce que je manque ?' Cette approche est plus rapide qu'attendre des exigences parfaites et révèle souvent des lacunes que le chef de produit n'avait pas envisagées. Pour chaque lacune, je poserais des questions précises : 'Que se passe-t-il si l'utilisateur saisit plus de 500 caractères ? Que doit afficher le message d'erreur ? Le formulaire doit-il conserver les données en cas d'échec de validation ?' Je regarderais également des fonctionnalités similaires dans le produit pour identifier les patterns de cohérence. L'objectif est de transformer des exigences vagues en critères d'acceptation testables par la discussion, sans attendre une spécification parfaite qui n'arrivera peut-être jamais.

Exemple de réponse

Je traiterais cela comme une vraie investigation, pas comme une confrontation. D'abord, je vérifierais l'assertion du test par rapport aux exigences actuelles : le test vérifie-t-il un comportement obsolète ? Si la fonctionnalité a intentionnellement changé et que le test n'a pas été mis à jour, c'est un écart de processus, pas un test incorrect. Je mettrais à jour le test pour correspondre au nouveau comportement. Ensuite, je vérifierais si le changement de comportement était intentionnel en consultant l'historique des commits, la description de la pull request et les tickets associés. S'il y a une décision documentée de modifier le comportement, le test doit être mis à jour. S'il n'y a pas de documentation, je demanderais au développeur et au chef de produit de confirmer. Parfois, les développeurs modifient involontairement le comportement lors d'un refactoring, et le test 'incorrect' a en fait détecté une vraie régression. Dans tous les cas, la discussion produit un bon résultat : soit nous mettons à jour le test (le changement est alors documenté), soit nous découvrons une régression non intentionnelle. Je signalerais également l'amélioration de processus à mettre en place : les changements de comportement devraient déclencher des mises à jour des tests dans la même PR.