Le mauvais QA, c'est un gars, y teste. Le bon QA, y teste aussi maaaaaais…

"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 co-produit).

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, s'il faut un QA, son rôle 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 prod, 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, nous y reviendrons en détail lors d'un prochain article (➡️ to-do).

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

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

Maintenant, reste la question à 100 balles : est-ce un rôle ou une compétence ? La réponse est dans la question 😊 En tout cas, je n'ai jamais rencontré de contexte justifiant un temps plein. Et quitte à investir du temps, je préfère l'investir sur la conception.

PS : c'était la dernière chronique avant une pause estivale de 3 semaines, durant laquelle je vous proposerai des rediffusions. Retour le mercredi 23 août avec du contenu tout neuf !