Non, le QA n'est pas votre testeur attitré
Que le QA fasse des tests, oui. Que le QA fasse les tests, non !
Un QA n’est pas là pour faire les tests que les développeurs ne veulent pas ou ne savent pas faire. En aucune façon, parce que chaque développeur est responsable de bout en bout de ce qu’il produit (« Tu casses, tu répares ! », aurait dit, fort à propos, un ancien premier ministre). C’est, bien sûr, une dérive que l’on observe couramment, mais elle n’est jamais que le reflet d’un problème plus profond d’organisation ou de compétence.
Ce problème organisationnel, que nous allons étudier plus en détail, se traduit au final par un glissement de vocabulaire : « QA » (Quality Assurance) est un processus et non un rôle. Par la suite, je parlerai cependant moi aussi de « QA » pour me référer à l’usage couramment constaté.
Les effets pervers de la division du travail
En premier lieu, dissocier tests et développement n’est pas toujours possible. C’est justement le propre du Test-Driven Development que d’utiliser les tests pour guider le développement. Le TDD, on ne le rappellera jamais assez, est une pratique de développement avant d’être une pratique de test, les tests étant un heureux coproduit.
Mais le TDD n’est qu’une pratique parmi d’autres, utilisée principalement pour le développement du cœur du domaine, et il existe bien sûr d’autres types de tests. Par contraste, les tests end-to-end sont généralement écrits une fois l’application fonctionnelle – pratique test-after. Cela veut-il dire que le développeur peut pour autant s’en affranchir ?
Non, parce que séparer les postes de travail (développement et test) au profit d’une plus grande spécialisation – la division du travail chère à Taylor – allonge significativement la boucle de feedback. Au lieu de constater l’erreur en quelques heures maximum, la division du travail porte ce délai à plusieurs jours, le temps que le testeur prenne le relais et s’imprègne du travail réalisé par son collègue. Mais c’est aussi, plus profondément encore, parce que le système crée ainsi une incitation naturelle à produire des bugs, le raisonnement inconscient étant « je peux relâcher mon attention parce que quelqu’un vérifiera après moi ». Autrement dit, on ne peut pas séparer le faire et le faire bien.
Faire grandir l’équipe
Encore une fois, le fait qu’une seule personne effectue tous les tests en lieu et place du reste de l’équipe (PM/analyste/concepteur, développeur…) est un symptôme.
L’absence de tests de non-régression automatisés est souvent la première cause cachée qui conduit à cet état de fait. En l’absence de tests de non-régression sur CI, toute nouvelle fonctionnalité demande de vérifier à la main l’absence d’effets de bord non-désirés, sur un périmètre d’autant plus large que l’application n’est pas correctement modularisée. Comme la charge de travail est immense et non liée au travail d’un seul développeur, elle est mutualisée et dévolue au QA.
La cause première, ici, est donc un problème de savoir-faire des développeurs. Et c’est, à mon sens, l’une des premières missions du QA : plutôt que d’absorber cette charge de travail, à lui/elle de faire comprendre le problème et former les équipes. C’est, au fond, le travail d’un coach, qui doit contribuer à faire grandir l’équipe.
Pousser l’application dans ses derniers retranchements
Une des missions essentielles du QA est de pousser l’application dans ses derniers retranchements. Cela peut s’entendre du point de vue de la performance, de la tolérance à la charge, mais aussi de la sécurité et de l’accessibilité. Là encore, ces sujets doivent impérativement être anticipés au moment de la conception fonctionnelle ou technique. Les découvrir en fin de parcours n’est pas normal.
S’il est en revanche une chose qui, par essence, est effectuée post-développement car elle requiert déjà un produit utilisable, ce sont les tests exploratoires. Vous me direz, 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 ?), mais le défi du QA est d’identifier ces états incohérents en amont, avant que l’application ne parte en production.
Cette exploration suppose une parfaite maîtrise fonctionnelle de l’application. Il faut connaître déjà tous les cas limites d’une application pour être en mesure de les combiner et d’en imaginer de nouveaux. Certains bugs se découvrent par le fait du hasard, évidemment, mais plus nombreux encore sont ces bugs dont on a imaginé l’existence, et que l’expérience a permis de vérifier.
Travailler en amont avec les équipes à la conception fonctionnelle
Le mieux est encore d’imaginer ces scénarios complexes au moment de la conception fonctionnelle, d’où l’idée que le QA soit partie prenante de ce travail. En la matière, l’Example Mapping est la pratique idoine, puisque les exemples sur lesquels il fait reposer la conception fonctionnelle deviennent autant de tests d’acceptation à l’issue du développement.
Là encore, il me semble utile de préciser que le rôle du QA n’est pas d’exécuter les tests d’acceptation que ses collègues rechignent à faire. Ces tests sont, par définition, un contrat liant le Développeur au PM, parce qu’ils définissent le comportement attendu pour l’application. Comment moi, développeur, pourrais-je considérer mon travail comme fini et le soumettre à vérification par le PM si je n’exécute pas ces tests moi-même ? Quant au PM, comment savoir s’il a conçu le bon incrément applicatif s’il n’exécute pas ces tests lui-même (même une équipe très performante trouvera un petit 5% de comportement à modifier) ?
Comme toujours, un mauvais usage des mots nous enferme. Penser à « QA » comme un rôle ou, pire, comme un poste à pourvoir, ne fonctionne pas, parce que la « QA » est un processus : les tests d’acceptation sont des contrats de l’équipe, les développeurs écrivent eux-mêmes d’autres types de tests, et les tests exploratoires devraient, à mon sens, être menés conjointement par toute l’équipe, PM + Dev. Si bien que s’il faut encore un rôle ainsi nommé, ce serait celui d’un coach.