Le développement logiciel consiste à cultiver les différences de points de vue. L’une des raisons pour lesquelles différents rôles existent, comme les propriétaires de produits, les concepteurs, les développeurs, les testeurs, les DevOps et les chefs de projet, est d’avoir des points de vue différents au cours de tout cycle de vie. Il peut s’agir d’un cycle de vie de projet, d’un cycle de vie de produit, d’un cycle de vie de développement logiciel, d’un cycle de vie de test logiciel, etc. Un Product Owner sera orienté métier. Tout dépend de ce que nous publions et de sa valeur pour le client. Un développeur est plus axé sur la mise en œuvre. Il s’agit de savoir comment implémenter nos fonctionnalités dans le code. Le point de vue d’un testeur comprend généralement des aspects techniques et des aspects commerciaux. Il s’agit de critiquer le produit de manière constructive et de donner des commentaires précieux aux parties prenantes.
Une façon de cultiver les différences de points de vue est d’utiliser des activités de jumelage. La programmation en binôme et les tests en binôme sont deux des plus populaires. Cet article se concentre sur les tests par paires, et je partagerai des expériences sur la façon dont les équipes ont utilisé les tests par paires à leur avantage.
Test de paire par rôle
Les tests en binôme peuvent être effectués entre testeurs, entre développeurs et entre testeurs et développeurs. Tant qu’il y a une différence d’orientation et de perspective entre les personnes impliquées, le test par paires sera bénéfique.
Tests en binôme entre testeurs
Peu importe à quel point les tests sont bien planifiés et organisés, l’appariement entre les testeurs peut trouver des cas limites manquants. En particulier entre testeurs de différents niveaux d’expertise, le brainstorming de cas à tester lors d’une session exploratoire aidera à en savoir plus sur le système testé. Par exemple, un testeur d’utilisabilité associé à un testeur principal peut se compléter de manière à aboutir à des résultats intéressants. Les testeurs des différentes équipes de développement ont planifié des sessions de test en binôme chaque fois qu’une nouvelle fonctionnalité est prête à être testée. Dans certains cas, les tests par paires ont été planifiés avant l’exécution des tests et pendant la conception des cas de test.
Tests en binôme entre développeurs
Un développeur frontend et un développeur backend pourraient réfléchir à la raison pour laquelle les choses fonctionnent comme elles le font dans des cas d’utilisation qui nécessitent des implémentations délicates. Ensuite, les développeurs de différentes équipes pourraient tester par paires les interdépendances de code. Une équipe a utilisé des tests par paires pour les tests unitaires et les tests d’intégration. D’autres équipes ont effectué des tests par paires depuis les tests unitaires et d’intégration jusqu’aux tests d’API. Enfin, une équipe de développement sans testeurs a utilisé des tests par paires pour élargir son point de vue sur ses implémentations.
Tests en binôme entre testeurs et développeurs
C’est généralement l’une des combinaisons les plus efficaces pour tester les paires. Un développeur teste souvent pour vérifier que le code implémenté fonctionne comme prévu. Un testeur teste souvent de bout en bout pour vérifier que le système logiciel se comporte comme prévu. Plus important encore, le testeur doit également explorer tout type de risques et de surprises dans le système. Les tests en binôme avec un développeur pour surmonter les surprises et les risques peuvent être instructifs pour toutes les personnes impliquées. Le testeur peut apprendre du développeur pourquoi le système se comporte de cette façon. Le développeur peut apprendre de nouvelles façons d’examiner le système et d’utiliser des cas entraînant un comportement problématique. Par exemple, il y avait une équipe de développement de six personnes qui ont effectué des tests par paire avant la sortie. Les développeurs avaient déjà testé au niveau de l’unité et avaient également effectué des tests de fumée au niveau de l’interface utilisateur. Le testeur avait fini de vérifier le comportement du système et d’explorer. Ils ont utilisé une session limitée dans le temps où toute l’équipe a participé pour un dernier feu vert à libérer. Une autre équipe a effectué des tests de paires en équipe entière après la sortie. Une fois toutes les activités de test terminées et la fonctionnalité testée publiée, l’équipe s’est réunie pour une activité de test de fumée en équipe entière. Cela a aidé l’équipe à s’assurer que la sortie n’a causé aucune mauvaise surprise.
Publiez les fonctionnalités plus rapidement
Dans une équipe qui suivait un cycle du type : développement → revue de code → test QA → release, les tests en binôme avant les revues de code et pendant le développement ont aidé à publier les fonctionnalités plus rapidement. Les développeurs ont organisé des sessions de test en binôme avec des testeurs pour démontrer le fonctionnement de leurs fonctionnalités. Lors des tests en binôme, ils ont examiné les scénarios positifs et négatifs. Les aspects de l’apparence et de la convivialité de l’interface utilisateur ont été discutés, ainsi que les éventuels goulots d’étranglement des performances. Lorsque les deux étaient satisfaits des résultats de leurs tests par paires, le développeur vérifiait le code testé. Des revues de code suivraient, puis des tests d’assurance qualité approfondis de la part du testeur. Les tests de paires détectent généralement les problèmes de base. Cela a réduit le développement → révision du code → cycles de test QA pour corriger les bogues ou mettre en œuvre des améliorations importantes avant la publication. Moins de cycles signifiait des versions plus rapides.
Trouver plus de bogues
Les tests par paires peuvent être utilisés pour trouver de nouveaux bogues. Peu importe le nombre de tests que nous écrivons, peu importe le nombre de cas que nous exécutons, nous trouvons toujours plus de bogues lorsque nous sortons des sentiers battus et lorsque nous testons le système de nouvelles façons. Nous pourrions avoir une quantité impressionnante de cas de test couvrant toutes les exigences fonctionnelles et non fonctionnelles disponibles. Avec le temps, les suites de tests détecteront des bogues de régression. Bien que les bogues de régression soient importants à trouver et à corriger, il pourrait y avoir d’autres bogues importants qui restent non identifiés. Le remue-méninges pendant les tests en binôme peut apporter la créativité nécessaire pour explorer et identifier de nouveaux problèmes.
Corrigez les bogues plus rapidement
Montrer les problèmes à des collègues lors de sessions de test en binôme semble être plus efficace que de publier des bogues dans les systèmes de suivi des bogues et d’attendre qu’un collègue trouve le temps de corriger les bogues. Les bogues doivent être suivis dans les systèmes de suivi des bogues. Dans les environnements de travail à distance, cependant, où les gens travaillent dans des fuseaux horaires très différents, les bogues identifiés lors des sessions de test par paires sont plus susceptibles d’être résolus plus rapidement. Communiquer et travailler ensemble à travers un bogue conduit souvent à une résolution plus efficace des problèmes.
Expliquer aide aussi l’explicateur
Souvent, lorsque nous expliquons un phénomène au mieux de nos capacités, nous avons tendance à mieux comprendre le phénomène que nous venons d’expliquer. Non seulement les gens qui nous écoutaient savaient, mais nous comprenions aussi mieux. L’une des valeurs les plus importantes apportées par les tests de paires est que l’appariement améliore la compréhension des deux personnes. Cela conduira souvent à de nouvelles idées et à des solutions aux problèmes, car l’échange de nouvelles idées peut stimuler la créativité. Lorsqu’un développeur essaie d’expliquer comment les choses fonctionnent avec le nouveau code implémenté, il comprendra probablement des choses qui n’étaient pas si claires au départ. Lorsqu’un testeur explique la séquence d’actions suivies pour reproduire un problème sporadique, des détails cachés du problème peuvent lui apparaître.
Emballer
Les tests de paires peuvent être effectués entre tous les rôles d’un groupe de développement de logiciels. Entre Product Owners, designers, développeurs et testeurs et entre collègues ayant le même rôle. Pour tirer le meilleur parti de l’appariement, nous avons besoin de diversité dans les points de vue. La diversité peut mener à la créativité. Tant que la diversité conduit également à des commentaires constructifs, les tests par paires peuvent améliorer efficacement notre confiance dans les versions de fonctionnalités de haute qualité.