Le métier de testeur QA : rôle, cycle et communication
Le gain du jour : situer le testeur QA dans une équipe mobile réelle — ce qu’il fait au quotidien, avec qui il parle, et par quels outils transite l’information entre développeurs et QA.
Où se situe le testeur QA dans le cycle de développement
Dans une équipe mobile organisée en sprints (méthode agile), le testeur QA intervient à plusieurs moments, pas seulement à la fin :
- Grooming / raffinement de backlog — il challenge les critères d’acceptation d’une fonctionnalité à venir, pose les questions « qu’est-ce qui se passe si… » vues en leçon 1.
- Pendant le développement — il prépare ses cas de test en parallèle du code, sur la base des critères d’acceptation validés, sans attendre que le développeur ait fini.
- Recette / validation — il exécute la campagne de test dès qu’une version buildée est disponible (souvent via une distribution interne comme TestFlight pour iOS ou une piste interne du Play Console pour Android).
- Après la mise en production — il surveille les retours utilisateurs (avis store, crash reports via des outils comme Firebase Crashlytics) pour détecter des régressions passées inaperçues.
La communication dev-QA au quotidien
Le point de friction le plus fréquent dans une équipe mobile n’est pas technique, c’est la communication : un développeur corrige un bug sans que le testeur sache qu’il doit le re-tester, ou un testeur bloque une fonctionnalité sans que le développeur comprenne pourquoi.
Deux canaux structurent cette communication au quotidien :
- Le tracker de bugs (JIRA) pour le suivi individuel de chaque anomalie, son statut, ses commentaires techniques.
- Un tableau de bord partagé (Google Sheet) pour la vue d’ensemble d’une
campagne de test : quel pourcentage de cas de test est passé, combien sont
bloqués, quels appareils de la matrice de compatibilité restent à couvrir avant une
mise en production. Contrairement à JIRA, un Google Sheet permet à toute l’équipe
— y compris le product owner, qui n’a pas toujours de compte tracker — de voir
en un coup d’œil l’état de préparation d’une release, avec des formules simples
(
=COMPTE.SI) pour calculer automatiquement le taux de passage des tests.
Beaucoup d’équipes mobiles tiennent une courte réunion quotidienne (bug triage) où dev et QA passent ensemble les nouveaux bugs ouverts dans JIRA, décident de leur priorité, et mettent à jour le Google Sheet de suivi de campagne en direct. Quinze minutes suffisent à éviter des jours de flou sur « qui doit faire quoi ensuite ».
Testeur QA manuel, automaticien, ou les deux ?
Le métier s’est diversifié : certains testeurs restent centrés sur le test manuel et exploratoire (leçon 6), où le jugement humain reste irremplaçable (évaluation UX, cas limites imprévus) ; d’autres évoluent vers l’automatisation (SDET — Software Development Engineer in Test), écrivant des scripts de test avec Appium, Espresso ou XCUITest (leçon 11). Dans une équipe mature, les deux profils coexistent et se complètent : l’automatisation libère du temps humain pour l’exploratoire, qui à son tour identifie les nouveaux scénarios à automatiser.
Vérifie ta compréhension
Pourquoi une équipe mobile utilise-t-elle souvent à la fois JIRA et un Google Sheet, plutôt qu'un seul outil ?
À quel moment du cycle de développement un testeur QA devrait-il idéalement intervenir en premier ?
À toi de jouer
Esquisse un Google Sheet de suivi de campagne de test : colonnes appareil / OS / % de cas de test passés / bugs bloquants ouverts, pour une app fictive avant sa mise en production.
Liste les trois moments du cycle de développement où, selon toi, l’absence d’un testeur QA coûterait le plus cher à ton équipe si tu devais en choisir un seul.
🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.