Comprendre le rôle de QA

"Le QA est là pour faire les tests" ➡️ Certainement pas.

Non, un/une QA (Quality Assurance engineer) n'est pas là pour faire les tests que les développeurs ne veulent pas ou ne savent pas faire. De toute façon, dans bien des cas, cela n'aurait simplement pas de sens : le Test-driven development  (TDD) est, littéralement, le développement guidé par les tests. Autrement dit, c'est une pratique de développement avant d'être une pratique de test, les tests sont un heureux coproduit.

Vous me direz : "Il y a d'autres types de tests, que l'on n'écrit pas dans le cadre du TDD". Et vous aurez raison : on écrira plus volontiers les tests d'intégration et les tests end-to-end dans le cadre d'une pratique test-after. Serait-ce donc au QA de les écrire ? Que nenni : en tant que développeur, je suis responsable de bout en bout de ce que je produis. Si je fais de la 💩, c'est à moi de nettoyer.

En revanche, le rôle du QA est de faire grandir l'équipe, c'est-à-dire identifier les lacunes dans les pratiques de test et ouvrir la voie à ses coéquipiers. Les "challenger", les convaincre de la nécessité de tester plus ou de tester mieux, et leur montrer comment faire.

Au-delà, un QA est là pour pousser l'application dans ses derniers retranchements. Ça, l'utilisateur le fait très bien, sans forcément savoir expliquer comment il est arrivé à telle ou telle situation de blocage (vous avez dit monkey-testing  ?) Le défi du QA est d'identifier ces états incohérents en amont, avant que le bousin ne parte en production, en imaginant des scénarios fonctionnels souvent un brin tordus.

Une pratique de test qui suppose donc une parfaite maîtrise fonctionnelle de l'application. "On ne trouve que ce que l'on cherche" dit-on parfois. C'est faux (cf. la sérendipité), mais pour ce qui nous occupe, une bonne connaissance du fonctionnel permet tout de même d'imaginer des parcours utilisateurs avancés, susceptibles de mener à des zones d'ombre de l'application.

Le mieux étant encore d'imaginer ces scénarios au moment de la conception fonctionnelle, d'où l'idée que le QA soit partie prenante de cette étape. L'Example Mapping  permet justement cela, puisque les exemples sont autant de tests d'acceptance, en plus d'être un moyen formidable de mener l'exploration fonctionnelle.

En conclusion, le rôle du QA est en grande partie d'aider les équipes à monter en compétence, qu'il s'agisse de conception fonctionnelle ou de test. L'autre dimension de son travail est plus exploratoire, mais dans tous les cas très loin de la conception habituelle de la personne "qui fait les tests"…

En résumé, le slogan du QA pourrait être le suivant :

 Faire les tests : non ; faire des tests : oui !