Apportez Vos Propres Outils… Mais Réfléchissez-y à Deux Fois
Les équipes de développement logiciel disposent de plus de liberté que jamais. Elles ont accès à une grande variété d’outils, dont beaucoup sont gratuits. Il existe une abondance de briques open source disponibles pour créer des applications. Et le meilleur, c’est que de nombreux employeurs encouragent les équipes à installer leurs propres systèmes de développement, à choisir leurs méthodologies et à permettre aux membres de rapporter leurs propres outils.
La liberté d’utiliser les outils, méthodes et technologies que l’on préfère et que l’on maîtrise le mieux contribue probablement positivement à la productivité de l’équipe—jusqu’au moment où on atteint les limites de l’autonomie de l’équipe.
Évitez un goulot d’étranglement dans les tests
Mon ami Jan dirigeait une équipe logicielle très compétente dans une entreprise de développement de logiciels sur mesure. Ils comprenaient vraiment comment être agiles. Et ils avaient un problème de qualité. Ils avaient tellement accéléré leur cycle de publication que les tests étaient devenus un goulot d’étranglement.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Et ils ont éliminé ce goulot d’étranglement en sautant l’étape de test. Jan, bien sûr, savait ce qu’il fallait faire. Il a téléchargé Robot Framework, l’a utilisé pour construire un cadre d’automatisation des tests personnalisé pour l’équipe et l’a intégré à leur pipeline d’intégration continue. Petit à petit, il a ajouté de plus en plus de tests et a enrichi le framework avec un grand nombre de mots-clés de haut niveau pour simplifier l’écriture des scripts de test.
Pendant ce temps, les autres équipes—et elles étaient nombreuses—rencontraient des défis similaires et y répondaient à leur manière, avec Selenium ou un autre outil de leur choix.
Les équipes ont besoin d’un cadre d’automatisation pour tous
Les pessimistes disent que chaque solution contient la graine d’un nouveau problème. Jan a vite découvert qu’il était devenu ingénieur en automatisation des tests à plein temps. Certes, ses bibliothèques étaient faciles à utiliser—pour lui, et son architecture de test était facile à comprendre—pour lui. Dans chaque autre équipe, il y avait un collègue dans la même situation. L’un d’eux a changé d’emploi. La développeuse qui a pris la relève a décidé de tout réécrire, car elle n’aimait pas la façon dont l’automatisation avait été réalisée et la trouvait difficile à comprendre. Lorsque plusieurs équipes ont commencé à signaler ces défis à leurs managers, la question évidente s’est posée : pourquoi n’y a-t-il pas de cohérence entre les équipes ?
Il fallait faire quelque chose. La solution était évidente : instaurer une équipe centralisée d’automatisation des tests qui servirait les équipes de développement en fournissant un unique cadre d’automatisation pour tous. En pratique, l’équipe se composait de Jan et d’un autre développeur. C’est là que la vraie lutte a commencé.
Partager la méthodologie, pas seulement les outils
Les tests se cassaient fréquemment. Le framework aussi. Les équipes de développement avaient du mal à modifier leurs pratiques pour s’adapter à l’outil, et l’équipe d’outillage avait du mal à répondre à tous ces besoins différents. La complexité du framework ne cessait de croître. Le goulot d’étranglement des tests était devenu un goulot d’étranglement de l’outillage d’automatisation des tests.
Le partage d’outils internes est une belle idée, mais il est difficile de la faire fonctionner. Pour réussir, l’outil doit être géré comme un vrai produit, et il doit être bien testé. Paradoxalement, les frameworks d’automatisation des tests faits maison sont souvent bogués. Mais il existe un défi encore plus grand. Pour profiter des outils partagés à grande échelle, il faut aussi une méthodologie partagée.
L’histoire de Jan est typique—et elle n’est pas terminée. Ils réfléchissent maintenant à leur prochaine étape : revenir à des équipes autonomes et accepter le coût, investir davantage dans l’outillage commun et établir une méthodologie cohérente, ou bien choisir un outil commercial et se concentrer uniquement sur la méthodologie. Aucune de ces options n’est mauvaise, mais chacune d’elles aura des conséquences différentes.
