31. mai 2022
Pourquoi les développeurs et les testeurs ne peuvent-ils pas s'entendre ?
La relation entre les testeurs de logiciels et les développeurs de logiciels est pleine de tensions. Le plus souvent, elle est définie par la condescendance et la dépendance à contrecoeur de part et d'autre.
D'une part, les testeurs souffrent parfois de l'idée largement répandue selon laquelle tester des logiciels est généralement une tâche moins difficile ou moins exigeante que développer des logiciels. Cette idée est exacerbée par le fait que de nombreuses entreprises font de l'"ascension" de l'ingénieur AQ au "véritable" ingénieur logiciel une étape importante de leur échelle de carrière interne.
Les testeurs doivent aussi souvent demander au développement des fonctionnalités "supplémentaires" telles que la rétrocompatibilité et les descripteurs d'accessibilité, qui sont parfois perçues par les développeurs comme superflues et fastidieuses à mettre en œuvre.
De leur côté, les développeurs n'entendent souvent parler du service d'assurance qualité que lorsqu'ils perçoivent un problème dans leur travail. Personne n'aime entendre qu'il a fait une erreur, et tout le monde ne sait pas toujours gérer les critiques avec élégance.
Mais les développeurs dépendent en fait de la diligence et des connaissances du service d'assurance qualité. J'ai personnellement été témoin de la façon dont les développeurs peuvent construire des logiciels "techniquement corrects" sans vraiment comprendre le cas d'utilisation sous-jacent. Il en résulte des idiosyncrasies dans le logiciel qui sont difficiles à repérer sans une connaissance approfondie du domaine d'activité.
La question est la suivante : que peuvent faire les entreprises de logiciels pour atténuer cette tension ?
Pouvons-nous rendre la création de logiciels si facile que tout le monde peut le faire ?
Une idée pourrait être d'essayer de rendre les compétences traditionnelles de "développement de logiciels" inutiles pour la création de nouvelles applications.
C'était l'objectif du mouvement "Low Code". L'idée, parfois aussi appelée "programmation visuelle", était de construire des "méta-programmes", des boîtes à outils permettant de créer des logiciels pour un domaine spécifique à partir de blocs visuels, de modèles et peut-être de simples scripts.
Cette démarche a été motivée par la pénurie constante d'ingénieurs en logiciels. Cette pénurie fait que les entreprises sont incapables de faire évoluer les logiciels qu'elles utilisent ou vendent à un rythme suffisant pour répondre à la demande et à la concurrence.
Au lieu de construire chaque logiciel en code à partir de zéro, les testeurs de logiciels (ou même les gestionnaires et les utilisateurs finaux) pourraient utiliser un outil "sans code" ou "à faible code" pour assembler un nouveau logiciel répondant à leurs besoins à partir de blocs de construction existants, réduisant ainsi le travail des ingénieurs logiciels à la programmation de l'outil initial.
Le logiciel ainsi créé devra toujours être testé de manière approfondie, bien sûr, pour s'assurer qu'il répond aux spécifications initiales. Mais l'ensemble des compétences du testeur de logiciels, avec sa connaissance intime de ce que le logiciel doit faire, est bien adapté à la fois à la création et au test de logiciels à faible code.
Mais le rêve de rendre la création de logiciels aussi facile que l'édition d'une feuille de calcul a largement échoué.
La plupart des exigences logicielles sont, dans le détail, trop complexes et spécifiques pour s'intégrer dans un quelconque système modulaire. Dans le meilleur des cas, il est possible de construire un logiciel qui répond plus ou moins aux spécifications d'origine, mais qui est rempli de compromis, simplifié et difficile à utiliser. Un logiciel issu d'un système modulaire exigera toujours que ses utilisateurs s'y adaptent, au lieu de servir ses utilisateurs.
Certaines de ces idées de "low code" sont restées dans les services modernes de création de sites Web et dans certains outils d'automatisation des processus, et ont connu le succès dans ces domaines limités.
Mais elles ne sont pas, et de loin, la solution miracle qui permettra aux testeurs de se débrouiller sans dépendre des développeurs.
Pouvons-nous rendre le logiciel de test si pratique que chaque développeur puisse le faire ?
Alors, pourquoi ne pas résoudre notre énigme testeur-développeur dans l'autre sens ? Pouvons-nous rendre les logiciels de test si pratiques pour les développeurs qu'ils puissent s'en occuper eux-mêmes ?
La plupart des développeurs de logiciels connaissent aujourd'hui l'importance des tests. Beaucoup utilisent même les tests comme une partie essentielle de leur flux de travail de développement, comme dans le développement piloté par les tests.
Mais les développeurs préfèrent les types de tests qu'ils peuvent écrire, exécuter et maintenir avec leurs outils habituels. Les développeurs écrivent des tests dans le code, des tests unitaires qui s'exécutent rapidement et sans queue ni tête.
Et les développeurs ne testent généralement que le code sur lequel ils travaillent et dont ils sont responsables. Il est rare que le flux de travail d'un développeur intègre naturellement l'écriture de tests d'intégration entre les systèmes de différents développeurs ou équipes, sans parler des tests de bout en bout.
Le développement piloté par les tests ne se soucie généralement pas non plus du comportement sur d'autres matériels ou systèmes d'exploitation, ou sur des matériels ou logiciels hérités. "Fonctionne sur ma machine" est le mantra des types de tests que les développeurs écrivent pour faciliter leur développement.
S'ils sont les seuls responsables des tests, les développeurs auront également tendance à éviter d'écrire du code difficile à tester avec leurs méthodes de test préférées. Plus important encore, cela signifie qu'ils écriront aussi peu de code d'interface utilisateur que possible et qu'ils éviteront les états partout où ils le pourront.
Le résultat final est un logiciel semblable à une interface de ligne de commande : techniquement correct, mais difficile à utiliser et à comprendre.
Pouvons-nous nous rencontrer au milieu ?
Ce que nous venons d'explorer ne sont pas deux solutions, mais plutôt deux scénarios cauchemardesques en matière de qualité logicielle. Ce que nous devrions faire en réalité, c'est essayer de combiner les meilleures qualités des deux approches.
Pour cela, nous avons besoin de deux choses : La communication et le respect entre les testeurs et les développeurs.
Les problèmes entre les testeurs et les développeurs ne sont pas d'ordre technique, ils sont d'ordre organisationnel. Ils ont donc besoin d'une solution organisationnelle.
Les entreprises doivent favoriser une relation positive entre les testeurs et les développeurs. Les équipes d'assurance qualité et de développement devraient être encouragées à travailler ensemble et à se mettre à la place de l'autre. Les développeurs doivent être informés des outils et des flux de travail que l'AQ utilise pour son travail. Les testeurs doivent acquérir au moins une compréhension sommaire de la façon dont le logiciel est construit. Enfin, les entreprises doivent être structurées de manière à ne pas encourager la concurrence entre les équipes, mais à faire savoir que tout le monde travaille à un objectif commun.
Je sais que c'est beaucoup plus facile à dire qu'à faire. Mais le fossé entre les testeurs et les développeurs n'est pas aussi important qu'il n'y paraît parfois. Si chacun est libre d'apporter ses compétences et son point de vue, nous pouvons ensemble créer de grands logiciels.
Avantages de QF-Test pour développeures et avantages pour testeurs