Leadership dans le test : tester en équipe

Parfois, il peut même ne pas y avoir de testeurs du tout (dun-dun-duuu), les analystes métiers et les développeurs prenant l’entière responsabilité des tests.

Le Shift-Left n'est pas une nouveauté — les défenseurs des tests prônent le mantra « testez tôt, testez souvent » depuis de nombreuses années. Dès 1993, il a été suggéré que tous les artefacts dans un processus en étapes — qu'ils soient documentaires ou logiciels — pouvaient (et devraient souvent) être testés.

Le Shift-Left consiste essentiellement à anticiper la réflexion sur les tests dans le processus.

Bien que le cycle de vie Waterfall ait été dominant à l'époque, le nombre ou la durée des phases importent peu. Le principe fondamental était que les Sources de Connaissance qui orientent la conception et le développement logiciel doivent être remises en question ou testées. 

Dans un projet en étapes, cela peut impliquer des revues formelles. Dans un projet Agile, le testeur (ou le développeur, l'analyste métier ou l’utilisateur) peut suggérer des scénarios qui remettent en question l'auteur d'une exigence ou d'une User Story afin de réfléchir à des exemples concrets et d’en discuter avant d'écrire la moindre ligne de code.

Voici les principaux changements impliqués par le phénomène Shift-Left :

1. L'approche Behavior Driven Development (BDD) a permis aux développeurs, utilisateurs/analystes métiers et testeurs de collaborer autour de ce que l’on pourrait appeler des histoires métier. Le Test-Driven Development est utilisé par de nombreux développeurs depuis plus de 15 ans. Aujourd’hui, le BDD est de plus en plus adopté, car il favorise une meilleure collaboration dans les équipes agiles tout en introduisant des outils BDD utilisables par les développeurs. C'est une approche Test-First plus accessible.
2. Le Continuous Delivery (CD) existe depuis 5 à 10 ans et puise ses racines dans les méthodes d'automatisation de build et de déploiement mises au point par les grandes entreprises du web. Cette approche est désormais adoptée par la plupart des organisations ayant une présence en ligne.
3. Le CD a systématisé et accéléré le processus de mise en production grâce à l’automatisation. Mais cela a aussi mis en lumière les délais de production, de déploiement et de changements d'infrastructure qui étaient auparavant masqués par la lenteur des processus de build, test et mise en production. Le DevOps correspond à un changement de mentalité culturelle dans lequel les développeurs collaborent bien plus étroitement avec les équipes d’exploitation. Aujourd’hui, de nouveaux outils apparaissent quasiment chaque jour et les éditeurs présentent le DevOps comme « la prochaine grande tendance ». La situation est très dynamique et surmédiatisée.
4. SMAC, c’est-à-dire Social, Mobile, Analytics et Cloud, représente une transformation dans la façon dont les organisations gèrent l’évolution métier et système dans l’univers mobile. Les expérimentations métiers, réalisées via des changements en production, sont surveillées très finement. Les « données massives » ainsi collectées sont exploitées et les décisions métier sont prises à partir des analyses réalisées.

L’expérimentation fréquente avec les systèmes en production permet à l’innovation d’avancer « à la vitesse du marketing ». L’expérimentation est au cœur de ce qui a été la tendance majeure des années 2010 : la transformation numérique.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with LinkedIn

Or sign up with email:

URL

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Les tests comme activité, pas comme rôle

Le Shift-Left modifie le rôle des testeurs. La répartition des tâches de test induite par cette approche montre clairement que les testeurs ne sont plus les seuls responsables. C’est-à-dire que les testeurs ne « possèdent » plus les tests. 

Si vous y réfléchissez, ils n’ont jamais vraiment été responsables des tests, mais il existait une compréhension tacite dans les projets : peu importe ce que le reste de l’équipe, en particulier les développeurs, réalisait comme tests, les testeurs servaient de filet de sécurité. Si les développeurs étaient pressés par le temps et réduisaient leurs tests pour livrer plus vite, le filet de sécurité était assuré par les testeurs.

Le test est désormais une activité, et non un rôle.

Les développeurs adoptent de meilleures pratiques de test et offrent plus de transparence sur leur travail. De bons tests de composants ou des tests unitaires ont des objectifs spécifiques qui diffèrent (par exemple) des tests système. Par conséquent, la portée (ou la quantité) des tests au niveau système peut être réduite. 

La répartition correcte des objectifs de test, ainsi que les tests pour les atteindre, constitue le but principal de la stratégie de test. Malheureusement, jusqu’à récemment, les développeurs n’étaient pas véritablement tenus responsables, de sorte qu'ils s’appuyaient sur une phase tardive de tests système pour compenser.

Le shift-left responsabilise davantage les développeurs.

Dans l’ensemble, la responsabilité des tests est redistribuée, donc le rôle du testeur évolue. Les testeurs peuvent effectuer moins de tests tactiques, mais leur contribution stratégique augmente. Les testeurs peuvent prendre en charge la stratégie de test, remettre en question les exigences, consulter les parties prenantes et tisser une relation plus étroite avec les développeurs afin de soutenir de meilleurs tests côté développement et l’automatisation des tests.

Un nouveau rôle

Le shift-left implique que chaque fois qu'il est possible de fournir un retour d’information utile à l’équipe pour comprendre, remettre en question et améliorer les objectifs, les exigences, la conception ou la réalisation, ce retour doit être offert. 

Utilisateurs, analystes métier, développeurs et toute l’équipe de développement doivent être prêts à échanger ce type de retours. Parfois, il peut y avoir des réticences, mais l’objectif global reste de mener un projet plus efficace et mieux informé – rien de plus.

La façon la plus simple de résumer ce comportement est : « impliquez-vous tôt »—aussi tôt que possible. Participez aux discussions et collaborez sur les idées, les besoins et à chaque stade dont le résultat influera sur la valeur du livrable final du projet. 

Pour faire simple, le testeur met au défi les sources de connaissance, qu’il s’agisse des parties prenantes, des utilisateurs, des développeurs, des user stories, de documents ou de précédents.

L’approche la plus courante consiste à challenger par l’exemple. À chaque étape, ces exemples peuvent être considérés comme des tests. Ils peuvent être rapidement abandonnés après utilisation, ou transformés en tests automatisés ou processus manuels. Ces exemples peuvent aussi servir tactiquement à pointer des failles dans les raisonnements, ou être fournis aux développeurs, par exemple comme des idées ou points de départ pour des tests développeur. Ils peuvent également servir comme outils de coaching pour montrer aux utilisateurs ou développeurs comment concevoir de meilleurs tests.

Considérez votre projet logiciel comme un processus d’acquisition de connaissances. Celles-ci sont collectées tout au long du projet et évoluent souvent au fil du temps. L’objectif du shift-left est d’assurer la fiabilité de ces connaissances en les challengeant et en les testant au plus près de leur source, et de faire en sorte, autant que possible, qu’elles soient fiables avant d’être figées dans le code.

Le shift-left pousse la philosophie du test en amont encore plus loin. L’Agilité a toujours encouragé la collaboration et le feedback rapide—le shift-left peut être considéré comme une démarche coordonnée de retour rapide. Si votre équipe adopte l’approche shift-left en matière de tests, disposer des bons outils peut tout changer. Consultez notre sélection d’outils de test logiciel pour trouver ce qui conviendra le mieux à votre équipe.

Interventions agiles sur les tests

L’approche shift-left est fondamentale dans une stratégie de test pour les projets agiles. En contexte agile, on peut considérer la stratégie de test comme une série d’interventions. Tous les projets connaissent des moments décisifs où existe une opportunité de recueillir ou de donner du feedback. Le testeur doit se concentrer sur ces moments clés et être prêt à intervenir à ces moments-là.

Dans vos propres projets, vous devez identifier les moments critiques où une intervention est possible et déterminer les choix que vous pouvez faire en tant qu’équipe sur l’organisation des tests. Par exemple, est-ce au testeur d’écrire des tests unitaires pour les développeurs, de fournir des exemples pour les lancer, ou de les accompagner afin d’améliorer leur capacité de test ? À vous et à votre nouvelle équipe de test logiciel d’en décider.

Nous allons utiliser un processus Scrum classique pour illustrer la façon dont les interventions de test peuvent s’insérer dans cette méthodologie. Les interventions se produisent soit au niveau du projet (ou de la release), soit à celui d’un sprint. Le schéma ci-dessous présente une vue au niveau projet et les cinq interventions majeures.

La remise en cause des user stories et leur définition sont l’occasion pour le testeur de valider une user story et les critères d’acceptation proposés pour celle-ci. Les tests d’intégration vérifient que les nouvelles fonctionnalités s’intègrent correctement avec les autres et avec le système global. Les tests système et utilisateur (acceptation) sont menés quand cela s’avère nécessaire.

Un projet comporte généralement plusieurs sprints et les quatre interventions de sprint sont illustrées dans le schéma ci-dessous. Le stand-up quotidien est l’occasion de faire le point sur l'avancement, de signaler des problèmes, d’identifier des risques ou de discuter des questions soulevées et des réponses reçues au cours du sprint. 

L’affinage des user stories et les contributions aux tests des développeurs sont des activités quotidiennes qui se déroulent dans les échanges avec les utilisateurs, les analystes et les développeurs. Le testeur intègre les tests du développeur et les nouveaux tests du système dans une base de tests automatisés toujours croissante.

Dans le tableau ci-dessous, vous pouvez voir un résumé sous forme de tableau des interventions des testeurs. Votre processus peut être différent, ou basé sur Scrum avec des variations, mais le tableau identifie les types d'intervention typiques dans un processus Scrum classique. Vous pouvez avoir plus ou moins d'interventions actives à différents moments selon votre propre processus unique.

Je vous suggère d'identifier les moments critiques, de proposer votre contribution et de négocier avec votre équipe. Vous apportez davantage de leadership et d’orientation pour les tests, plutôt que de simplement vous porter volontaire pour assumer la responsabilité du travail de test. Adopter cette approche vous permettra de démontrer plus facilement votre valeur à l'équipe, mais il se peut que l'équipe n'ait pas besoin d'autant de testeurs.

Relations avec les développeurs

Dans certaines organisations, la relation entre développeurs peut être fondée sur la méfiance, la recherche de coupables et même l’antagonisme. Au pire, la relation est toxique : les développeurs ne testent pratiquement pas et les testeurs sont considérés comme les serviteurs des développeurs. Les testeurs adoptent un comportement que l’on pourrait qualifier de co-dépendant et se comportent comme des victimes. C’est exactement ce que la démarche shift-left vise à éviter.

De nombreuses métaphores ont été utilisées pour décrire une bonne relation entre développeurs et testeurs. Nous utiliserons la métaphore du duo pilote-navigateur pour illustrer comment une relation comparable entre développeur et testeur peut fonctionner. Mais examinons d'abord une situation dysfonctionnelle.

Le navigateur ne monte pas dans l’avion, mais fait signe au pilote pendant que celui-ci décolle. Le navigateur voyage en bus, séparément mais lentement. Finalement, le navigateur arrive à destination, mais après un certain temps, on découvre que l’avion s’est trompé de direction et s’est écrasé contre une montagne.

Le navigateur n’aurait-il pas dû être à bord de l'avion ? Imaginez comment pilotes et navigateurs collaborent en réalité.

• Le pilote ne peut pas faire voler l’avion sans un navigateur. Le navigateur ne peut pas piloter l’avion.
• Le pilote et le navigateur s’accordent sur le plan de vol avant le début du trajet.
• Le pilote décolle et fait voler l’avion.
• Le navigateur suit la trajectoire, la compare au plan de vol et/ou à la destination finale en tenant compte des événements défavorables, notamment la météo.
• Le navigateur recherche les écarts, trace un nouveau cap et en informe le pilote qui ajuste la trajectoire de vol.
• Et ainsi de suite.

La relation pilote/navigateur est comparable à la relation programmeur/testeur. Séparer les développeurs et les testeurs en équipes distinctes, fonctionnant l’une après l’autre, n’a aucun sens non plus. Pourtant, c’est ce que nous avons classiquement fait depuis une trentaine d'années – en particulier dans les projets plus importants et de longue durée.

La démarche shift-left redistribue la réflexion sur les tests et, de fait, l’anticipe. Les testeurs agissent comme de véritables partenaires des développeurs, tout comme les navigateurs le sont des pilotes :

• Le testeur et le développeur rassemblent conjointement les informations sur les exigences.
• En général, le testeur remet en question les exigences à l’aide d’exemples (idées de tests potentielles ou effectives).
• Le développeur réfléchit à l’implémentation, en s’appuyant sur les exemples pour orienter sa conception.
• Le testeur, le développeur, les parties prenantes, les utilisateurs et les analystes s’accordent sur une compréhension commune d’une exigence fiable.
• Le testeur est en communication constante avec le développeur, discute des évolutions des exigences, des risques d’échec et de la façon dont les tests peuvent démontrer le fonctionnement des fonctionnalités ou révéler des dysfonctionnements.
• Le testeur considère comment la fonctionnalité sur laquelle il travaille s’intègrera à la fois au niveau technique et au niveau du parcours utilisateur, et comment l’intégration pourra être testée.
• Le testeur examine au-delà de la fonctionnalité immédiate développée pour identifier les défis, risques, changements et incertitudes à venir.
• Et ainsi de suite.

La relation idéale entre développeur et testeur telle que décrite ne se produit pas automatiquement. Cela doit être établi par l’équipe. Vous pouvez considérer chacune des activités ci-dessus comme des interventions, mais les interventions ne sont pas toujours confortables pour toutes les parties. Donnez à cette approche les meilleures chances de réussir en discutant de chaque type d’intervention avec vos partenaires dès le départ — dès que vous savez que vous travaillerez en étroite collaboration.

Les interventions, comme de bonnes user stories, servent de déclencheur pour les discussions.

Chaque type d’intervention nécessite l’assentiment des deux parties pour qu’il soit validé. Pour être à l’aise, chacun doit avoir confiance dans le fait qu’il existe une bonne raison de poser des questions, de soulever des problèmes et de remettre en cause les exigences ou leur compréhension lors des réunions debout, des séances de planification ou des rétrospectives.

Défis des équipes distribuées et externalisées

Dans les discussions ci-dessus, il a été tacitement admis que tout le monde travaille dans la même équipe et est situé au même endroit. Lorsque la charge de travail de l’équipe de test logiciel est externalisée et/ou délocalisée, plusieurs facteurs négatifs entrent en jeu. Le tableau présente trois facteurs typiques à prendre en compte.

Certaines entreprises renforcent les équipes de test logiciel existantes pour accroître leurs capacités sur des projets d’envergure, ou embauchent des sociétés spécialisées dans les tests plutôt que de recourir à des sous-traitants ou au personnel utilisateur interne. Dans d’autres situations, tout le développement et/ou l’ensemble des tests peuvent être confiés à des fournisseurs. Dans tous les cas, l’entreprise cliente doit gérer ses fournisseurs. Cela ne veut pas dire qu’il suffit de rédiger un contrat restrictif avec des clauses pénalisantes sévères.

Quand les choses tournent mal, vous souhaitez des réponses rapides et de la collaboration de la part de votre fournisseur ; vous ne voulez pas qu’il se retranche derrière les clauses juridiques du contrat.

Les clés de la réussite sont les suivantes :

• Si vous ne gérez pas votre fournisseur, il vous gérera (si vous n’êtes pas de véritables partenaires et laissez le fournisseur définir les conditions, il détiendra tous les leviers).
• L’objectif est de définir une bonne relation de travail. Celle-ci doit être établie à tous les niveaux – parties prenantes, responsables et praticiens.
• Les contrats doivent être rédigés de façon à définir toutes les responsabilités de chaque partie, avec des mesures appropriées, des seuils, des paiements échelonnés et des critères d’acceptation afin d’encourager les bons comportements (des deux parties de l’accord).
• Les accords doivent encourager la transparence et l’adhésion à l’objectif commun de la réussite du projet.

À méditer

Et enfin, quelques questions pour vous faire réfléchir. 

Quelle relation avez-vous en tant que testeur avec vos développeurs ? Ou, si vous êtes développeur et que vous lisez ceci, quelle est votre relation avec les testeurs ? Peut-être pourriez-vous demander à vos collègues du développement ou des tests comment ils décriraient votre relation. Comparez vos points de vue !

Pour que les équipes de test logiciel soient productives, elles doivent communiquer et collaborer.