Je considère que le testeur de logiciel n’est pas là uniquement pour exécuter une stratégie de tests, de façon automatisée ou non, pour nous permettre d’avoir une idée de la qualité d’un logiciel.
En effet, en tant que testeur, chaque fois que j’ai identifié un défaut, j’ai pensé qu’il est aussi de ma responsabilité d’en trouver les causes racines de façon précise en allant vers toutes les parties prenantes de l’organisation. Je veux parler d’abord des Développeurs de logiciels, mais aussi des Product Owners ou encore des Business Analysts par exemple. Concrètement, je m’y prends selon une approche structurée de résolution de problème, le PDCA. Pour chaque défaut, il faut remonter dans le processus de production du logiciel, pour identifier la pratique – de développement, ou encore de spécification, de capture du besoin – qu’il est nécessaire d’adapter pour que ce défaut ne se reproduise plus jamais.
L’idée est la suivante: pour faire en sorte que nos clients soient ravis, avec un logiciel qui fonctionne toujours parfaitement, nous n’allons pas seulement identifier les défauts et les corriger une fois le logiciel développé, mais surtout nous donner les moyens de faire évoluer nos pratiques de production de logiciels pour que celles-ci ne génèrent – idéalement – plus de défauts.
Le testeur, étant celui qui travaille à trouver les défauts que le client ne trouvera pas, reste bien placé pour porter cette démarche. Cette évolution de son rôle, au sein d’une équipe, consiste finalement à rendre visible les pratiques qu’il faut améliorer pour produire encore moins de défauts.
C’est pour cela que le testeur est, de fait, le déclencheur et le porteur de l’amélioration continue.
Contactez-nous pour échanger sur l’évolution du métier de testeur de logiciels.
Leave a Reply