Comment les tests automatisés changent la composition des équipes chez Askida

Nous parlons beaucoup sur notre blogue de l’importance de la qualité logicielle pour Askida, mais qu’est-ce ça veut dire de façon concrète, dans les opérations de l’entreprise à chaque jour? Un développeur de notre équipe, Claudio, me racontait que lorsqu’il a commencé à travailler chez Askida, il était surpris du nombre de ressources assignées à l’assurance qualité parmi les équipes de développement. Je trouvais sa perspective très intéressante, alors je lui ai demandé si je pouvais partager son expérience sur notre blogue. Voici un résumé de notre conversation.

Pour commencer, est-ce que tu pourrais me parler de ton parcours?

En tant que développeur, j’ai commencé à m’intéresser aux méthodes Agile au début des années 2000. J’ai suivi une certification de Scrum Master en 2003 avec Ken Schwarber, qui est un peu un guru en matière d’Agile et de Scrum. J’ai suivi la certification pas nécessairement pour devenir Scrum Master, mais simplement pour mieux comprendre les avantages des méthodes Agile.

Par la suite, au travail, j’ai commencé à essayer de promouvoir les méthodes Agile, mais je travaillais pour des grosses compagnies qui ne voulaient pas vraiment chambarder leurs processus établis. Éventuellement, « Agile » est devenu une expression à mode et les gens autour de moi disaient qu’ils travaillaient « Agile » même si le modèle de développement lui-même ne changeait pas, donc restait « Waterfall ». Il y a des chefs de projets pour qui « Agile », tout ce que ça signifiait, c’était « plus vite ». Je commençais à voir clairement les bénéfices des méthodes Agile, des tests unitaires, des tests de non-régression et d’autres approches du genre, donc j’étais un peu déçu. En plus, ce n’était pas seulement les gestionnaires de projets qui préféraient ne pas changer leurs méthodes de travail, mais aussi des développeurs.

Qu’est-ce qui a changé quand t’es arrivé chez Askida?

D’abord, les méthodes Agile étaient déjà beaucoup mieux implantées et faisaient clairement partie de la culture de l’entreprise. Ensuite, j’ai été agréablement surpris quand j’ai constaté le nombre de ressources assignées à l’assurance qualité dans les équipes de développement. Dans d’autres entreprises, les gens disent qu’ils désirent livrer de la qualité, mais il n’y a souvent pas assez de conséquences si ce n’est pas le cas. Chez Askida, nous nous donnons réellement les moyens de livrer de la qualité.

La différence entre les méthodes d’Askida et les méthodes traditionnelles, pour moi, c’est un peu comme un acrobate qui marche sur un fil avec (ou sans) un filet de sécurité. En tant que développeur, l’assurance qualité chez Askida, c’est mon filet de sécurité. Disons par exemple que j’introduis du nouveau code dans un projet qui se trouve à briser un module déjà existant. S’il n’y a pas de tests de non-régression en place, il est possible que je ne réalise pas mon erreur avant un certain temps.

Avec les tests automatisés d’Askida, si jamais j’introduis une erreur dans un module existant, je peux le savoir très rapidement, ce qui permet un bien meilleur contrôle de la qualité.

En quoi est-ce que l’approche d’Askida change la composition des équipes?

Mon projet actuellement chez Askida compte 23 ressources. Avant d’arriver ici, j’ai travaillé sur un projet de la même taille, mais la répartition des ressources était très différente. Pour l’ancien projet, notre équipe était composée de 18 développeurs, 1 chef de projet, 1 Scrum Master, 1 architecte et 3 analystes AQ qui réalisaient des tests de façon manuelle. C’était très difficile de garder le contrôle. Les analystes AQ nous disaient « Arrêtez d’insérer des nouveaux bugs! » parce qu’ils ne voulaient pas re-tester manuellement des modules que nous avions déjà développés et testés. En matière de tests automatisés, tests unitaires ou tests de non-régression, il n’y avait presque rien en place.

Chez Askida, mon équipe en ce moment est composée de 8 développeurs, 1 chef de projet et 14 personnes qui développent des scripts pour les tests automatisés. Le nombre total de scripts augmente tout le temps, ce qui étend la couverture des tests automatisés. En ce moment, mon projet comporte plus de 5500 scripts de tests différents, et les tests automatisés de non-régression sont en place pour s’assurer que l’équipe de développement n’introduit pas de nouvelles erreurs dans des modules qui sont déjà fonctionnels. Le processus de développement est plus efficace pour tout le monde, pour les développeurs, pour les analystes AQ, pour notre chef de projet, et cela nous permet de livrer une meilleure qualité logicielle et un projet très gros et très complexe à temps.

Image Team Askida

Team Askida

L'équipe d'Askida // Team Askida