Est ce que le testeur est seul à tester dans l’équipe?
Les questions
Cet article apporte des éléments de réponses aux questions suivantes :
- Est ce que en tant que testeur je dois réaliser tous les tests dans un projet?
- Est ce que dès qu’il y a le mot test alors c’est moi qui est responsable?
- Est ce que quand il y a un problème dans le logiciel c’est ma faute?
Les mauvaises réponses
Il y a effectivement des croyances largement répondues qui conduisent à mal répondre à ces question, par exemple :
Oui dès qu’il s’agit de tester c’est au Testeur de faire. (Les développeurs développent et les testeurs testent.)
Dès qu’un incident apparait sur l’application déployée en production c’est la faute du testeur, car c’est à lui de veiller à ce que aucun défaut ne traverse jusque là.
Pourquoi ces réponses sont mauvaises
a. “Les développeurs développent et les testeurs testent”
Cette réponse est fausse pour les raisons suivantes :
- Le temps
- L’argent
- La main d’œuvre : les compétences
- L’équilibre des pouvoirs : l’indépendance
Le temps et l’argent
Pour illustrer ce point, imaginons une équipe composée de 3 développeurs et un testeur.
Souvenons nous des niveaux de test : Les fonctionnalités programmées par les développeurs doivent passer par plusieurs niveaux de test : les tests unitaires, les tests d’intégration, les tests système et les tests d’acceptation
Disons que chaque développeur travaille sur une fonctionnalité qui prend 2 jours de codage et 1 jour de tests unitaire.
Si c’est le testeur qui doit coder les tests unitaires (parce que c’est tests sont codés avec un langage de programmation), alors il devra y travailler pendant 3 jours (1 jour x 3 fonctionnalités)
alors que chaque développeur n’a travaillé jusque là que 2 jours (codage de la fonctionnalité)
Et cela sans prendre en compte le fait que dans la réalité le testeur aura besoin de plus qu’un jour pour coder les tests unitaires d’une fonctionnalité développée par quelqu’un d’autres, il doit donc l’assimiler avant de créer les tests unitaires correspondants.
Ajoutons à cela 1 jour par fonctionnalité pour faire les tests d’intégration et 2 jours par fonctionnalité pour faire les tests système.
Cela fait donc 3+3+6 = 12 jours/homme de travail pour le testeur.
Alors le testeur travaillerait 12 jours pour chaque 2 jours de travail d’un développeur.
Pour absorber cette charge de travail, le gestionnaire du projet doit alors recruter une équipe de 6 testeurs pour que les testeurs et les développeurs finissent le travail au même moment.
Et les tests d’acceptation qui les fait? si ce sont les même testeurs alors la charge augmentera encore plus ainsi que les coûts associés.
La main d’œuvre
Même si on est prêts à payer le prix, ou est ce qu’on peut trouver des testeurs qui maîtrisent autant de sujets différents, par exemple : Java pour le code, JUnit pour les tests unitaires, Jenkins pour l’intégration continue, Git pour le versioning du code, les techniques de tests statiques, les techniques de test dynamique, les outils de gestions de test comme XRAY, ALM ou Squash, les outils de gestion des anomalies comme Mantis, les protocoles d’interfaçage, les outils des tests d’intégration comme Postman, les tests de régression, les tests automatisés , les tests de sécurités et les tests de performances qui sont des domaines à part entières…etc.
Autant chercher des moutons à 5 pattes.
C’est une mauvaise affaire pour le client puisque même s’il met plus de temps et d’argent sur cette configuration, le travail sera finalement moins bien fait.
L’équilibre et l’indépendance des pouvoir
Un autre point qui fait qu’on ne peut pas juste mettre les testeur partout, c’est que le testeur doit garder une distance par rapport à la technologie pour qu’il puisse préserver sa capacité à juger un logiciel par “ce qu’il permet de faire” et non par “comment il est fabriqué”.
Un logiciel qui est codé avec les technologies les plus récentes ne doit pas émouvoir le testeur si ces technologies ne permettent pas d’atteindre l’utilité fonctionnelle attendue.
Pour juger de cette utilité un testeur doit garder le recul nécessaire pour se concentrer sur la valeur ajoutée contrairement au développeur qui doit plonger dans les considérations techniques.
ce sont là deux paradigmes différents et tous les deux sont nécessaires pour la réussite d’un projet.
Pour faire le parallèle avec l’équilibre des pouvoir politiques, le pouvoir législatif, le pouvoir exécutif et le pouvoir judiciaire
Le rédacteur des spécifications représente le pouvoir législatif car il crée la loi qui est ensuite suivie par les développeurs qui représentent le pouvoir exécutif, Et finalement le travail des testeurs ressemble au pouvoir judiciaire car ils jugent la qualité du produit par rapport aux spécifications.
Les spécifications jouent le rôle de la loi dans un projet logiciel.
Dès qu’un incident apparait sur l’application déployée en production c’est la faute du testeur, car c’est à lui de veiller à ce que aucun défaut ne traverse jusque là.
Si ton client pense ça alors il faut être pédagogue et lui rappeler les principes généraux des tests:
- Les tests exhaustifs n’existent pas
- Les tests montrent la présence de défauts mais ne garantissent pas l’absence de défauts
- Et l’illusion de l’absence de défauts
Les tests ne garantissant pas l’absence des défauts, les testeurs ne peuvent pas non plus garantir l’absence des défauts.
Le testeur travaille sur la base du risque.
S’il n’y a pas de risque il n’y a pas de test.
Tout le travail du testeur est de réduire le risque au maximum selon les moyens à disposition.
Un testeur n’annonce donc jamais un risque 0.
Comme il a un temps limité pour tester un périmètre, il essaye de trouver les défauts les plus critiques au plus tôt pour se donner le temps de les corriger.
L’idéal c’est que si des incidents réussissent à se retrouver en production , alors ces incidents sont mineurs, car on a trouvé et corrigés tous les défauts majeurs bien avant.
Mais ça c’est l’idéal.
Alors le testeur ne garantie pas l’absence d’incidents en production.
La bonne réponse
La qualité est l’affaire de tout le monde et pas seulement des testeurs.
Le testeur peut piloter tous les aspects de la qualité s’il a assez d’expérience mais ne peut prendre en charge toutes les actions de test.
En se basant sur la pyramide des niveau de test nous pouvons faire une première distribution des responsabilités
Les niveaux de tests unitaires et intégration sont réalisés en général par les développeurs.
Les niveaux de test système et acceptation sont réalisés par des testeurs mais pas les mêmes
Les tests systèmes ont pour objectif de vérifier le produit par rapport aux spécifications fonctionnelles et sont alors réalisés par les testeurs de l’entité qui a fabriqué le produit : la maitrise d’œuvre, le fournisseur de service ou l’éditeur logiciel
Les tests d’acceptation ont pour objectif de valider que le produit répond aux besoins métier alors ces tests sont réalisés par des testeurs appartenant à l’entité qui va recevoir le produit : le client ou la maîtrise d’œuvre.
Les tests de sécurité et de performances sont aujourd’hui quant à eux assez pointus et sont réalisés par des spécialistes dont c’est le métier.
Quand un testeur réalise des tests système ou d’acceptation, il donne des résultats de test sous forme d’indicateurs qui expriment clairement le niveau de qualité de la partie couverte par les tests et le niveau de risque résiduel de la partie non couverte par les tests.
Dites moi dans la zone commentaires ce que vous pensez de cette distribution de travail théorique à adapter bien sûr à chaque contexte?
Dites moi aussi comment les tests sont organisées dans votre projet?